Back to Blog

The MCP Testing Loop: How a Solo Founder Closes the Build-Test-Fix Cycle with Claude Code

The MCP Testing Loop: How a Solo Founder Closes the Build-Test-Fix Cycle with Claude Code

You are one person. Your AI agent is fast. Your tests are not - at least not the way most teams write them. As a solo founder, the whole reason you reach for Claude Code or Cursor is to compress the loop between "I want a discount code on the paywall" and "the discount code ships." The bottleneck is no longer typing the feature. It is verifying the feature did not silently break the other seventeen things you forgot you built. That is exactly where an MCP testing loop earns its keep: it lets the same agent that wrote the feature drive a deterministic test layer instead of guessing.

That verification step is where most AI coding workflows quietly fall apart. You ship, you pray, you find the regression on Tuesday from a customer email. This post is about how the Lastest MCP server closes that loop - and why "let the model write a Playwright test" is not the same thing.

Forget the hypothetical for a second. Here is Claude Code, wired to the Lastest MCP server, actually doing this - the clip below is an unedited screen capture, not a mockup.

Three prompts, one uninterrupted loop: build the suite, triage the failures, log the ticket - the fourth stage, fixing it, is next commit's job.

Why "ask the model to test it" is not enough in an MCP testing loop

Industry surveys keep landing on the same uncomfortable split: most developers now use AI tools daily, but only about a third trust the output without checking it. The obvious workaround - ask the agent to write its own end-to-end tests - tends to take several attempts before a non-trivial flow runs clean, and the tests it does produce cluster where they are easy to write rather than where regressions actually hide:

LLMs write tests where they're easiest, not where regressions hide.

The failure mode is structural. When an agent writes a test from scratch each time it touches a feature, it has no memory of what the page used to look like. It has no concept of a baseline. It picks selectors that look stable to a language model and break the moment a Tailwind class changes. And every single run burns tokens and wall-clock time.

What you actually want is a deterministic test layer the agent can drive - not author from scratch. Record once, replay forever, and let the agent only intervene when something genuinely changes.

What MCP actually unlocks

The Lastest MCP server exposes roughly 20 tools over the Model Context Protocol. Any MCP-compatible agent - Claude Code, Cursor, Windsurf, Zed, your own LangGraph thing - can call them. The tools fall into five rough categories:

  • Test lifecycle: create_test, update_test, delete_test, list_tests
  • Execution: run_tests, run_suite, run_area, cancel_run, get_run_status
  • Review: review_diff, approve_baseline, reject_baseline, classify_failure
  • Healing: heal_selectors, propose_fix, apply_ai_fix
  • Intelligence: scan_routes, detect_framework, discover_areas, check_coverage, get_impact
Layered stack of the five MCP tool categories the Lastest server exposes: test lifecycle, execution, review, healing, and intelligence, each band labelled with the kind of work it lets an agent do, stacking into one end-to-end testing loop the agent owns.
The five tool categories stack into one loop an agent can own end to end, from creating a test to classifying its failures.

The point is not the tool count. The point is that those tools are enough for an agent to own the testing loop end to end without you switching tabs. And because Lastest is bring-your-own-AI, the agent calling them can run on Claude, an OpenAI key, OpenRouter, or a local Ollama model - no lock-in to one provider.

A real flow, captured on screen: build the suite, triage a regression, log the ticket

Watch what happens across three prompts in the clip above.

Prompt one: "claude, set up Lastest visual tests for staging.acme.io." Claude connects to the Lastest MCP server and hands the crawl to the Play Agent - the sub-agent pipeline that explores the app on its own instead of waiting for you to enumerate every flow. It maps four areas (checkout, product, nav, auth), records 24 visual tests, and asks for exactly one approval: baseline confirmed. Nobody hand-wrote a test file, and nobody reviewed 24 screenshots pixel by pixel.

Prompt two: "a PR just landed. replay the suite and triage failures." Claude replays all 24 tests in CI - GitHub Actions, zero tokens, because a replay is Playwright executing a recorded script, not a model improvising one. Eleven checks come back clean. Two get flagged. One of them, checkout/price-stepper.spec.ts, shows a 1.05% visual diff on iOS Safari. Claude does not stop and ask you "is this bad?" - it reads the diff classification the same way review_diff would return it and reasons directly: a layout regression, not something anyone changed on purpose.

Prompt three: "open a GitHub issue with full context for the eng agent." Claude opens issue #482 - "Regression: price stepper misaligned on iOS Safari" - and attaches everything a human or another agent needs to fix it without re-deriving context: the spec file, the failing selector ([data-testid="qty-stepper"]), the baseline-vs-current diff, and the browser/viewport it was seen on. It tags the issue ai-ready and assigns it to @ai-engineer. That is the fourth stage in the loop - build, triage, log, fix - meant to run on every commit, not just the ones you remember to check.

Notice what never happened. You did not write a test. You did not open the Lastest UI. You did not load Safari on an actual iPhone to eyeball a price stepper. The only judgment calls were Claude's, and every one of them was grounded in a deterministic diff, not a model guessing whether two screenshots "look the same."

The tool schema, in case you want to wire your own agent

Every MCP tool is a typed JSON schema. Here is run_tests, slightly trimmed:

{
  "name": "run_tests",
  "description": "Execute one or more recorded tests against the current build.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "tests":      { "type": "array", "items": { "type": "string" } },
      "area":       { "type": "string", "description": "Optional area name to scope the run" },
      "baseline":   { "type": "string", "enum": ["main", "current", "branch"] },
      "headed":     { "type": "boolean", "default": false },
      "diff_engine":{ "type": "string", "enum": ["pixel", "structural", "perceptual"] },
      "heal":       { "type": "boolean", "default": true }
    },
    "required": []
  },
  "outputSchema": {
    "run_id":   "string",
    "status":   "queued | running | passed | failed | diffed",
    "passed":   "number",
    "failed":   "number",
    "diffs":    "Array<{ test: string, region: string, severity: number }>"
  }
}

Notice heal: true by default. If a button moved or got renamed, the 7-layer self-healing selector (data-testid → id → role → aria-label → text → CSS → OCR) kicks in before the test is marked broken. The agent sees a green run, not a fake failure. That is the difference between an agent that closes the loop and an agent that pages you about a non-bug at 11pm. We break the fallback chain down in how self-healing selectors work.

The loop, drawn out

Pipeline diagram of the MCP testing loop: you ask Claude Code for a feature, it writes the code and calls the Lastest MCP server, which fires zero-token deterministic Playwright replays with self-healing selectors, runs three diff engines, and only pings you when the AI classifier flags a change as not intentional, otherwise the agent ships.
The agent drives every step; the human-in-the-loop edge only fires when a diff is classified as not intentional.

The shape of that diagram is the whole point. The human-in-the-loop edge - "ping you for review" - only fires when the diff engines plus the AI failure classifier think the change is not something the agent just did on purpose. Most runs never reach you. The ones that do are the ones that should.

Why this beats "let the model just test it"

Two-column comparison: the red left column is an agent writing Playwright from scratch (new selectors each run, thousands of tokens, high flake, tests where it is easy, no human approval); the teal right column is an agent driving Lastest via MCP (recorded once and replayed, zero tokens, 7-layer self-healing, get_impact scopes coverage, human-in-the-loop on diffs).
Same agent, two strategies: authoring tests from scratch versus driving a deterministic test layer over MCP.
DimensionAgent writes Playwright from scratchAgent drives Lastest via MCP
DeterminismNew selectors each runRecorded once, replayed forever
Tokens per runThousandsZero (replay is local)
Flake from layout shiftsHigh7-layer self-healing
Coverage logic"Where it's easy"get_impact picks affected areas
Baseline approvalNone - model declares victoryHuman-in-loop on visual diffs
Cost of a re-runTokens + wall clockSeconds, free

The token math alone is decisive. If your agent writes a 200-line Playwright test from scratch every time it touches checkout, that is real money - and worse, a real delay - on every iteration. With the MCP loop, replays are zero-token deterministic Playwright runs, so the agent's job shrinks to orchestration: pick the area, fire the run, read the diff, decide. That is what LLMs are actually good at.

The manual testing tax you stop paying

The win here is not a benchmarked number, it is a category of work you stop doing by hand. A solo founder shipping several features a week pays a steady manual testing tax: clicking through flows, eyeballing the paywall on mobile, making sure last week's bug fix did not quietly unfix itself. The MCP loop pulls most of that into the agent, because replays are deterministic and the agent only escalates a true visual diff. The clicking-through-flows-by-hand hours mostly disappear, and they were the most boring hours you had. We put rough figures on that drain in what manual QA actually costs a solo founder.

And the thing that makes it actually work is not the AI. It is the deterministic substrate underneath: recorded user journeys, three diff engines, and a typed MCP surface the agent can call without inventing anything. The agent is the conductor. Lastest is the orchestra.

How to wire it up

Self-hosting Lastest is free, forever - open source under the FSL-1.1 license, your infra, unlimited screenshots and replays. Source is at github.com/las-team/lastest; if you would rather skip the ops, Lastest Cloud is a flat $299/month with no per-seat or per-screenshot fees. Once it is running, point your MCP client at the server (Claude Code: claude mcp add lastest ...) and the tools show up in your agent's tool list automatically. Record three or four critical journeys - signup, checkout, paywall, dashboard - and let the agent take it from there.

Your tests stop being something you maintain. They become something your agent uses. That is the loop. If you're a solo founder burning hours on manual QA, this is the cheapest minute-per-minute upgrade you can give your build pipeline this quarter. Browse the full MCP tool surface, watch the live demos, or clone the repo and wire it into Claude Code today.