Too Many Tools Hurt Agents

Connecting one more MCP server is the easiest way to make a working agent worse.

Nobody does it on purpose. The agent handles support tickets well, so someone adds the billing server. Then the CRM. Then the deployment tools, because the agent kept asking a human for things it could have looked up itself. Each addition is reasonable. The result isn't. The agent that was reliable in June is picking the wrong tool by September, and the post-mortem blames the model.

The model is usually innocent. What changed is the size of the choice it faces at the start of every request.

Every tool an agent might call has a definition: a name, a description, a parameter schema. In the standard setup, all of those definitions are loaded into the model's context before it reads a word of the request. Anthropic's worked example of a five-server setup (GitHub, Slack, Sentry, Grafana, Splunk) comes to 58 tools consuming roughly 55K tokens before the conversation starts, and Anthropic reports seeing definitions reach 134K tokens. That's a tax paid on every request, for tools the request will mostly never touch.

The tax is the visible part. The accuracy cost hides better. Anthropic notes that the most common failures in that setup are wrong tool selection and wrong parameters, especially between similar names. Its example pair is notification-send-user and notification-send-channel, two definitions that differ by one word and opposite intent. When Anthropic's Tool Search Tool loaded only the few tools a request actually needed instead of the whole catalogue, token use fell by about 85%, and accuracy on its internal MCP evaluations rose sharply: Opus 4 from 49% to 74%, Opus 4.5 from 79.5% to 88.1%. Same models. Smaller choice.

The catalogue is not the working set

Here's the distinction we think teams miss. A catalogue is everything the agent is allowed to reach, ever. A working set is what this request needs, usually three to five tools. Loading the catalogue to serve the working set confuses storage with attention. You wouldn't hand a new engineer the manual for every system in the building before their first ticket. You'd tell them where the manuals live.

So the fix is retrieval, applied to tools the way it's already applied to documents. A search step reads the request, ranks the catalogue, and loads a shortlist. The RAG-MCP study tested exactly this against a large pooled catalogue: with every definition in context, tool-selection accuracy sat at 13.62%; with retrieval narrowing the candidates first, it reached 43.13% accuracy, while prompt tokens fell by more than half. A 43% score is nothing to celebrate in absolute terms. The direction is the finding: the model didn't get smarter, the question got smaller.

A more recent shortlist study adds a useful wrinkle. On the BFCL benchmark, an adaptive shortlist that showed about seven tools per query, chosen per request, matched the coverage of showing fifty every time, 90.3% against 90.8%. The same study found the catch on ToolBench: a fixed shortlist of five found nothing at all on the hardest queries, where the right tool ranked sixth to twentieth, while the adaptive one, allowed to look deeper when the first pass was thin, still found 16.7% of them. Shortlists have to be able to widen. A retrieval step that can't miss loudly will miss silently.

It also means the raw count was never quite the villain. Fifty well-separated tools can be an easier choice than ten that overlap. What degrades selection is neighbours: tools whose descriptions promise nearly the same thing, so the model splits its confidence between them and picks by wording accidents. Count is just the easiest way to accumulate neighbours.

What we'd change first

Start by splitting the catalogue. A handful of tools get used on most turns. Those stay resident, loaded every time. Everything else is deferred: present in a registry the agent can search, absent from its context until a request actually calls for it. On most stacks this is configuration, not surgery.

Then consolidate. Anthropic's guidance on writing tools for agents is blunt that more tools don't always lead to better outcomes, and its remedy is to build the tool around the workflow instead of the API: one scheduling tool that checks availability and books, rather than separate tools for listing users, listing events and creating events that the model has to chain correctly every time. Every consolidated tool deletes several near-neighbours at once.

Descriptions get the same treatment. A good tool description reads like directions to a colleague: what it does, when to reach for it, and — the part everyone skips — when not to. "Use this to message one person. For a channel, use the channel tool." Two sentences like that do more for selection accuracy than a model upgrade, because most wrong-tool calls are really two descriptions that never agreed on the boundary between them.

Last, measure selection itself. Log which tool was chosen, which were on the shortlist, and which one the completed task actually needed. Wrong-tool rate is a metric you can watch fall as you defer, consolidate and rewrite. If it doesn't fall, the problem is somewhere else and you've learned that cheaply.

Where this bends

A six-tool agent doesn’t have this problem, and adding a search step to it buys latency and a new failure point in exchange for nothing. Anthropic’s own guidance puts the payoff at ten-plus tools, or once definitions pass roughly ten thousand tokens. Below that, load everything and spend your effort on the descriptions.

Retrieval also moves the failure rather than deleting it. If the right tool isn’t in the shortlist, the model can’t call it, and it will often complete the task with the wrong tool rather than report the gap. That’s why the widening behaviour matters, and why the resident core should be chosen from logs of what your agent actually calls, not from what the architecture diagram says it should.

And none of this rescues bad tools. Defer a confusing pair and they still confuse, just later and in a smaller room. The shortlist is a way to stop paying for the whole catalogue on every request. The catalogue still has to deserve the agent’s trust: one tool per job, boundaries written down, names that don’t collide.

Work with us

If your agent’s tool list has grown server by server and its wrong-tool calls have grown with it, the catalogue is where we’d start: what stays resident, what gets deferred, and which tools should never have been separate. Bring us the list through Trida AI’s intake.