Blog / Tool results and errors

structuredContent or text? Which half of your MCP result the model actually sees

The MCP spec lets a tool return its result twice: once as text and once as structuredContent, and recommends sending both for compatibility. So many servers do. But the model doesn't get both. Each agent app picks a half, and they don't pick the same one.

Leonid Bugaev · Published 21 Oct 2026

The two-marker test

To see which half reaches the model, you need the halves to differ. Our test server has one tool. Its text content carries the marker TXT-7Q4; its structuredContent carries STR-9Z2. We ask each app to call the tool once and report every marker it can see, without guessing. Then we check the app's transcript for what it passed on.

{"content": [{"type": "text", "text": "TEXT_PART: marker TXT-7Q4"}],
 "structuredContent": {"part": "STRUCTURED_PART", "marker": "STR-9Z2"}}

A model can't report a marker it never saw, so this is a clean read on what each app does with a dual result.

What each app passed to the model

We ran the same test on 16 October with Claude Code 2.1.301 and OpenCode 1.18.34 and got the same result for both. It matches public reports: Claude Code users have noticed text being hidden when structured content is present (#9962, #45575), and Codex made structuredContent the preferred function output (PR #2594), with users reporting dropped content blocks (#10334). In our runs Codex's model still saw both, because in code mode it gets the whole result object.

The practical consequence: if your text says something the structured half doesn't, such as “call get_item next” or “results are truncated, use offset”, Claude Code's model never reads it. If your structured half has fields the text lacks, OpenCode's model never sees them.

What duplication costs

On the wire, sending both halves sends the data twice. We measured a 99-tool production server where 27 of 34 read tools did exactly that, with no outputSchema on any tool:

Because each app picks one half, most runs don't pay double in the model's context. But the client still receives both, and Codex can pay for both: when its model printed a raw result in code mode, both halves were serialized, “original token count: 67,251”, and the output was truncated. Large results have their own limits per app; see MCP output limits by agent.

What to send instead

1. Full data in structuredContent, with an outputSchema so clients know its shape.
2. A short text summary: what was returned, how many, whether there's more, and the next useful call. Not the same data serialized again.
3. Put anything the model must read in both, briefly. A “truncated, use offset=10” note belongs in the structured half too, for Claude Code.
4. Test it with markers in your own server, per app, after each client update. Behaviour has changed between versions before.

{"content": [{"type": "text", "text": "12 tasks blocked in Mobile app (showing 10). Next: offset=10."}],
 "structuredContent": {"items": [...], "total": 12, "next_offset": 10}}

Small, summarised results helped every model in our tests: see should your MCP server look different to each model? For the wider question of which MCP channels agents use, see MCP prompts, resources and tools.

Go deeper: Tool results for AI agents, Pagination for agents, Error messages for AI agents.

How we measured

• Two-marker server: a 12-line stdio MCP server with one read-only tool whose text and structured halves carry different markers.
• Runs: 2 per app on 21 Oct 2026, about 21:40 (UTC+3): Claude Code 2.1.304 and Codex CLI 0.161.0 with default models, OpenCode 1.18.34 with a small free model. Each isolated from other servers. Earlier capture: 16 Oct 2026, Claude Code 2.1.301 and OpenCode 1.18.34; Codex's raw-print figure is from a live run the same day.
• Evidence: the marker the model reported, checked against the tool result recorded in each app's transcript.
• Production sizes: recorded default results from a 99-tool production server, counted in o200k_base, 16 Oct 2026.
• Limits: 2 runs per app is enough for a yes/no on a deterministic behaviour, not for rates. Grok Build and OpenCode 2 weren't re-tested.