Ask an agent platform vendor how many tools you can wire up to a single agent and the answer is usually "as many as you need." That answer is optimizing for the sale, not for what happens when the agent has to pick the right tool at step four of a nine step task. Tool count is not a packaging detail. It is one of the strongest levers on whether the agent gets the right answer at all, and it is one you control directly through scope decisions before a single line of code ships.
Nobody selling agent platforms wants to lead with this, because the pitch is generality: connect everything, let the model figure out the rest. The engineering reality is narrower. As the number of tools available to an agent grows, the model's accuracy at picking the correct one, calling it with the right arguments, and sequencing it correctly against the others, gets worse. Not dramatically worse at first. Then worse in a way that is hard to diagnose because nothing crashes. The agent just quietly picks the wrong tool, or the right tool with a plausible but wrong argument, and the failure looks like a model problem when it is actually a scope problem.
Why more tools makes the model worse at using any of them
A tool call is a classification problem before it is anything else. The model reads a user request, reads a list of tool names and descriptions, and has to decide which one applies, or whether none do. Every tool you add is another candidate the model has to rule out on every single call, even the calls that have nothing to do with that tool.
Three things degrade as that candidate list grows:
Selection accuracy. Two tools with similar names or overlapping descriptions (a "search_documents" and a "search_policies" that both do full text search over PDFs) are exactly the kind of thing a model confuses under time pressure, and it has no time pressure, it has token budget and a prompt that is trying to describe forty things at once instead of six.
Argument correctness. Even when the model picks the right tool, it has to fill in the arguments correctly, and the more tool schemas are competing for attention in context, the more likely it borrows a parameter name or a format convention from a neighboring tool's schema. This shows up as calls that look reasonable and return garbage or an error the agent has to recover from.
Sequencing. Multi step tasks require the model to hold a plan across several calls. A longer tool list means a longer system prompt describing all of them, which competes with the actual task instructions for the model's attention within a fixed context window. The plan degrades before the individual calls do.
None of this is a defect in a particular model. It is a property of how tool selection works: the model is doing next token prediction over a prompt that includes every tool description you handed it, whether or not that tool is relevant to the current step. Give it thirty tools when six would do and you have made every single call in the session harder, not just the calls that touch the other twenty four.
The number nobody can give you, and why that is fine
There is no fixed ceiling, no "eleven tools and you are safe, twelve and you are not." It depends on how distinct the tools are, how good their descriptions are, how long the task runs, and which model is doing the selecting. A team building a specialist agent that only ever touches five clearly distinct systems, one for calendar, one for a document store, one for a ticketing queue, will tolerate a longer list than a team building a general assistant where three tools all do some flavor of "look something up."Chasing an exact number is the wrong exercise. The useful question is not "how many tools is too many," it is "does every tool in this agent's list get used on a meaningful fraction of the sessions that reach it." If a tool sits in the list for edge cases that come up once a quarter, it is not free. It is a permanent tax on every other call the agent makes, paid whether or not that edge case shows up this week.
What actually breaks in production, and where it shows up
The degradation is easy to miss in a demo because demos are short and the person running them knows exactly which prompt exercises which tool. Production traffic is neither short nor cooperative. Watch for:
- The agent calling a tool that is technically valid but is not the one a human would have picked, especially between two tools that do adjacent things.
- Arguments that are the right type and shape but the wrong value, a date range from the wrong tool's convention, a status string from a different tool's enum.
- Sessions that used to complete in two or three tool calls now taking five or six, because the agent is retrying after a wrong call rather than because the task got harder.
- Accuracy that was fine in testing with a narrow set of scripted requests and gets worse specifically as real users start asking things that sit between two tools rather than squarely inside one.
That last one is the trap. Testing tends to happen with clean requests that map obviously to one tool. Real usage is messier, and messier requests are exactly where an overloaded tool list costs you.
What to do about it before you build
The fix is mostly scope discipline, decided before the build starts, not a model swap after it is in production.
Scope the agent to a job, not a department. An agent that answers policy questions from one document set is a tight, well bounded tool list. An agent that also books meetings, also files tickets, and also pulls reports is three or four agents wearing one name tag. Split it. Each of the narrower agents will be more reliable than the combined one, even though the combined one looked more impressive on a slide.
Write tool descriptions like you are disambiguating for a person, not documenting an API. If two tools could plausibly apply to the same request, the description is the only thing that helps the model tell them apart. Vague, boilerplate descriptions ("retrieves relevant information") make every tool look like every other tool.
Route before you dispatch. For agents that genuinely need a wide range of capability, a first pass that narrows the request to a smaller relevant subset of tools, before the model that actually calls a tool ever sees the full list, keeps the working set small at the point where selection accuracy matters. This adds a step and a bit of latency. It is usually worth it once the tool count passes what a single, well written system prompt can describe without crowding out the task instructions.
Measure selection accuracy directly, not just end to end success. Build a small set of test requests where you know which tool should fire and log whether it did, separately from whether the final answer was right. An agent can get the right final answer through a wrong tool call and a lucky recovery, and that will not show up if you only measure outcomes. This is the same discipline described in building an evaluation set from your own documents, applied to tool calls instead of retrieved passages.
None of this is a reason to avoid agents with real tool access. It is a reason to treat the tool list as a design decision with a cost, made deliberately, rather than a checklist you fill in with every system the vendor happens to support. The platforms selling you the connectors have no incentive to tell you where the list gets too long. The incentive runs the other way. That is exactly why it belongs in the scoping conversation before anything ships, not in the postmortem after an agent starts calling the wrong tool on a request nobody scripted for.
