Claude summarized a document after reading only the beginning: an MCP server's hidden response truncation

A developer found that Claude had confidently summarized a large document after actually reading only its beginning. The cause turned out to be silent truncation on the MCP server's side.

What the developer found

The author connected the mcp-server-fetch tool to Claude and asked the agent to extract several specific passages from a document. The model responded fluently and confidently, with nothing to suggest a problem: the output read as if the agent had worked through the entire document. Only after inspecting the JSON-RPC traffic between client and server, the raw message exchange between Claude and the connected tool, did the developer see that the document's content had been cut off at the 6000-character mark.

The server also marked the truncated response as successful, without a single error or truncation flag. As far as the protocol was concerned, the request completed normally: the response code signaled no timeout, no exceeded limit, and no other failure. The model received partial data and treated it as complete.

• Tool: mcp-server-fetch, used to retrieve web content and pass it to the model
• The response was truncated at the 6000-character mark
• The server marked the truncated response as successful, with no error flag
• At the end of the truncated text, the server appended a hidden instruction to the model
• The problem was discovered only through manual analysis of the JSON-RPC traffic between client and server

Why this is dangerous for agents

MCP (Model Context Protocol) is an open protocol that lets AI models such as Claude connect to external tools: file systems, databases, web requests. When such a tool returns truncated data without an explicit error signal, the model has no way to tell a complete response from a partial one. It simply works with what it received and produces a result with the same confidence as if it had read the whole document. From the user's side, nothing looks different: the answer is just as coherent, just as logical, and just as convincing.

The second part of the author's finding is especially troubling: at the very end of the truncated response, the server appended a text instruction addressed to the model. Formally, it is part of the content the agent interprets as data from the document. In practice, it is control text inserted by the tool itself after the real content had already ended. For a user who doesn't look under the hood of the JSON-RPC exchange and sees only the model's final answer, this substitution stays completely invisible: coherent text, a confident tone, and no visible signs of failure or unreliability.

This illustrates a broader problem in the model-tool chain: trust in a tool's output is rarely verified in practice, because the mere existence of a response is taken as proof that it is complete. Until the protocol explicitly requires signaling truncation, the burden of verification effectively falls on the developer, who has to log and cross-check the raw traffic separately rather than rely on the model's final text.

What it means

As agents built on Claude and other models increasingly rely on MCP servers to access external data, silent truncation and hidden instructions inside tool responses are becoming a practical risk to the quality and reliability of agentic systems. Developers building pipelines on MCP should build truncation checks into the tools themselves and should not trust tools blindly, even when the model's final answer looks completely convincing.