MCP
None of these exist. This section describes what four Model Context Protocol servers would do and, more importantly, where each one’s boundary sits — which is the part worth reviewing before any of it is written.
Publishing the boundary before the implementation is deliberate. The interesting question about applying a model to testing is not whether it can produce test code; it is which decisions stay human, and that question is cheaper to answer on a page than in a retrospective.
The four
Section titled “The four”| Server | Does | Does not |
|---|---|---|
| Test scaffolding | Turn acceptance criteria into test skeletons at the right level | Decide what the criteria are, or assert anything it inferred from the code |
| Risk analysis | Rank a change set by likelihood and impact from history | Decide what is tested — that is a human decision it informs |
| Exploratory charters | Draft session charters from a change set and a risk model | Run the session, or judge what was found |
| Performance DSL authoring | Derive a workload model from access logs and contracts | Set the SLO, or decide the run passed |
The line
Section titled “The line”One rule generates every “does not” in that table:
A model may generate anything whose correctness a human can check quickly. It may not generate the thing being checked against.
A test skeleton is checkable at a glance. An assertion derived from observing what the code currently does is not — it is a change detector that agrees with every bug already present, and it is indistinguishable from a real test until the day it matters. That single distinction is why the tooling section rules out AI-generated assertions over existing behaviour while this section exists at all.
The same rule applied to the other three:
- Ranking risk is a suggestion over evidence a human can audit; deciding coverage is a commitment somebody has to own.
- A charter is a starting point for a session whose value comes from the human following surprises.
- A workload model derived from real logs is checkable against the logs; the SLO it is measured against is a promise to users, which no model is in a position to make.
Why a model helps at all here
Section titled “Why a model helps at all here”Testing has an unusual amount of work that is mechanical but not straightforwardly automatable — it needs judgement about context, not just transformation. Generating a parameterised test skeleton from six acceptance criteria, in this repository’s conventions, at the level the strategy says that property belongs at, is exactly that shape: too contextual for a template, too mechanical to be worth a person’s afternoon.
And the failure mode is bounded, because a wrong skeleton is obvious in review. That is not true of most places a model gets pointed at.
Status
Section titled “Status”Described. Not built, not scheduled, not committed to. If any of them is built, the page for it will say what it actually does rather than what it would.