MCP: wiring agents to your test estate

MCP, the Model Context Protocol, is a standard way for an agent to reach tools and data. An MCP server exposes a set of capabilities. An MCP client, which is the agent, calls them.

The point is that it replaces bespoke integrations. Without it, every agent needs its own custom glue for your test management tool, your CI and your logs. With it, you describe those capabilities once and any compatible agent can use them.

Your test estate is the material worth exposing: cases, runs, results, defects, logs, coverage. Most of it is read-only reference data, which happens to be the safest and most useful thing to start with.

The terms you will hear

• MCP server. A process exposing tools, resources or prompts over the protocol.
• Tool. One callable capability, such as "search test cases" or "get run results".
• Resource. Data an agent can read, such as a document or a log file.
• Client. The agent side, which discovers and calls what the server exposes.
• Scope. What the exposed credentials are allowed to touch. The most important design decision.
• Transport. How they talk, usually a local process or an HTTP endpoint.

Why it matters for testers

Because the questions people ask about a test estate are tedious to answer and easy to expose.

For example: which tests cover the refund path, when did this case last pass, which defects were open at the March release, what changed in the suite last week. Each of those is a query somebody currently answers by hand, and each becomes one tool call.

That is the whole value proposition. Not autonomy, but removing archaeology, which is exactly the problem traceability exists to solve.

What to expose, in order

1. Read the suite. Search cases by text, by tag, by area. Return ids and titles rather than whole documents.
2. Read run history. Results per case per build, with dates. This answers the most common question you get asked.
3. Read defects. Open, closed, by severity, linked to cases.
4. Read logs and artefacts. Scoped to a run, and redacted, because logs carry personal data.
5. Read coverage data. Which areas have tests and which do not.
6. Only then consider writes. Creating a draft case or a draft defect, marked as agent-created and requiring review.

How to do it safely

1. One scoped credential per server. Not your personal token. A service identity that can reach exactly the projects in question.
2. Read-only first, for at least a month. Watch what gets asked before you consider writes.
3. Rate limit and cap. A loop calling "search cases" four hundred times is a normal failure mode, not an attack.
4. Redact on the way out. Logs and test data contain emails and tokens. Strip them in the server, not in the prompt.
5. Log every call with its arguments. You will need this the first time an answer looks wrong, and it is the same rule as reading an agent's trajectory.
6. Test it like an API. It is one. Wrong arguments, missing permissions, huge result sets, and the injection case below.
7. Treat returned content as untrusted. A test case title containing "ignore previous instructions" is indirect injection through your own tooling.

A worked design

For example, here is a first server for a small team, with the decisions written down.

The last block is the argument for starting read-only. In a month of real use nobody wanted a write, and the four questions that came up repeatedly were all archaeology that used to cost somebody twenty minutes.

How to show you know it

• A read-only server that answers real questions. With the list of what was actually asked.
• A scope decision. "One service credential, two projects, no writes." It shows you designed the blast radius before the feature.
• An injection test through your own data. A case title carrying an instruction is the test nobody thinks to run.
• A redaction check. Proving logs come back masked is the difference between a useful tool and a leak.