Grade a test run and say what to fix next
pdlc.verifyVerdictGrades a test run as pass or fail with fixed rules; no AI decides.What it does
Final step of the loop (project.initialize → feature.implement → feature.verify → testrun.create / testrun.record_results → pdlc.verify). Reads the results of an existing test run and returns a verdict: is it done, and if not, what to do next. It never runs tests itself; record results first. The verdict is "pass" (at least one case passed and none failed), "fail" (any case failed, or a case from a frozen regression baseline is missing or no longer passing), or "in-progress" (no case has a Pass or Fail yet). Cases whose acceptance criterion is waived (case.waive_ac) are left out of grading and counted in waived. It is computed by fixed rules, never by an AI, so the same results always give the same verdict. Returns snapshot with verdict, passed, failed, failureBuckets (failures grouped by cause, e.g. timeout, selector-not-found), waived and waivedCaseIds, reliabilityKpi, gitSha, branch, workingTreeClean, frozenRegressions (only when present) and nextStep. nextStep.action in plain words: "ship" = everything passed, release it (release.ship); "repair_code" = the app is wrong, fix the code for nextStep.caseId and re-run; "repair_test" = most failures are the test failing to find elements on the page, so fix the test (case.update) and re-run; "add_coverage" = nothing was graded yet, add or execute test cases. nextStep.hint is optional advice text that an AI may write for repair actions when the workspace has an AI key; it never changes the verdict. The response also lists nextTools to call.
Ask your agent
You don’t call pdlc.verify yourself. Say something like this to Claude Code, Cursor or another MCP-connected agent:
- “Did the last test run pass? What should I fix first?”
- “Check whether the checkout feature is ready to ship”
- “Grade the tests I just ran and tell me if the bug is in my code or the test”
Inputs
| Name | Type | Description |
|---|---|---|
testRunIdrequired | string | Id of the test run to grade: the id returned by testrun.create, or from testrun.list. Must belong to the connected workspace and already have results recorded. |
sessionIdoptional | string | Optional PDLC session id (from project.initialize or pdlc.list). When given, the session is moved forward to VERIFY and then routed by the result: ship → SHIP, repair_test → REPAIR, anything else → CODE. Works from AUTHOR, CODE, REPAIR or VERIFY. If the move is not allowed you still get the verdict, and the message says the state change was skipped. |
The MCP call
What the agent’s MCP client sends (placeholders in angle brackets):
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "pdlc.verify",
"arguments": {
"testRunId": "<testRunId>"
}
}
}Connect your agent
npx -y @testmaze/mcp init tmt_xxx claude mcp add tm --scope project -- npx -y @testmaze/mcp
Create the token in your Test Maze workspace under Settings → MCP. Setup for Cursor, Cline, Gemini CLI and Codex CLI is shown there too.
More guided workflows tools
- Start the build-and-verify loop for this repo
project.initialize - Start a new feature and plan its tests
feature.implement - Write out the full test cases for a feature
feature.verify