The most common reflex when setting up a new agent is to switch on everything you have. The more it can do, the better it will work, or so the thinking goes.
The result comes out the other way round. As the tool list grows, the agent's accuracy drops, its cost climbs and finding bugs gets harder.
Tool definitions enter the context too
The model does not see tools from somewhere separate. Every tool's name, description and parameter schema is part of the text placed in front of the model on every call.
That has two costs. You pay on every call for the definitions of tools that will never be used. And those definitions occupy space that was meant for information that would actually help the job.
In crowded setups the space taken by tool definitions can be many times larger than what the user typed. Without anyone noticing, the same crowd gets sent again on every request.
Choosing gets harder
The second problem is sneakier. When picking the right tool, the model looks only at the name and the description.
If two tools resemble each other the choice blurs. Either the wrong tool gets called, or the right tool gets called with parameters borrowed from another tool's schema. The second is especially annoying, because the call looks successful and produces the wrong result.
The measured side
This topic now has numbers. A study on a registry of three hundred and seventy tools found that narrowing the list per query, instead of showing a fixed list for every query, improved the result.
In the setup showing a fixed five tools, tool selection accuracy was 87.1 percent, and in the setup that narrowed the list per query it rose to 93.1 percent. On medium-difficulty questions the gap widened further, 60.9 percent against 76.8 percent (Repantis et al., How Many Tools Should an LLM Agent See?).
The study's real emphasis is not on giving a threshold number. It argues that the number of tools shown should change with the difficulty of the question, and it reaches nearly the same coverage as a fixed list of fifty tools with an average of seven.
The hidden cost of adding a tool
We ran into something else on our side, and we have not seen it discussed much.
When we connected an external set of tools, tool calling started failing outright on some providers. The cause was not the number of tools. It was the shape of the schemas. A field that could take more than one type, option lists that were not text and unrecognised format tags were being rejected.
The fix was to simplify the schemas and send only the common subset every provider understands.
The cost of adding a tool is not only tokens. Every new tool also widens the compatibility surface, and the day you want to switch models, that surface is waiting for you.
"How many tools" is the wrong question
Instead of hunting for a fixed number, look at the ways to narrow the list.
Keep the role narrow. One agent, one job. Splitting into narrow roles instead of one agent that does everything shrinks the tool list on its own.
Merge similar tools. Three variants of the same job do not have to be three separate tools. One tool and a parameter may be enough.
Write names and descriptions that differ. The model chooses from the description. Do not expect it to choose between "updates a record" and "modifies the record".
Turn off what is not used. Look at how often each tool gets called. A tool that has not been called in three months should not stay on the list.
A narrow list is also narrow authority
There is a security side to this, and it usually comes second.
An agent's tool list is the list of what the agent can do. Narrowing it does more than improve accuracy. It shrinks the surface the system can touch.
That is why tool selection should be treated as a design decision rather than a performance setting. Know what you are turning on when you turn it on, and turn off whatever no longer has a reason.
Sources
Repantis et al., How Many Tools Should an LLM Agent See? A Chance-Corrected Answer