MCP Verifier
Tools
THE VERIFIER HARNESS FOR AI CODING AGENTS

Stop letting AI grade
its own homework.

TestMaze is the MCP-native verifier for Claude Code, Cursor, Cline, and every coding agent that speaks Model Context Protocol. Your agent writes the code and runs the tests; Test Maze keeps the test plan, records every result against the exact commit, and returns a pass/fail verdict computed by fixed rules — not by the agent that wrote the code.

Never reads your repo
Deterministic verdicts
Reliability gates
Zero self-grading
Commit-pinned runs

Works with any MCP client. Two commands to connect, one token per project.

~/checkout-v2 · claude code
$ implement checkout flow
→ edited 3 files, ran unit tests ✓
$ testrun.create && pdlc.verify
verdict: fail · 14 passed, 2 failed
text-mismatch · tc_204
nextStep: repair_code
caseId tc_204 · failureBucket text-mismatch
Speaks MCP · works withClaude Code·Cursor·Cline·Gemini CLI·Codex CLI·Any MCP client
THE GAP

AI coding agents are great writers.
They're terrible judges.

When the same agent that writes the code also decides whether it works, every CI green-light is a self-graded exam. You ship faster — and you ship more bugs.

Self-grading drift

Agent edits the assertion until the test passes. The diff looks clean. The bug ships.

No shared quality bar

Every agent invents its own KPI. Selector-failure share, snippet quality, reliability — none of it is enforced.

Hidden flakiness

Retries hide real regressions. "Transient" failures pile up until the suite is unrunnable.

THE PDLC LOOP

One protocol. Six states. One source of truth.

Optionally track each piece of work as a PdlcSession — a state machine the MCP server advances as plans, tests and verdicts land, so your agent always knows the next step. The agent drives; the server keeps score.

01 · INTAKE
project.initialize

Your agent surveys the repo with the product-init prompt and writes back the vision, problem and target users. A session opens, scoped to the workspace your token belongs to.

02 · PLAN
feature.implement

Your agent checks feature.list for an existing feature, then the feature-spec prompt expands the idea into user stories and acceptance criteria across 8 testing facets — rendered locally by your IDE’s LLM.

03 · AUTHOR
feature.verify

The ac-to-testcase prompt turns every acceptance criterion under the feature and its user stories into a complete test case. Prompts run client-side via prompts/get; only the resulting test cases are saved.

04 · CODE
case.update + your agent

Your coding agent writes the code that satisfies each acceptance criterion. The tests are already on record, so the target cannot quietly move.

05 · VERIFY
pdlc.verify

Your agent runs the tests and records pass/fail per case with testrun.create or testrun.record_results, plus optional screenshots. pdlc.verify grades the run — failure buckets, reliability KPI, deterministic nextStep.

06 · SHIP
pass → release.ship

A passing verdict pinned to a clean commit moves the session to SHIP. Mark the release shipped and freeze the run as a regression baseline so it stays green.

On failure: nextStep says whether to fix the code or the test. On success: the session advances to SHIP.
Throughout: every tool call narrated in plain English on the live Agent Sessions view inside your workspace — “Created test case ‘Pay button disabled when cart empty’ for feature ‘Apple Pay’.”
YOUR REPO STAYS YOURS

We verify the work.
We never read your repo.

Your repository lives on your laptop, in your IDE, with your own LLM. Test Maze has no access to it and only sees what your agent explicitly sends in a tool call: test artefacts, run results and git identifiers — plus a snippet of code only when you ask for a code-quality check.

ON YOUR MACHINE

Stays right here.

Your repository
.ts / .py / .go / .sql — whatever the agent edits stays on disk. Test Maze never clones, pulls or scans it.
.env, secrets, credentials
We never read your environment. Your secrets are not in scope.
The LLM that powers your IDE
Claude / GPT / Gemini runs in your client. We never proxy LLM traffic.
Rendered prompt output
feature-spec and ac-to-testcase expansions execute client-side. The diff between template and rendered prompt never reaches us.
Git diffs & history
Test runs carry the commit sha, branch and a clean-working-tree flag — identifiers, not contents.
REACHES TEST MAZE

Just the verdict layer.

Test case rows
Titles, AC labels, steps, expected results — the contract your code is built against.
Test run results
Pass / fail status per case, failure-bucket classification, KPI scoring.
Git identifiers
gitSha, branch name, workingTreeClean flag. We pin verdicts to revisions, never to file contents.
Evidence — opt-in only
Screenshots attach to a run only when your agent explicitly sends one with its results.
Code you ask us to review — opt-in only
quality.smell_check analyses the snippet or diff your agent passes, with fixed rules and no AI. Exploratory testing sends page snapshots of the app under test.
Tool-call trace
Every call (long inputs truncated, secret-looking keys masked) shows on Agent Sessions inside your workspace only. Per-workspace tmt_* tokens isolate every customer.
Point it at your own Test Maze deployment.

The @testmaze/mcp client talks to whichever serverTESTMAZE_MCP_URLnames, so a private deployment keeps the whole verifier loop inside your perimeter.

BYOK AI keys AES-256-GCM encrypted· Per-space tmt_* tokens· Multi-tenant isolation
WORKING WITH YOUR AGENT

From feature spec to shipped — the same loop, every time.

Whether you're starting a fresh project in Claude Code or pushing a new feature into an existing repo with Codex, the workflow is the same: hand over the description, get back a tested, graded build.

Starting a fresh project
Adding a feature to an existing app
01

Drop the feature description in

A PRD, a Linear ticket, a back-of-napkin one-pager — whatever you fed your agent. Fresh project? Use the high-level spec. New branch? Hand us just the delta.

02

It becomes a feature with user stories

Each feature is saved as a suite in your workspace, with its user stories under it — the contract your agent is building toward. Existing repo? Your agent lists what is already there first, so nothing is created twice.

03

Extensive test cases — every facet covered

Test cases are generated for every facet of how the feature can be used, abused and broken — by your agent through Test Maze prompts, or in the web app from an uploaded PRD. coverage.gap_for_feature then shows which facets are still missing.

Happy-path flows
Edge cases & boundaries
Error & recovery states
Permissions & roles
Accessibility (a11y)
Performance budgets
Browser & viewport matrix
Data-shape mutations
04

Your agent codes and runs the tests

Claude Code or Cursor implements the acceptance criteria and runs the tests. It records the results with testrun.create against the current commit, then pdlc.verify grades them — failure buckets, reliability KPI, deterministic nextStep — and feeds the result back into your IDE.

05

A quality grade you can defend

Every test run gets a verdict pinned to a specific commit. Pass — merge it and freeze the run as a baseline. Fail — the next step tells your agent whether the code or the test is wrong. You ship with a reliability score, not a green CI badge you can't explain in standup.

# greenfield product — initialise once
> project.initialize { repoRoot: "/Users/me/checkout-v2" }

# new feature on an existing product
> feature.implement { title: "Apple Pay button", sessionId: "pdlc_…" }

# after your agent codes — grade the work
> pdlc.verify { testRunId: "tr_…", sessionId: "pdlc_…" }
BEYOND THE LOOP

Everything your agent can reach for.

You don't call these tools yourself — ask your agent in plain English and it picks the right one. Every tool, with example requests, is listed on the MCP Tools page inside the app.

Explore your running app

exploration.start · observe · to_cases

Your agent clicks through the app in its own browser (for example Playwright MCP). Test Maze verifies each step, suggests what to try next, tracks coverage and turns the journey into test cases. It never opens a browser itself.

“Explore the sign-up flow on localhost:3000 and save it as test cases”

Find what is not tested yet

coverage.gap_for_feature

Sorts a feature’s test cases into 8 facets — happy path, edge cases, errors, permissions, accessibility, performance, browsers, unusual data — and names the gaps, including missing acceptance-criterion numbers.

“What is the checkout feature not tested for yet?”

Keep fixed things fixed

regression.freeze_run · case.waive_ac

Freeze a fully passing run as a baseline: any later run that drops or breaks one of its cases fails the verdict. Deliberately skip a criterion with a recorded waiver instead of leaving it silently untested.

“Everything passes — lock this in as the baseline”

Keep the code healthy

quality.smell_check · architecture.advise

A code-smell check with fixed rules — same code, same findings — mapped to the refactorings that fix each smell, plus design advice that ranks proven patterns against your problem. Your agent still makes the call.

“Review src/cart.ts for code smells and plan the refactor”

Always on the right project

project.whoami · npx @testmaze/mcp whoami

Each project folder keeps its own token in .env.testmaze, so two repos on one laptop never write into each other’s workspace. Your agent checks which workspace and user it is connected as before changing anything.

“Which Test Maze workspace am I connected to?”

Watch it happen

Agent Sessions

Every prompt, tool call, test run and verdict appears live on Agent Sessions as a feed, a graph and a timeline — in plain English, scoped to your workspace.

“Record my request so it shows up in Agent Sessions”
THE VERDICT PAYLOAD

Every verify call returns the same contract.

No LLM in the pass/fail decision path. Failure buckets are machine-categorised. Every run carries gitSha, branch, and workingTreeClean — so the verdict is bound to exactly the code that ran.

Deterministic verdict path (no LLM in pass/fail)
The same reliability thresholds on every run
Selector-failure share + reliability scoring
Pinned to git state — no untracked-file surprises
Waived criteria and frozen baselines respected
verify.response.json
// pdlc.verify → returns
{
  "verdict": "fail",
  "passed": 14,
  "failed": 2,
  "waived": 0,
  "waivedCaseIds": [],
  "failureBuckets": {
    "selector-not-found": 1,
    "text-mismatch": 1
  },
  "reliabilityKpi": {
    "passRateMet": false,
    "selectorShareMet": true,
    "passRate": 0.875,
    "selectorFailureShare": 0.5
  },
  "gitSha": "a4f9e2c",
  "branch": "feat/checkout-v2",
  "workingTreeClean": true,
  "testRunId": "tr_a4f9e2c-001",
  "sessionId": "pdlc_q4-checkout-v2",
  "nextStep": {
    "action": "repair_code",
    "caseId": "tc_204",
    "failureBucket": "text-mismatch",
    "hint": null
  }
}
WIRE IT UP

One command. Your agent now has a verifier.

Create an MCP token in your workspace, then run two commands in your project folder. init checks the token, shows which workspace and user it maps to, and stores it in .env.testmaze (git-ignored). Your agent can confirm the workspace any time with project.whoami. Stdio and stateless HTTP both share the same tool surface.

@testmaze/mcp is live on npm — setup for Cursor, Cline, Gemini CLI and Codex CLI is in the app
terminal · zsh
npx -y @testmaze/mcp init tmt_xxx
claude mcp add tm --scope project \
  -- npx -y @testmaze/mcp
@testmaze/mcp is a thin stdio wrapper that exchanges your token and forwards to your Test Maze backend (defaults to https://testmaze.com; override with TESTMAZE_MCP_URL). Published on npm.
COMPATIBILITY

Speaks MCP. So it speaks every coding agent.

One canonical contract — tools/list, resources/read, prompts/get — that every modern coding agent already speaks. No plugins to maintain. No bespoke integrations.

CClaude Code
Cursor
clCline
GGemini CLI
{}Codex CLI
Any MCP client
"The coding agent never grades its own work."— TestMaze design contract

Wire your coding agent
to a real verifier.

Five minutes to install. Deterministic verdicts from the first run. Test Maze never reads your repository — your agent sends results, and verdicts come back. Start on the free Basic plan; upgrade when your team scales.