Why does an agent's tool-selection accuracy fall as its catalog grows from 20 to 400 tools?

## What is being measured Tool-selection accuracy, in the narrow sense used here, is a single-turn measure: given one user request and one catalog of tool definitions, does the model call the tool a human labeller marked as correct? It deliberately excludes whether the whole task eventually succeeded, because an agent can recover from a bad first pick, and can also fail a task for reasons that have nothing to do with which tool it chose. Isolating selection is what makes the decay visible at all. ## The shape of the curve The decay is not linear and not smooth. Small catalogs — roughly a dozen or two well-separated tools — sit near the model's ceiling, and adding a few more costs almost nothing. Somewhere past that, accuracy starts sliding, and it slides fastest when the newly added tools are near-neighbours of existing ones rather than genuinely new capabilities. A realistic enterprise pattern: 20 tools at about 94% correct selection, 400+ tools at about 61%. The exact numbers depend on the model, the catalog and the request mix, which is precisely why you measure the curve for your own catalog rather than trusting a published figure. ## Force one: crowding the context Tool definitions are just tokens in the prompt. A definition with a name, a paragraph of description and a JSON Schema of parameters commonly costs several hundred to a thousand tokens. Four hundred of those can be tens of thousands of tokens spent before the model has read a word of the user's request, on every single turn of the conversation. Three consequences follow. Cost and latency rise on every call, whether or not any tool is used. Prompt-cache economics get worse as the static block grows. And the relevant definition ends up somewhere in the middle of a very long, very homogeneous list — the position where long-context recall is empirically weakest, the failure the field calls context rot or being lost in the middle. ## Force two: semantic overlap Crowding is the obvious effect; overlap is usually the bigger one. Independent teams contribute tools, and at scale their vocabularies collide. HR ships a leave-request tool; payroll ships a wage-advance tool that its own docs describe in terms of "time off" and "pay period"; facilities ships a desk-booking tool whose description mentions "absence". None of them is wrong in isolation. Together they present the model with three defensible answers to "I'm off next Tuesday, sort it out", and nothing in the catalog says which one owns that intent. This is why polishing one tool's wording rarely moves the needle: the error lives in the *relationship between* definitions, not inside any one of them. ## Why a bigger context window is not the answer The reflex answer — "windows are huge now, just load everything" — misses both forces. A larger window does nothing about overlap; the three time-off candidates are equally ambiguous whether the prompt is 30k or 300k tokens. And it makes crowding worse rather than better, because the tokens are still paid for on every turn and long-context attention degradation is exactly what large windows expose you to. Capacity to fit the catalog is not the same as capacity to discriminate within it. ## What the decay costs you A wrong selection is not a free retry. The tool runs, so a wrong pick can have side effects — a payroll advance requested when the user wanted leave booked. It burns turns and tokens as the agent notices and backs out. And it degrades trust in ways users report as "the assistant is unreliable" long before any dashboard shows it, because the end-task sometimes still completes. ## The structural responses Everything that actually works reduces how many definitions are in front of the model at decision time, or makes the survivors distinguishable. Server-side tool search over deferred definitions keeps the catalog out of the prompt and injects only the few that match. Progressive disclosure loads a one-line metadata tier per tool and the full usage instructions only after activation. Namespacing and toolsets separate the colliding pairs by name and by which ones are eligible at all for a given role or request class. And an admission policy — a new tool has to earn its place against a labelled selection suite — stops the catalog from eroding quietly as teams keep adding to it.