Your customer support agent uses an order_lookup MCP tool that returns 40+ fields per order: order ID, status, dates, line items, shipping carrier, tracking number, billing address, shipping address, payment method, gift wrap selection, marketing source, internal flags, and on. The agent typically only references 5 of these fields. After a 12-turn conversation, the context is dominated by tool outputs — earlier turns have been compressed and key facts are getting lost.
What's the best fix?
Why did you pick that answer? Two or three sentences. The act of articulating it is what builds the judgment — not the click that follows.
Context economy starts at the tool layer. Tools that return 40 fields when the agent uses 5 are wasting context budget the agent will need later for reasoning, recall, and case facts. The fix is to shape the tool's output to match what's usually needed, with a separate detail-fetch tool for the edge cases. This is a recurring pattern: don't make the model pay tokens to ignore data; don't serve it data it didn't ask for. Trim at the boundary, expose detail on demand.
A larger context window lets you waste more tokens before consequences hit — it doesn't fix the underlying inefficiency. And lost-in-the-middle effects worsen as context grows.
Asking the agent to summarize every tool output adds an LLM call per tool call (cost, latency, error surface) for work that's deterministic — you know which fields matter, so trim them at the source.
A 500-character cutoff could chop off the order ID or the status while preserving an internal flag the agent doesn't need. Structure-aware trimming keeps what matters and discards what doesn't; character-count truncation can't.