One MCP Call, 24K Characters: Why Tool Results Keep Blowing Up Your Context Window

Someone on r/mcp posted their context usage after one tool call: 24,568 characters, from a single response. If you've built or run more than one MCP server, this isn't surprising - it's close to the default outcome. Nobody designs for it on purpose; it's just what happens when a tool returns "the data" instead of "the data the model actually needs."

This happens enough that there's a name for it - context bloat - and enough real incidents behind it that the numbers are well documented. A single Playwright DOM snapshot runs about 56 KB. A gh issue list dump comes back around 59 KB. Feed either straight into a model's context and you've spent tens of thousands of tokens before the model has done anything with the data at all.

Where the bytes actually come from

Almost every case traces back to the same root cause: the tool returns everything it has, not everything the request needs. A few recurring patterns:

• No extraction. A browser automation tool returns the full page HTML instead of the title, main text, and links you actually asked about - the difference between roughly 50,000 tokens and about 500.
• No pagination. A list endpoint returns every row it has. Without a page size cap, one call to "list my open issues" can return hundreds of them in a single response, whether or not the model needed all of them.
• No response shaping. Scripts, styles, comments, and boilerplate ride along with the content that actually mattered, because nobody told the tool to strip them.

None of this is a flaw in MCP as a protocol - it's a flaw in how individual tool implementations decide what "the response" means. A tool author who never thinks about token cost will, by default, return the most complete answer they can construct, which is exactly the wrong optimization target when the consumer is a context window instead of a person scrolling a page.

The sibling problem: you haven't even called anything yet

Result bloat gets the viral Reddit post, but there's a second, quieter version of the same problem that shows up before a single tool runs. Connect a handful of MCP servers - GitHub, Slack, a filesystem tool, a database tool - and you can be looking at 60,000+ tokens of tool definitions alone, loaded into context before the conversation starts. Scale that to an enterprise setup with twenty servers exposing twenty tools each, and you're serializing 400 tool schemas - production deployments have measured this past 100,000 tokens, just for definitions nobody's using yet.

Both problems compound in the same direction: the more MCP servers you connect, the more of your context window is spent on things the model isn't actually using on this particular turn.

What actually fixes the result problem

The fixes here live at the tool layer, not the protocol layer:

• Structured output over raw dumps. Configure extraction explicitly - title, main text, links, with a max length - instead of returning whatever the underlying API or page handed back.
• Pagination, always. A list endpoint without a page size is a standing invitation to return everything, someday, to someone.
• Push large intermediate data out of the model's context entirely. The frontier version of this is the code-execution pattern some agent harnesses now use: the model writes code that calls tool stubs in a sandboxed execution environment, large artifacts stay inside that environment, and only a summary or a structured result comes back to the model. A 50,000-token document doesn't have to touch the context window at all if nothing downstream needs the full text.

If you maintain an MCP server, this part is on you. No proxy, gateway, or client-side trick fixes a tool that insists on returning the entire payload every time.

What actually fixes the definition problem

This one lives above the individual server, and it's where curation architecture starts to matter:

• Lazy tool loading. Load tool names up front, full schemas only when a tool is actually invoked - one documented setup cut baseline token cost by 90% doing exactly this.
• Scope what's exposed, per use case. An allowedTools filter that restricts a session to filesystem.*, github.search, and nothing else is a completely different token budget than "every tool from every connected server, all the time."

This is the exact shape of the problem bundling exists to solve. A bundle is a named, curated set of MCP servers for a given job - not "every server this agent might ever need," just the ones this task actually uses. Bundler's LLM Tool Router takes it a step further for large bundles: instead of connecting every upstream MCP up front, an LLM decides which namespaces to actually activate for the current request, and can re-rank which ones stay active based on recent tool call history. A bundle with a dozen upstream servers doesn't have to mean a dozen servers' worth of tool schemas sitting in context on every single turn - only the ones the router decided were relevant stay connected.

To be precise about what that does and doesn't solve: routing which servers are active controls definition bloat. If one of those active tools still returns a 50,000-token HTML dump because nobody configured extraction on it, routing doesn't save you - that's still the tool author's problem to fix. The two are separate failure modes that happen to compound on the same context window, and it takes both a curated, routed set of tools and tools that return sane, structured results to actually keep a context window under control.

The pattern worth reaching for

If you're past one or two MCP servers, you're already paying the definition-bloat tax whether or not you've noticed it yet, and it only gets worse from here - every server you add is pure upside for capability and pure downside for context budget until something curates what's actually exposed per task. That's the argument for a gateway or bundler layer generally, independent of which one you reach for. Fix the tools you control to return less. Put the tools you don't control behind something that only activates what the current task needs. Do both, and a 24,568-character surprise stops being the default outcome and starts being the exception someone actually has to explain.