Too many MCP tools make agents worse. Here is the data.
2026-08-24
Connect a filesystem server, GitHub, a weather API, and a search API to your agent and you have done something subtle: you have added well over a hundred tool definitions to every single request that agent makes. The definitions ride along whether the task needs them or not. In our benchmark setup, six live servers produced 137 tool definitions, tens of thousands of tokens of schema and description text, resent on every model call.
That hurts twice.
The first cost is money and latency
Tool definitions are input tokens. An agent that makes ten model calls to finish a task pays for the full tool surface ten times. On our benchmark, a frontier agent running against the raw federation of six servers cost $0.260 per completed task. The same agent, same tasks, against a compiled six-tool surface: $0.052. Same accuracy, one fifth the cost, purely because the context stopped hauling dead weight.
The second cost is accuracy
With many servers connected, tools overlap. Two servers both expose something that looks like search. Three expose something that fetches a document by id. The model has to arbitrate between near-duplicates using nothing but their names and descriptions, written by different authors who never saw each other's work.
We built an overlap-rich task category to measure exactly this: tasks where several connected servers plausibly could answer, but one is clearly right. The raw federation picked the right tool 90% of the time. The compiled surface, where descriptions are rewritten with knowledge of the whole pool and near-duplicates are merged into explicit facades, scored 100%.
What actually fixes it
Four things, in increasing order of ambition:
- Prune. Most surfaces ship tools your agent will never call. Dead-tool elimination is the cheapest win available.
- Rewrite. Descriptions written for human API docs are not descriptions written for tool selection. Rewriting them, with the full pool in view so overlaps get disambiguated explicitly, is where much of the arbitration gain comes from.
- Consolidate. Families of near-duplicate tools (search_x, find_x, get_x) become one facade tool with an action parameter and a deterministic routing table. Fewer, clearer choices.
- Compress behind search. For very large surfaces, expose search_tools and call_tool instead of everything. This is the maximum-savings mode, with a caveat covered below.
The honest caveat
Indirection is not free for every model. A small agent model (we tested Haiku-class) scored 90.6% on the raw surface but 81.7% on the most aggressively compiled one. Frontier models absorb a level of indirection that smaller models pay for. If your agent runs on a small model, prefer a direct pruned-and-rewritten surface over search-based compression. We wrote up the full result in the token-usage post and the paper.
The through-line: a tool surface is a compilation target, not a pass-through. Treating it that way is worth 5x on cost and measurable points of accuracy before your agent's prompt changes at all.