CenterTest AI Toolkit

CenterTest Documentation MCP

Architectural References

The CenterTest Documentation MCP lets your assistant answer from Kimputing's CenterTest documentation instead of general guesswork: configuration references, framework patterns, troubleshooting guides and the CenterTest error-code list. It reads and explains. It doesn't run tests, change code or hold credentials.

• Plain answers for the business side: what a run mode, a restart point or a narrative report is, and what a result means, in words a test analyst can use, including support for business analysts working in Data Studio and Recorder.

• Configuration for engineers: the property, profile or run mode that does what you need, with the documented Java example.

• Stack traces read: paste a failure and get the likely cause, the part of the code it came from (your test, a shared step, the generated page objects or the framework), and the checks to run next.

• Error codes explained: what a CenterTest code such as TD-044 means, and the documented fix.

• Where it runs is your choice: hosted by Kimputing, or in a container on your own machine so questions and stack traces stay inside your network. Each person connects with their own CenterTest seat.

Analysts get answers without a support request, and engineers stop searching the documentation for the setting or the cause they need.

ReportPortal MCP

Test Execution History

When CenterTest publishes to ReportPortal, every run arrives with its results, failure details, stack traces, screenshots, logs and timings, execution narratives, videos and documents extracted during the run, and with the environment and Git branch in the launch name. The ReportPortal MCP server lets an assistant read launches, test items, logs, attachments and each test's history, so anyone on the team can ask about results in plain words.

• How did the run go? A summary of last night's regression run, or of everything that failed in the latest QA launch, without opening the dashboard.

• When did this start failing? A test's run history shows the first failing run, so the team knows which change to look at.

• Does it fail everywhere? The same test compared across environments and branches, using the names CenterTest puts on each launch.

• Triage with the evidence: the logs, error and attachments behind a failure gathered in one answer, with a suggested defect type and the reasoning, and the stack trace passed to the Documentation MCP for a likely cause.

• One view across projects: results from several ReportPortal projects combined into one summary or chart for stakeholders.

Day-to-day results stay where your team already looks; long-term trends come from the CenterTest analytics database.

IntelliJ MCP

Test Code & Data Repository

The IntelliJ MCP connects your assistant to the project you have open: the tests, the shared steps, the generated page objects and your conventions. Advice then follows your implementation, not a generic example. Run it on a shared IntelliJ instance kept on your latest code, and people who never install IntelliJ can ask about your tests too.

• What does this test do? A plain-language walk-through of a test or a set of tests (the flow, the data it uses and what it checks), for someone who never opens the code.

• Is this already covered? Find the tests whose flow tags already map to a requirement before writing another.

• Debug against what works: compare a failing test with a passing one in the same project and find the difference, with the IDE's own build errors and inspections.

• Keep it consistent: draft and refactor to the patterns your project already uses, with the IDE's symbol search, call hierarchy and project-wide rename, including the generated page objects in your libraries.

• Regenerate, do not hand-edit: when a Guidewire screen changes, the fix is to regenerate the page objects using CenterTest Generators; the assistant can tell you which tests then need updating.

Your project's guidance file and the CenterTest skills carry your standards; the IDE connection gives the assistant the code to apply them to.

PostgreSQL MCP or API

Comprehensive Analytics Data

With CenterTest Analytics switched on, every run, test result and recorded action lands in your own database, PostgreSQL or SQL Server, in the documented data model. Connect an assistant through a read-only database MCP server or an API layer, and plain questions become persistent, custom reports without waiting for a report developer.

• Questions a business owner asks: "How many tests ran in each environment this month, and how many failed?" or "Is the regression suite taking longer than last quarter?", answered from your own history as a summary or a chart.

• Failure patterns: failures that follow an environment, a machine, a time of day or a particular check, from the run, result and action records CenterTest keeps.

• Step-level detail for engineers: which screen checks fail most and which steps are slowest, from each recorded action's expected value, actual value and timing; with network capture on, web response times too.

• Reports on demand: a stakeholder summary, a team view or a project-level cut, delivered in the conversation.

• The route that fits your security: a PostgreSQL MCP server for read-only SQL; Microsoft's SQL MCP Server, which exposes only the tables you configure and serves REST and GraphQL from the same setup; or the database tools in IntelliJ.

Every answer comes from your own run history, so a stakeholder's first question and the follow-up it raises are both answered from the same records, with access kept read-only inside your environment.

Recording-to-Test

A compiling test from a Recorder session

Recording to Test turns a CenterTest Recorder session into a working test. A business or test analyst records the flow once, at normal speed, in Guidewire PolicyCenter, BillingCenter or ClaimCenter, adding notes and checks along the way, and hands over the recording. Your engineer asks the assistant to create a test from it, and the skill writes the test the way your project already writes tests.

• No code for the analyst: the recording carries every screen, value, note and check, so what the business expects is captured as it happens.

• Your checks become assertions: every value, message and "no errors" check the analyst added becomes a CenterTest assertion in the test.

• A test class in your layout: in the right center, line of business and transaction folders, named and annotated like your other tests.

• Built on your project, not raw selectors: it reuses your login and builds new reusable steps on your generated page objects. It never writes a credential and never edits an existing file. Any field it cannot map to a generated getter is listed for review, and CSS ID Finder looks it up by ID.

• Reviewed before it exists: it shows a table of every file it plans to create and waits for approval, then builds the project and asks before running the test or adding it to a suite.

Analysts capture the flow they know best; engineers start from a reviewed test instead of a blank file.

Watch one recording become a passing CenterTest test on the CenterTest Recorder page.

CSS ID Finder

Screen Fields to Test Code

CSS ID Finder turns the ID of a field on a Guidewire PolicyCenter, BillingCenter, ClaimCenter or ContactManager screen into the exact line of test code that reaches it. Copy the ID from the browser, or from the widget ID a Recorder report lists beside each value, and name the application. The skill returns the getter chain from your generated page objects, ready to paste.

• Is this field already reachable? Point at a field on the screen. A match means your generated page objects already cover it; a miss says so, and how many forms of the ID were tried.

• The getter chain, ready to paste: for example new AccountFile_SummaryPage(getContext()).getAccountHolder(), instead of a search through thousands of generated classes.

• Table rows and repeated sections handled: IDs carrying row or iterator numbers, toolbar buttons and the _Input suffix are matched the way the generator stores them, and the result shows where your row index goes.

• Guidewire 9 and 10: both ID styles and both mapping-file layouts, so projects generated before and after CenterTest 6.15 work.

• Retire temporary overrides: when the run report says a widget override can be replaced but gives no path, the skill finds the generated widget with that ID.

Analysts can point at exactly the field they mean, and developers get the code that reaches it without searching the generated project by hand.

Test Data Tools

Sound test data, checked before a run

CenterTest test data lives in Excel workbooks that point at each other: a cancellation row points at a submission, which points at a person, an address and a vehicle. The Test Data Tools keep that web trustworthy and readable, using the CenterTest Data Studio engine when it is installed.

• Readable change review: a cell-by-cell list of what changed in a workbook against main, so a business reviewer can approve a data change without comparing spreadsheets by eye.

• Which tests use this data? The tests that depend on a data file, and what a change to it would touch, before anyone edits it.

• Is every reference real? Every code a row points at exists, across workbooks, including the links from cancellations, renewals and claims to their submissions.

• What is no longer used? Data no test uses, workbooks nothing reads, duplicate codes, and test code pointing at data that isn't there.

• A pipeline gate for engineers: fail the build on broken data, or record today's findings as a baseline and fail only on new ones.

Bad data rarely fails loudly: the engine skips it and the test passes while testing the wrong thing. These checks catch it before a run.

Health Check

Test code quality, reported

Health Check reviews a CenterTest project's Java test code against a defined rule set and produces a report the team can share: an Excel workbook with a summary and a sheet per rule, plus Markdown and an HTML dashboard. Run it on the whole project, on one branch before a pull request, or month by month. Generated code is skipped by default.

• For leads and managers: a shareable report on suite quality, and the trend month by month or between two releases, answering "Is our automation getting better or worse?"

• CenterTest compliance: direct Selenium calls instead of CenterTest widgets, fixed sleeps, and data-driven helpers used without their annotation.

• Correctness risks: string comparison with ==, empty catch blocks, waits with no deadline, and a discarded equals check that silently checks nothing.

• Security: possible hard-coded credentials.

• Before merge, for engineers: only the issues a branch introduces against main, plus test-data wiring (missing data files, references that don't resolve), long or complex methods, duplicated code and brittle long XPaths.

Leads get an objective, repeatable measure of suite quality, and every pull request gets the same review whoever wrote it.

---