Claude Paraphrased a Document After Reading Only the Beginning: Hidden MCP Server Truncation

A developer discovered that Claude confidently summarized a large document, even though it actually read only the beginning — the cause turned out to be an unnoticed truncation of the response from the MCP server.

What the developer discovered

The author connected the mcp-server-fetch tool to Claude and asked the agent to extract several specific fragments from a document. The model responded fluently and confidently, giving no hint of a problem: the text appeared as if the agent had truly worked through the entire document. Only by analyzing the JSON-RPC traffic between client and server — that is, by looking at the raw message exchange between Claude and the connected tool — did the developer see that the document content was truncated at the 6000-character mark.

Moreover, the server marked the truncated response as successful, without a single indication of error or truncation. Formally, from the protocol's perspective, the request completed normally: the response code did not signal a timeout, limit exceeded, or any other failure. The model received partial data and processed it as complete.

• The tool — mcp-server-fetch, used to fetch 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, without an error flag
• At the end of the truncated text, the server added a hidden instruction for the model
• The problem was discovered only through manual analysis of JSON-RPC traffic between client and server

Why this is dangerous for agents

MCP (Model Context Protocol) — an open protocol through which AI models like Claude connect to external tools: file systems, databases, web requests. When such a tool returns trimmed data without an explicit error signal, the model has no way to distinguish a complete response from a partial one — it simply works with what it received and returns results with the same confidence as if it had read the entire document. For the user, there is no visible difference: the response is equally coherent, equally logical, and equally convincing.

Even more concerning is the second finding from the author: at the very end of the truncated response, the server added a text instruction addressed to the model. Formally this is part of the content that the agent interprets as data from the document, but in reality — a control message inserted by the tool itself after the actual content ended. For a user who does not look under the hood of the JSON-RPC exchange and only sees the model's final answer, such substitution remains completely invisible: coherent text, confident tone, no visible signs of failure or unreliability.

This illustrates a broader problem in the "model-tool" chain: trust in a tool's result is rarely verified in practice, because the mere presence of a response is perceived as confirmation of its completeness. Until the protocol requires explicitly signaling truncation, responsibility effectively falls on the developer, who must separately log and cross-check raw traffic, rather than relying on the model's final text.

What this means

As agents based on Claude and other models increasingly use MCP servers to access external data, quiet truncations and hidden instructions within tool responses become a practical risk to the quality and reliability of agent systems. Developers building pipelines on MCP should establish checks for truncation indicators in the tools themselves and not blindly trust tools — even if the model's final response looks absolutely convincing.