What is the too-many-tools problem?
An MCP server describes each tool with a name, a description and an input schema. Those descriptions are text, and the model has to read them. Anthropic's engineering team states the default behaviour plainly: “Most MCP clients load all tool definitions upfront directly into context.”
That creates two costs, both named in the same post.
- Tool definitions overload the context window. The post says tool descriptions occupy more context window space, increasing response time and costs, and that an agent connected to thousands of tools would need to process hundreds of thousands of tokens before reading a request.
- Intermediate results pass through the model. When one tool's output feeds the next call, the data is read and written again by the model. The post's example is a meeting transcript that flows through twice, which for a two-hour sales meeting could mean processing an additional 50,000 tokens.
The accuracy figures below point to a third cost: choice. In Anthropic's evaluations the model picked correctly less often with every definition loaded than with tool search turned on.
How big is the problem? The published numbers
These figures come from two Anthropic engineering posts. They describe Anthropic's own setups and tests, not a universal benchmark.
| Measurement | Figure | Source |
|---|---|---|
| Tool definitions in a five-server setup | 58 tools, about 55K tokens before the conversation starts | Advanced tool use, November 24, 2025 |
| Largest tool-definition load Anthropic reports seeing | 134K tokens before optimization | Advanced tool use |
| Token use with the Tool Search Tool | An 85% reduction, while keeping access to the full tool library | Advanced tool use |
| Accuracy on MCP evaluations with tool search enabled | Opus 4: 49% to 74%. Opus 4.5: 79.5% to 88.1% | Advanced tool use |
| Example workflow rewritten to use code execution | 150,000 tokens down to 2,000, a saving of 98.7% | Code execution with MCP, November 4, 2025 |
What does search-then-load mean?
Search-then-load is a simple change in order. Instead of handing the model every definition and letting it choose, you hand it one small search tool. The model describes what it needs, gets back the few tools that match, and only those definitions enter the context. It is the same idea as a person using a search box instead of reading the whole catalog.
Anthropic calls the general idea progressive disclosure. In its words, presenting tools so that models can read tool definitions on-demand keeps the context for the task itself.
What are the ways to do search-then-load?
The sources describe three. They work at different layers, so they can be combined.
1. Tool search in the model API
Anthropic's Tool Search Tool lets a developer mark tools with defer_loading: true to make them discoverable on-demand. Deferred tools are not loaded at the start; the model finds them through the search tool when a task calls for them. This is where the 85% figure above comes from.
2. A search tool on the server
A server can offer search itself. The code execution post notes that a search_tools tool can be added to the server to find relevant definitions, with a parameter that lets the agent select the level of detail it needs.
3. Code execution
The agent writes code that calls tools, instead of calling each tool through the model. Tools are presented as code on a filesystem that the agent reads on demand, and because the code passes data from one tool to the next, that data does not have to be read by the model on the way. This is the approach behind the 150,000 to 2,000 token example. It needs a safe place to run the code, which is its own engineering work.
What can a server author do about it?
You do not control the client, but you control what your server asks the model to read.
- Publish jobs, not endpoints. Five tools that match what people ask for beat fifty that mirror every route in your API.
- Write descriptions for selection. Say what the tool does and when to use it. Keep it short: every word is paid for in every session.
- Split by audience. A support agent and a finance agent rarely need the same tools. Separate servers, or separate keys with different tool sets, keep each context small.
- Measure. A call log shows which tools are actually used. Tools nobody calls are context nobody needed.
Related: how to choose the first tools for a company server, and why MCP exists.
Sources
Every figure and dated fact above comes from one of these pages. Follow the link to check it.
- Code execution with MCP: building more efficient agents. Anthropic Engineering, November 4, 2025.
- Introducing advanced tool use on the Claude Developer Platform. Anthropic Engineering, November 24, 2025.
- Model Context Protocol specification, version 2025-06-18. modelcontextprotocol.io.
