It is known that MCP tools can consume agent context (that is, the information, instructions, and data an agent needs before it makes a call). Loading tool definitions on demand can reduce that overhead, but your context budget also has to account for the call’s response too.

To get a better handle on context consumption, we set out to answer this question: how much of a tool’s result output reaches the agent, and how many copies of the output does it get?

Initial Observation

While working on Polytomic’s MCP server, we noticed that a small compatibility feature could make our tool responses much larger in an agent’s context.

The MCP spec lists a recommendation for backwards compatibility: tools returning structured content should also include the the content’s serialized JSON in a text block in the response. Here is the quote from the spec specifying this:

Based on this, we added structuredContent to our response alongside the existing text content, returning the same data in both. But we soon noticed that, depending on the harness, that compatibility copy can become a second copy of the payload available to the agent.

The duplication is easy to overlook for a small output. But for a large schema or query result, it can mean spending context on the same information twice.

The path to this starts well before the MCP response. For example, the harness (i.e. the software connecting the model to its tools) decides how to turn that response into model input.

Given a particular LLM, how could we predict this duplication in advance? Source code and traces can help but don’t provide ironclad proof that the model received duplicated data: a trace containing both the structuredContent and content fields only proves that they were recorded, not that the model necessarily received both.

We needed a test that could distinguish these two fields from the agent’s own response.

Verifying Differences in MCP Protocol Implementation

To figure out exactly what each model does, we built a small MCP server with three probes:

• The first returns a different random marker in each field.
• The second returns text only.
• The third returns structured content only.

We then ask the agent to report on the exact markers it sees and we compare those reports with the server’s markers.

The markers deliberately differ so that we can tell the two fields apart. Reporting both indicates that information from both fields was available to the agent, thus if a real tool puts the same JSON in both fields we know we’d have a data-duplication risk.

We employed the following pass/fail/warning rubric:

• Structured-only visibility is marked as a pass for the dual-field probe.
• Text-only visibility is marked as a warning.
• Both-marker visibility is marked as a failure.

This rubric expresses our preference: expose the payload once, prefer the structured representation, and preserve either single-field result.

(We are not claiming that the MCP standard mandates this selection policy, only that we prefer it.)

Results

The results are now live at What the Harness?. We tested different models and harnesses, resulting in this October 2, 2026 snapshot of the latest approved run for each harness, MCP client, and version:

As the table makes clear, there are inconsistencies.

For an example of the phenomenon we’re talking about, consider Amp’s result (perhaps the most notable one):

Both its cloud version (listed as Amp on our site) and CLI version declared the same MCP client (amp-thread-actor) and the same version number (1). Yet, when sending both our markers, the cloud run correctly reported both while the CLI run only reported the structured marker.

Our tests revealed inconsistencies with the others too:

• Claude Desktop only reported text despite both fields being present, while Claude Code only reported structured content.
• ChatGPT Desktop only reported structured content, while the OpenAI Agents API path reported both.
• The Codex paths, Grok CLI, and Pi reported both.
• Cursor and Grokbot only reported text and reported no markers for structured-only output (note that Grokbot declares its MCP client as Cursor, which makes the distinction between harness and client especially useful).

Due to these inconsistencies, it became clear that our compatibility table needs to list the harness and execution environment as well as the declared client and version.

Browser Compatibility Testing, Again

We created What The Harness? to collect these observations. This will help us compare behavior across agent clients and versions.

The observations on there can be updated with your own results by doing the following:

1. Connect our public probe.
2. Run the test prompt.
3. Submit your results through the MCP connection. Submissions will be reviewed by the Polytomic team before publication (older approved runs also remain available).

Thanks to QuirksMode and Peter-Paul Koch for the web-browser compatibility tables that inspired this approach. As with QuirksMode, here we also illustrated an ostensibly identical protocol, different implementations, and a table of what happens in reality.

An eternal fact in software is that all standards have implementation inconsistencies. This was certainly true for web browsers and multi-platform compilers. Agents are proving no different.