← All posts

Giving coding agents a QA teammate over MCP

Most of what we've built so far works after the fact. Code ships to staging, Testomatica notices the deploy, the gate runs, agents explore, the referee confirms, a ticket lands in Jira. That's detection, and it's useful.

But the cheapest bug is the one that never gets written.

A growing share of code is now written by coding agents: Claude Code, Cursor and others. Those agents are fast and often careful. What they lack is context about consequences. They see the file they're editing and maybe a few around it. They don't know that the query they're about to rewrite feeds the price sort on the category page, or that there's a business rule saying an in-stock product must never show a price of 0.00.

We know those things, because they're in the impact graph and the coverage map. So we gave agents a way to ask.

An MCP server for the questions agents should be asking

The Model Context Protocol lets a coding agent call external tools in a standard way. We run an MCP server that exposes Testomatica's knowledge as tools an agent can call while it works. It currently has 17 of them, and they mostly fall into three questions:

  • What will this change affect? Pass in the files you plan to touch, get back the affected pages, rules and tests, each with the dependency path that explains it.
  • Which business rules apply here? Before editing pricing code, an agent can see the rules that guard pricing: in-stock price above zero, card price matching the product page and the cart, sort order matching the displayed price.
  • Which tests should I run? Instead of the whole suite or nothing, the agent gets the tests that sit downstream of its change.

None of these answers come from a model. They come from the graph and the coverage map, the same way every time. An agent can be wrong about what it wants to do. It shouldn't have to guess about what's connected to what.

The same answer, in the pull request

Not every change comes from an agent with MCP configured, and humans review code too. So the same information is meant to show up as a comment on the pull request: here's what this diff touches, here are the rules in play, here are the tests that matter. A reviewer looking at a twelve-line change to a stored procedure deserves to know it reaches the category page.

We like that the agent and the reviewer get identical answers. If they disagree about a change, they're at least disagreeing about the same facts.

Why now

The server lives on the dedicated machine that came online on October 9, alongside everything else. Before that, it would have been one more process on a laptop. Now a coding agent can reach it the way it reaches any other tool.

There's a slightly funny symmetry here. We built Testomatica because AI-written code needs better verification. Part of that verification now happens by giving the AI that writes the code better information up front.

Detection still matters. Agents will still make mistakes, and the gate and the referee will still catch them. We'd just like them to catch fewer.

Testomatica TeamWritten Wednesday, October 21, 2026

Want Testomatica watching your deploys?

We're onboarding a small group of teams that ship with AI.

Get early access