How many tools can an AI agent have before it picks the wrong one?

Past 30 to 50 tools. That is where Anthropic's documentation says Claude's ability to pick the right tool begins to degrade, and OpenAI's function calling guide sets its soft limit lower still, at fewer than 20 functions available when a turn starts. Both vendors document the effect. Neither prices it, so the arithmetic below is ours, and it does not land where we expected it to.

Thresholds, token counts and prices here were checked by Unity Horizon on 15 September 2026 against Anthropic's tool search documentation, its advanced tool use announcement, its pricing page and OpenAI's function calling guide.

How many tools is too many for one agent?

Neither vendor publishes a hard cap on accuracy. Anthropic's documented ceiling of 10,000 deferred tools per request sits far above the problem. What both publish is a soft limit, and OpenAI's is below the bottom of Anthropic's range.

Source	What it documents
Anthropic, tool search docs	"Claude's ability to pick the right tool degrades once you exceed 30-50 available tools"
OpenAI, function calling guide	"Aim for fewer than 20 functions available at the start of a turn at any one time", called a soft suggestion
Anthropic, tool search docs	Reach for tool search at 10 or more tools, or definitions over 10k tokens, or 200+ tools aggregated from MCP servers

Crossing the line takes one afternoon of config. Anthropic's own example of a five-server setup, GitHub, Slack, Sentry, Grafana and Splunk, is 58 tools and roughly 55,000 tokens of definitions before the model reads a user message.

We built Noxio's integrations with Booking.com, Airbnb, Expedia, VRBO, Hostelworld, Agoda, Trip.com, HRS and Tripadvisor, and Noxio connects to 100+ channels. Hand an agent two operations per channel and the catalogue is past the documented threshold before anyone writes a prompt. No design review would approve that. It would arrive one integration at a time, each one obviously worth having.

Why does a bigger catalogue make the model worse?

Tool definitions live in the prefix of every request. Nothing is held in reserve. The model re-reads the whole catalogue on every turn, and every entry in it stays a live candidate at every decision it makes. Forty tools means forty names, forty descriptions, forty argument lists and forty chances to be the closest match to a vague instruction.

Then the near-duplicates arrive. Aggregate three MCP servers and you get search_issues, find_issue and issues_query, written by three teams who never met, all defensible answers to "find the open bug". Anthropic's own guidance is to namespace by service and to consolidate related operations into fewer tools that do more. Read that as advice about the shape of the list, because no rewrite of a single description fixes a list that contains three ways to do one thing.

What does a full tool catalogue cost per turn?

Anthropic's worked example puts a large setup at about 77,200 tokens of context before any work begins, roughly 72,000 of them tool definitions, falling to about 8,700 with the tool search tool. Run both through the Claude Opus 5 list price of $5 per million input tokens, with a 5 minute cache write at 1.25x and cache reads at 0.1x.

Line, Claude Opus 5	Full catalogue, 77,200 tokens	Deferred, 8,700 tokens
First turn, cache write at 1.25x	$0.482	$0.054
Each later turn, cache read at 0.1x	$0.039	$0.004
A 20 turn run, one write and 19 reads	$1.22	$0.14

So deferring the catalogue saves about $1.08 on a 20 turn run. Set that against the run it sits inside: 500,000 input and 50,000 output tokens on Opus 5 is $3.75, an anchor we have used since the piece on automating a government portal that has no API.

A dollar a run. That is the entire token argument, and it is the stronger of the two arguments on paper.

Is deferring tools a cost decision or an accuracy decision?

Price the accuracy side and it comes out smaller. On Anthropic's MCP evaluation, Claude Opus 4.5 goes from 79.5% to 88.1% with tool search on, so the failure rate falls 8.6 points. If every failed run were rerun once, that is 0.086 x $3.75, about 32 cents of avoided inference per run. Less than the dollar the tokens saved.

The token saving is real and it goes in a spreadsheet. The accuracy saving, priced the same way, is a third of it. Neither one is the reason to do this.

An agent that picks the wrong tool calls something. As we wrote in how you stop an AI agent from doing the same thing twice, the model call is the layer that retries safely and the tool call is the layer that carries the side effect: a refund, a message to the wrong guest, a filing, a row written into somebody else's database. We built OFFSET, which files declarations directly to the ΑΑΔΕ portal. There is no cache read anywhere in the price of getting one of those wrong.

The tokens cost a dollar. The wrong tool call costs whatever it touched.

How much of the published accuracy gain should you believe?

Believe the direction. Hold the 25 point figure loosely until you have run it on your own catalogue.

Anthropic published two pairs on 24 November 2025: Claude Opus 4 from 49% to 74%, Claude Opus 4.5 from 79.5% to 88.1%, on its own MCP evaluation. That is a vendor measuring its own feature on an eval nobody else can run.

Then read the validity audit of tool-calling evaluation posted on 30 June 2026 by Bhat, Vaghasiya, Mohsin and Aali. Across four benchmark families and 496 expert-reviewed tasks they found an 18.5% misalignment rate between evaluator and human judgment. On LiveMCPBench, 23 repeated evaluations of the same setup scored anywhere from 57.9% to 76.8%, a spread of 18.9 points. Anthropic's internal eval was not among the four audited, so nothing there falsifies its numbers. It does mean a 25 point gain reported once, when one public MCP benchmark swung 19 points across 23 runs of a single setup, is a reason to measure rather than a number to quote.

Who gains from the fix, and who was never in this conversation?

An agent that drives one system with six tools has no problem to solve here, and the whole feature is overhead for it. The team that mounted five MCP servers because each was one line of YAML carries 55,000 tokens and the selection problem that arrives with them, and nobody chose that in a design review.

The same split runs through the vendors. A tool provider who ships eight operations that do real work is easy to drive. A provider who mirrors forty REST endpoints one for one has handed its integration work to your model, and your model does that work badly, in public, on a booking.

What breaks when you turn tool search on?

Six things the API documentation spells out.

• You still send every tool definition in the tools array on every request. defer_loading controls what enters the context window, not what leaves your server.
• A tool with defer_loading: true cannot carry cache_control. The API returns a 400. Put the breakpoint on a non-deferred tool.
• At least one tool has to stay non-deferred, normally the search tool. Defer everything and the request is rejected.
• Discovery adds a step, and the definitions it loads bill as input tokens. The model searches, reads up to five matches by default, then calls.
• The computer use and browser use toolsets take defer_loading per member inside configs, not on the entry, and they expand as a unit when found.
• The regex variant caps a pattern at 200 characters, and a search that matches nothing returns an empty result rather than an error, so a badly named tool is invisible instead of loud.

The empty result is the one that will cost you an afternoon. A tool the search cannot find fails in a way that looks exactly like a model being stupid, so you go and rewrite the prompt.

What should you do about your own catalogue this week?

Count it. Not the servers. The tools, and then the tokens those tools cost: the token counting endpoint gives you that number before you spend anything, and the response usage gives it to you after. Compare the count against 30 and 50, and the token figure against the 10k line in Anthropic's own guidance. Then keep the three to five tools your agent reaches for on every run loaded and defer the tail, namespaced by service so one search pulls a whole group.

We have not measured selection accuracy against catalogue size on our own systems, so every accuracy figure above belongs to Anthropic and the audit that questions the method belongs to somebody else. The cost table is arithmetic over published list prices rather than a bill we paid. If you have run the same agent at 20 tools and at 80 and counted the wrong calls, we would rather print your number than reason around it.

How many tools does your agent see on turn one, and what is that in tokens? If nobody has counted, counting is where we would start.