MCP context bloat

MCP context bloat is the problem where connected Model Context Protocol servers consume tens of thousands of tokens of tool definitions before a customer has said anything. Every connected server contributes each tool's name, description, and full parameter schema to the prompt, and that overhead is paid again on every turn.

The pattern got its name as MCP adoption spread through early 2026 and teams discovered that connecting a dozen servers could leave less room for the actual conversation than for the catalog describing what the agent could do. Anthropic's advanced tool use and code execution work in November 2025 introduced the two standard responses, deferred tool loading and calling tools from generated code, and MCP.Directory's May 2026 treatment noted that progressive disclosure is the architectural pattern underneath both. Bloat is not only a cost problem. It crowds out retrieval, it slows the first response, and it makes tool selection measurably harder.

Where the tokens go

A tool definition is not a name. It is a name, a natural-language description of when to use the tool, and a JSON schema for every parameter with types, enums, nested objects, and per-field descriptions. A single well-documented tool for creating a refund can carry more prompt text than the instructions that govern the whole agent. A server exposing dozens of operations across an order system pays that cost once per operation.

The overhead is also fixed rather than amortized. Conversation history grows, but tool definitions sit in the prompt at full size on the first turn and every turn after, regardless of whether the agent calls anything. A deployment where the schemas consume a large share of the context window is paying for that share on every single model call in every conversation, which is why the effect on spend is larger than the raw token count suggests.

Why bloat compounds with each connected server

MCP made integration cheap, and cheap integration invites accumulation. A support agent gets an order server, a subscription server, a payments server, a shipping server, a CRM server, a ticketing server, and a search server, each added by a different person solving a different problem. None of them removes anything.

What compounds is not just volume but redundancy. Three servers each expose a way to look up a customer. Two expose overlapping refund operations with different field names. The prompt now contains several near-duplicate descriptions of nearly the same capability, which costs tokens twice: once to state them, and again in the reasoning the model spends distinguishing them. Nobody audits the set, because each server was individually justified and the cost of the whole is invisible in any single review.

The second-order cost of too many tool choices

The token bill is the visible cost. The accuracy cost is larger and harder to attribute. Tool calling is a selection problem, and selection gets worse as the candidate set grows and the candidates get more similar. Given a handful of clearly distinct tools, a model picks correctly nearly all the time. Given hundreds of tools where a dozen could plausibly apply, it picks something defensible but wrong often enough to matter.

The failure looks like an agent calling a read-only search tool when it should have called the authoritative lookup, or picking the deprecated refund endpoint that a legacy server still exposes. These are not reasoning failures in any interesting sense. They are the predictable result of asking a model to disambiguate a catalog nobody curated. And because the schemas occupy window that retrieved knowledge would otherwise use, bloat also drives context rot, so the same deployment gets worse at grounding and worse at tool choice at the same time.

Deferred loading and tool search

The fix is to stop treating the tool catalog as something the model must read in full before it can act.

Tool search. Expose a small set of always-loaded primitives plus a search facility over the remaining catalog. The agent describes what it needs, retrieves the handful of matching definitions, and loads only those schemas into context. The catalog can then grow without the prompt growing, because relevance rather than availability determines what gets loaded.

Code mode. Rather than exposing every operation as a separate callable, let the model write code that invokes the underlying APIs, with the definitions available to that code rather than inlined in the prompt. This collapses hundreds of near-duplicate function definitions into a much smaller interface and moves multi-step orchestration into the generated program, where intermediate results never enter the window at all.

Both are instances of progressive disclosure: reveal capability when it becomes relevant instead of up front. That framing also explains why partial fixes disappoint. Trimming descriptions shaves the constant without changing the shape of the problem, while deferred loading changes the shape.

Practical hygiene for a support deployment

Most teams do not need a new architecture to recover a large share of their window. They need to stop connecting servers whole.

Scope the tool set per use case. An agent handling order status does not need payment mutation tools, and one handling billing does not need shipping label creation. Exposing per-agent subsets rather than the union of everything connected is the single highest-yield change, and routing through an AI gateway makes those subsets enforceable rather than aspirational.

Then measure. Track assembled prompt size broken into system instructions, tool definitions, retrieved knowledge, and conversation history, and review the split. Teams that do this usually find one server contributing a disproportionate share and one set of tools that has never been called in production. Clearing stale definitions mid-session belongs alongside context compaction in the same maintenance loop, and both feed directly into time to first token, since prefill cost scales with everything in the prompt whether the agent uses it or not.