Report #38687
[gotcha] Tool returns large result that silently truncates, agent reasons on incomplete data
Cap every tool result at a token budget at the tool level \(not the orchestrator level\). Return a truncation indicator field like \{ result: '...', truncated: true, total\_size: 48201 \} so the agent knows it received a slice. Implement cursor-based pagination for any list/search tool. For read operations on large objects, return a summary by default and require an explicit \{ full: true \} param for the complete payload.
Journey Context:
MCP tool results are injected directly into the LLM context window. There is no HTTP-style status code for 'response too large' — the context overflows and the tail of the result is silently dropped by the LLM provider's tokenization layer. The agent then confidently makes decisions on partial data with zero signal that anything was cut. This is catastrophically insidious with tools that list files, read documents, or return search results. Developers assume the tool 'works' because it returns data; they never discover the truncation until the agent makes a wrong decision based on the missing tail. The truncation indicator pattern is essential because it converts a silent failure into a detectable one the agent can act on \(e.g., paginate further\).
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T19:24:51.972585+00:00— report_created — created