Connect a typical production agent to ten MCP servers today and it can consume 100,000 tokens before the user has typed a single word. That is not a rough estimate - by Q1 2026, a production agent connecting to between five and twenty servers, each exposing five to fifty tools, each with a JSON schema rarely under 300 tokens and often over 1,000, hit that ceiling on every session start. Ten servers at twenty tools and 500 tokens each is 100,000 tokens, charged on every turn.
The MCP maintainers acknowledged this directly in their August 22 roadmap update, listing progressive tool discovery as a first-class priority for the next specification cycle. As MCP host applications connect to more servers and accumulate hundreds or thousands of tools, naive approaches to tool management break down. Loading every tool definition into the model's context window upfront wastes tokens, increases latency, and degrades model performance. Passing large intermediate results through the model between sequential tool calls compounds the problem.
The roadmap did not ship a fix. It named the problem. That distinction matters for teams running agents in Slack or Teams right now - because the workarounds are real, measurable, and deployable today, while the protocol-level solution is still being designed.
Why MCP tool discovery becomes a context tax
Progressive discovery is the pattern where an agent learns a tool exists without loading its full schema until it decides to use it. Progressive tool loading defers the body of an MCP tool definition until the agent needs it, instead of placing every connected tool's full schema into the system prompt at session start. The agent still discovers what tools exist, but the verbose schemas, parameter descriptions, and example payloads load on demand.
The reason this matters now is scale. By April 2026, there were over 10,000 enterprise MCP servers and more than 97 million SDK downloads across providers. More integrations means more tools per agent, and tool schemas are not small.
There are three failure modes when you skip progressive loading:
- Cost creep. Tool catalogs are present on every turn. A 100,000-token system prompt on a model priced at $10/million input tokens adds $1 to every single exchange. A team sending 500 agent messages a day is burning $500 daily in catalog overhead alone.
- Performance degradation. Long inputs push relevant content further from the model's attention. Studies on attention in long-context models consistently show retrieval quality drops as context grows - your agent gets worse at the actual task as your MCP footprint grows.
- Security surface expansion. If you have an agent that is only supposed to do analysis, there is no reason it needs access to data write tools. The risk of agents going off track - from prompt injections to just trying to be helpful - is real. Injecting every tool definition upfront hands the model a larger action surface than any single task requires.
What the August 2026 roadmap actually proposed
The proposed approach is for a server to expose a small entry-point set of tools first and reveal more of its catalog as the conversation narrows, instead of pushing its entire tool list into the model's context on connect. The maintainers describe it as an effort they are starting, with no mechanism specified yet.
The roadmap covers five priority areas: agentic messaging primitives, HTTP-native transport unification and hardening, agent identity and enterprise-ready security, improved primitives, and improved SDK developer experience. Tool discovery falls under "improved primitives." The honest reading of the document is that it is a commitment to expedite review of relevant Specification Enhancement Proposals, not a feature shipping in the next six weeks.
Five weeks after the 2026-07-28 release turned remote MCP servers into ordinary HTTP workloads, MCP core maintainers David Soria Parra and Den Delimarsky published the August 22 roadmap. It doesn't announce a new spec version - it names what the core maintainers and working groups will actually spend review time on next, and which SEPs get expedited attention.
That is still significant. A priority named in a roadmap by the lead maintainers of a protocol with close to half a billion SDK downloads a month is a strong signal about where implementors should put engineering time. But teams cannot wait for the spec.
What teams can do before the spec ships
Three approaches work today, each with different trade-offs:
| Approach | How it works | Token reduction | Complexity |
|---|---|---|---|
| Anthropic Tool Search | Server exposes a search tool; schemas load with defer_loading on demand |
~85% | Low - enable in Claude Code v2.1.7+ |
| Cloudflare Code Mode | Model writes code against a typed SDK; collapses 100s of endpoints into 2 tools | ~99.9% | Medium - requires server-side SDK wrapping |
| Proxy with meta-tools | Lightweight proxy exposes describe_tools and use_tool; full schemas load on call |
60-90% depending on catalog | Medium - add a proxy layer |
| Tool allow-lists | Client loads only the subset of tools relevant to the current workflow | Proportional to subset size | Low - configuration change |
The technique is a context engineering move, not a protocol change. It works on the current MCP spec because MCP already separates discovery from invocation. You do not need a new spec version to implement progressive loading today.
The allow-list approach deserves more attention than it gets. If a team's Slack-connected agent handles three workflows - answer a support question, file a Jira ticket, summarize a doc - it probably needs twelve tools, not two hundred. Trimming the loaded set to the task at hand is free, requires no new infrastructure, and reduces the attack surface at the same time.
Beagle in action#engineering-ops, 10:30amThe non-obvious point here is organizational: most teams that have hit context ceiling problems report discovering them via cost anomalies, not performance complaints. A developer notices the LLM bill jumped, traces it to a new MCP server added to the agent config, and only then realizes that adding one server with fifty tools added 50,000 tokens to every message the agent processes. The fix is often a ten-minute config change, not an architectural rewrite.
A teammate like Beagle that connects to multiple Slack-adjacent services - Jira, Notion, Linear, GitHub - only routes the right tools into context for the task at hand. That is the practical shape of progressive discovery applied to a real team workflow.
MCP tool discovery: common questions
What is progressive tool discovery in MCP?
Progressive tool discovery is a pattern where an MCP client defers loading a tool's full schema until the agent selects that tool, rather than injecting all tool definitions at session start. The agent still knows what tools exist, but only loads the verbose parameter schemas on demand. This keeps context proportional to the task rather than the full catalog size.
How many tokens do MCP tool definitions use?
A typical production agent connecting to between five and twenty MCP servers, each exposing five to fifty tools, faces JSON schemas rarely under 300 tokens and often over 1,000. A ten-server, twenty-tool-per-server catalog at 500 tokens per tool consumes 100,000 tokens per session start - before any user input reaches the model.
Does the August 2026 MCP roadmap ship a fix for context bloat?
Not yet. The roadmap proposed that a server expose a small entry-point set of tools first and reveal more as the conversation narrows. The maintainers describe it as an effort they are starting, with no mechanism specified yet. Workarounds - tool allow-lists, defer_loading, Code Mode - are available in the current 2026-07-28 spec.
Why does a large tool catalog make agents less accurate?
Loading hundreds of tool definitions pushes the user's actual task further from the model's active attention. Long-context models show degraded retrieval accuracy as context grows. A large catalog also multiplies prompt injection surface - malicious content in one tool's description can influence decisions involving completely unrelated tools.
Is this a problem only for large enterprises?
No. Preloaded catalogs broke down because tool surface scaled faster than context windows did. A five-person engineering team using a handful of popular MCP servers - GitHub, Linear, Notion, Slack, a database connector - can easily accumulate enough tools to hit 50,000-token catalog overhead. The problem scales with the number of connected services, not the headcount.