All articles
MCPAI EngineeringAgentsContext WindowBest Practices
MCP tool bloat is eating your context — the tool-search pattern
Every MCP tool you register at session start burns context forever. Ship 40 and you have already spent 15-25k tokens before the user says hello. The tool-search pattern, and when to reach for it.
Eshwar Perumal Kumar29 August 20263 min read
Every model that supports tool-calling has a context budget, and every tool you register at session start burns some of that budget forever. Register 40 MCP tools and you have shipped 40 tool schemas, 40 descriptions, and 40 parameter blocks into every single turn — before the user has even said hello.
That is the MCP tool-bloat problem, and it is quietly killing agent responsiveness in half the deployments I have looked at this year.
## The math
A modest MCP tool weighs in around 200-500 tokens of schema + description. Ten of those and you have already spent 3-5k tokens per turn on tools the user probably will not use. Fifty and you are burning 15-25k tokens per turn on nothing. That is context you cannot get back for the user's actual work.
Worse: the more tools in scope, the more the model second-guesses which one to call, and the more time it spends on tool-selection versus reasoning. Latency goes up too.
## The three approaches
### 1. Static autoload (default, worst at scale)
Every tool is registered at session start. Zero code, worst context economy. Fine below 10 tools. Falls apart around 30.
### 2. Tool catalog (curated presets)
Group tools into named bundles (`billing_bundle`, `codegen_bundle`) and load a bundle based on user intent or route. Cheaper, but you now maintain a bundle map and lose fine-grained composition.
### 3. Tool search (dynamic discovery)
Ship a single meta-tool (`tool_search(query)` or `list_tools(keywords)`) that surfaces relevant tools on demand. The model calls the meta-tool first, then re-plans with the tools it actually needs.
We use approach 3 across our own MCP servers.
## Why tool search wins for us
The meta-tool costs maybe 300 tokens to keep in scope. It replaces registering 40 individual tools that would have cost 15-20k. That is a 50x context saving before the user has done anything.
The model does one extra hop ("search first, then call") — costs ~1s of latency for a well-designed catalog — but pays back on every subsequent turn.
Concrete pattern from what we ship:
```json
{
"name": "tool_search",
"description": "Fetch schemas for tools matching your need. Call with keywords or 'select:' for direct selection.",
"parameters": { "query": "string", "max_results": "number" }
}
```
The model calls `tool_search("send slack message")`, gets back the concrete `slack_send_message` schema, then calls it. Two hops instead of one, but the initial context stays lean.
## When NOT to use tool search
- Under 10 tools total. Static autoload is simpler and the context cost is negligible.
- Every tool is used on every turn (a pure workflow, not an agent). Static wins.
- Latency budget is punishing (sub-second first-token). The extra hop matters.
Everything else, tool search.
## One rule of thumb
If the *count* of your registered tools exceeds the number a human colleague would sensibly memorize, the model will not use them well either. Give it a search bar instead.