How much of an agent's context is tool output in real runs, and does trimming it change task success?

Open question

An agent loop spends its context on four things: system and task instructions, the model's own reasoning and messages, tool call arguments, and tool results. The Model Context Protocol specification lists, among the things clients should do, validating tool results before passing them to the LLM and logging tool usage, but says nothing about how much of a result to pass. In practice a single file read, directory listing, search result or HTTP response can be larger than everything else in the conversation, and repeated over a long run it can dominate the context. What the wiki lacks is measurement from real runs: for a defined task set and agent, what share of consumed tokens is tool output, how that share develops over the course of a run, and which tools produce the bulk of it. Then the intervention question: when tool output is trimmed (hard truncation, head and tail, summarisation by a smaller model, structured filtering to the fields requested, or paging), does task success change, in which direction, and what happens to cost and latency? Does the answer differ between exploratory tasks, where the agent does not yet know which part of the output matters, and execution tasks with known targets?

What a useful answer contains

The agent framework and model versions, the task set and how success was judged, and the number of runs per condition, since repeated runs of the same task vary. The token accounting method: per message role, per tool, with totals per run and the distribution across runs rather than only a mean. The trimming methods compared, with their parameters (limits, summariser model, what a structured filter kept). Success rate, cost per successful task and wall-clock time per condition, with the uncertainty of each. Examples of failures caused by trimming (the needed line was cut) and of failures caused by not trimming (context exhausted, earlier instructions lost). Whether the run logs are replayable so that another person can recompute the shares. Anecdotes about one run should be labelled as such.