How Many Tools Should an AI Agent Have? What the Evidence Says

How many tools should an AI agent have is no longer a hypothetical question. MCP servers can expose hundreds of tools to one agent, and every framework now ships with tool registries, so builders have to decide how much of that library an agent should actually see. Three 2026 sources give a sharper answer than the usual "it depends": Anthropic's tool-design guidance, a chance-corrected benchmark paper, and a 960-call experiment on real business scenarios. Together they say the important number is not how many tools your agent has, but how many it is shown for each query, and how well those tools are designed. Source

The short answer

No source supports a single magic number for total library size. What the evidence supports: keep the working menu small and relevant per task, consolidate tools around workflows rather than API endpoints, and validate arguments, because selection accuracy is rarely the failure that hurts. A large central registry is fine if a retrieval layer filters it down to a short list per query. Source

Anthropic's case for fewer, consolidated tools

Anthropic's engineering post on writing effective tools starts from a constraint: LLM agents have limited context, while computer memory is cheap. A tool that returns every contact in an address book forces the agent to read each entry token by token, which wastes that limited context on irrelevant information. Their recommendation is a few thoughtful tools targeting specific high-impact workflows, matched to your evaluation tasks, then scaled up from there. Source

The practical technique is consolidation. Instead of list_users, list_events, and create_event, build one schedule_event tool that finds availability and schedules. Instead of read_logs, build search_logs, which returns only relevant lines with surrounding context. Instead of get_customer_by_id, list_transactions, and list_notes, build get_customer_context, which compiles a customer's recent relevant information in one call. Each consolidated tool handles several operations under the hood and keeps intermediate outputs out of the agent's context. Source

Anthropic also warns that too many tools, or overlapping ones, distract agents from efficient strategies. Their fix for large libraries is namespacing: grouping tools under common prefixes, by service (asana_search, jira_search) or by resource (asana_projects_search), so agents can tell boundaries apart. They note that prefix versus suffix naming had non-trivial effects in their own tool-use evaluations, and recommend choosing a scheme based on your evals rather than convention. This is vendor guidance from the team behind Claude, not a neutral benchmark, but it matches what the independent research below found. Source

The benchmark answer: it is about the shortlist, not the registry

A June 2026 arXiv paper, "How Many Tools Should an LLM Agent See? A Chance-Corrected Answer," reframes the question. Before an agent can use a tool, a retrieval system picks which candidate tools to show it. Show too many and the model struggles to choose; show too few and the correct tool never appears. The authors evaluate the shortlist size itself using a chance-corrected metric called Bits-over-Random, which asks whether success at a given depth beats what random selection would achieve at that depth, across registries from 20 to 3,251 tools. Source

The headline result: on the BFCL benchmark with 370 tools, a learned per-query policy nearly matched the coverage of always showing 50 tools, 90.3% versus 90.8%, while showing only 7 tools on average. On ToolBench with 3,251 tools, a fixed shortlist of 5 achieved higher aggregate coverage but found nothing on hard queries where the correct tool ranked 6th to 20th; the adaptive agent recovered 16.7% of those by searching deeper. Downstream validation with Claude Sonnet 4.6, as reported by the authors, showed shorter adaptive lists also improved the model's ability to pick the right tool: 93.1% versus 87.1% when always shown 5, widening to 76.8% versus 60.9% on medium-difficulty queries where the correct tool was present but not ranked first. These are the paper's own reported figures, from a deliberately simple RL agent the authors describe as a probe of the metric rather than a production system. Source

The counterpoint: selection held up, arguments did not

An October 2026 experiment by Avi Santoso tested the assumption directly. Three open-weight models (Mistral Small 3.2, Qwen3-30B-A3B-Instruct, GPT-OSS-20B) each ran 16 business scenarios with tool menus of 3, 5, 10, 20, or 48 tools, repeated four times per combination for 960 calls. The correct tool was always in the menu; the rest were distractors. Source

The result cut against expectations. Models selected the correct tool in 952 of 960 calls, a 99.2% selection rate, and accuracy did not fall as menus grew: 96.9% with 3 tools, 100% with 5 and 10, 99.5% with 20 and 48. But complete success, meaning correct tool, correct arguments, executed action, expected state change, was only 88.3% overall. Failures clustered after selection: a model picked the right ticket tool but passed "Remote Support" where the system required "remote-support", or supplied several unit IDs where one was required. Santoso's practical conclusion: showing an agent around 5 to 10 relevant tools keeps its working menu focused, and for business-critical actions, validating IDs, dates, and status values matters more than shrinking the tool count. Worth noting this was one experiment with three smaller open models on structured business scenarios, not frontier models on open-ended tasks. Source

Reconciling the three

The apparent disagreement dissolves once you separate three decisions. First, registry size: how many tools exist in total. Both the paper and the experiment suggest a large registry is workable. Second, shortlist size: how many tools the agent sees per query. Here the evidence agrees: keep it small and relevant, roughly single digits to low tens, delivered by retrieval rather than a fixed dump. Third, tool design: Anthropic's consolidation and namespacing reduce confusion at any scale, and the 960-call experiment shows that even perfect selection fails when arguments are wrong, so schema design and validation belong in the same conversation as tool count. Source

Our read

This section is our assessment, not the sources' claims. For teams building production agents, the actionable order of operations is: consolidate tools around workflows first, put retrieval in front of the registry second, and add argument validation third. Tool count debates usually skip straight to the second step. The Sonnet 4.6 downstream numbers in the arXiv paper, 76.8% versus 60.9% on medium-difficulty queries, are the strongest signal that shortlist quality beats shortlist size, and they deserve a place in your own eval harness rather than blind trust. The failure mode Santoso documented, right tool with wrong arguments, is exactly the class of error an AI agent observability checklist is built to catch, since it only shows up when you log tool inputs, not just tool names. And if your tool surface comes from MCP servers, the same "small relevant menu" principle doubles as a security control, a point our MCP server security best practices post makes from the threat-model side. Tuning the harness around these decisions is covered in our agent harness tuning notes.

Bottom line: if you need a number to start with, the evidence points to 5 to 10 relevant tools shown per query, from a registry that can be as large as retrieval quality allows. Measure selection and argument accuracy separately, because they fail for different reasons.