How many tools should an AI agent have? Does a larger toolset reduce selection accuracy?

There is no universal optimal number of tools for every AI agent. The practical rule is: at each decision point, show the model the smallest toolset that is sufficient for the current step. A platform may own dozens or hundreds of tools without placing the entire catalog in one prompt.

A larger toolset can reduce selection accuracy when tool names, descriptions, or capabilities overlap; schemas are ambiguous; irrelevant tools remain visible; or the context becomes long and noisy. Count alone, however, does not determine quality. Twenty clearly separated tools may be easier to select from than five near-duplicates. For production, start by benchmarking roughly 5–15 active tools per step as an internal heuristic, then adjust using observed results. This is not a model limit or an industry standard.

When discussing how many tools an agent has, separate three layers:

• Tool catalog: every connector, API, and action supported by the platform. A large catalog is not directly harmful when those definitions are not all sent to the model.
• Authorized tools: the tools the agent or user may call under role, tenant, workflow, and policy constraints. This is a security boundary.
• Active candidate set: the names, descriptions, and parameter schemas actually presented to the model in the current turn. This is the choice space that directly affects accuracy, tokens, latency, and irrelevant calls.

For example, a customer-service platform may expose 80 actions. A support agent could be authorized for 25, yet an order-lookup step only needs customer.search, order.get, shipment.track, and ticket.add_note. If the workflow later reaches a refund step, the router can load a different group while policy determines whether the agent can execute an action or only create a draft.

The model selects a tool using signals from the request, tool name, description, and argument schema. Anthropic likewise documents that the model decides from the user request and tool description. As the candidate set grows, several types of noise can appear:

1. Semantic overlap: search_customer, find_contact, and lookup_account all seem plausible for the same request.
2. Granularity mismatch: a broad manage_order tool beside narrow tools such as order.cancel and order.update_address creates an unclear boundary.
3. Description collision: several descriptions merely say “manage data” without when-to-use and when-not-to-use guidance.
4. Schema ambiguity: free-form action, payload, or query parameters map many intents to the same contract.
5. Irrelevant exposure: finance, HR, and deployment tools appear during a customer-support task.
6. No-tool confusion: the agent calls the closest available tool when it should answer directly, clarify, or refuse.

Fewer tools help only when the reduced set still contains the correct capability and does not prevent task completion.

Four questions help shape the active set:

• How many intents are valid in this step? An order-read step does not need write tools.
• How distinct are the tools? Five synonyms may be harder than fifteen tools from clearly separated domains.
• What happens after a wrong choice? A read-only step may tolerate a broader candidate set. Payments, access changes, and production deployments need narrow allowlists and independent policy enforcement.
• Can routing happen first? If the domain or workflow state is known, load only the relevant namespace after routing.

The 5–15 active-tool range is a useful starting point for testing because it is small enough to diagnose and broad enough for many workflows. If a task needs more, do not assume the design is wrong—measure performance by tool group. Conversely, an agent with only three overly broad tools can still produce dangerous or ungovernable calls.

A production flow can follow: request → intent/domain router → policy filter → tool retrieval → active candidate set → model selection → argument validation → authorization → executor.

The router first identifies a domain such as support, billing, or infrastructure. The policy filter removes tools the agent or user cannot access. Retrieval ranks the remainder using descriptions, metadata, workflow state, and required data. Only the top candidates are materialized into context; other tools remain in the catalog and can be loaded later. OpenAI's Agents SDK supports deferred loading, tool search, namespaces, and dynamic filtering for MCP tools, which fit this progressive-disclosure pattern.

Keep two decisions separate: retrieval decides which tools the model should consider, while authorization decides whether the selected call may execute. A router or semantic retriever can miss or misrank a tool, so the executor still needs deny-by-default checks for tenant, action, resource, limits, and approvals.

Each tool should have one clear purpose and a domain-plus-verb name such as order.get, shipment.track, or refund.create_draft. Its description should explain what it does, when to use it, when not to use it, and which prerequisites apply. For confusing neighbors, include negative guidance—for example, “does not execute a refund; creates a draft only.”

Schemas should use specific types, enums, required fields, length or quantity bounds, and additionalProperties: false where appropriate. Avoid accepting an unrestricted command or unstructured payload. OpenAI's Agents SDK strongly recommends strict JSON Schema for function tools, while Anthropic emphasizes detailed descriptions and supports input examples for complex arguments.

If two tools represent the same business capability and differ only by backend provider, consider one stable façade tool and let the backend select the provider. If actions carry different permissions or risk—such as draft versus execute—keep them separate so policy and audit remain explicit. Merge or split according to semantic and authorization boundaries, not a target count.

The Berkeley Function Calling Leaderboard covers cases involving multiple function candidates, parallel calls, relevant and irrelevant tools, and missing functions. This highlights that function calling involves more than selecting one name: the model must also decide not to call, choose the complete set, and provide correct arguments. Public benchmarks still cannot replace evaluations based on your schemas and traffic.

Build a golden test set from common requests, ambiguous language, no-tool cases, missing candidates, similar tools, prompt injection, and multi-step tasks. Label each expected outcome as no_tool, ask_clarification, one specific tool, or an allowed tool set. Compare at least three configurations: the full catalog, domain routing, and dynamic top-k retrieval.

Track:

• Tool selection accuracy: correct tool or set of tools.
• No-tool precision/recall: avoid unnecessary calls without missing required ones.
• Argument validity/correctness: valid schema and correct resource values.
• Unauthorized-call rate: calls blocked by policy; unauthorized side effects must never execute in production.
• Clarification rate: ask at the right time rather than guess.
• Task success, latency, tokens, and cost: selection gains must not make the workflow operationally inefficient.

Finding the right threshold experimentally

Hold the model, prompt, temperature, tool definitions, and evaluation set constant; change only the candidate strategy. Repeat runs when outputs are stochastic and retain traces. Start small, then add domain groups or change top-k—for example 5, 10, 15, and 25. These are experimental checkpoints, not universal recommendations.

Analyze a confusion matrix for individual tool pairs. If customer.search is regularly confused with contact.search, improve their boundary or routing before changing models. If the correct tool is absent from the retrieved candidates, the failure belongs to the router or retriever rather than the selector. If the tool is correct but arguments are wrong, focus on schemas, examples, and entity resolution. If the call is semantically correct but unauthorized, the pre-model filter and post-model policy are inconsistent.

Expand the active set only when task success improves while selection errors, no-tool false positives, latency, and cost remain within SLOs. Roll out by use case or tenant rather than replacing the full catalog at once.

When should tools be merged, split, or assigned to specialist agents?

Merge tools when they express one business capability with the same permissions and consequences, and only provider details differ. Split tools when actions have different prerequisites, scopes, or risk tiers; read, draft, execute, and delete are especially useful boundaries. Use routing or namespaces when the catalog is large but domains are clear. Create specialist agents when domains need distinct instructions, data, owners, credentials, and evaluations—not merely because the tool count increased.

Warning signs include tool descriptions accumulating exceptions, the same request alternating between synonymous tools, the model preferring an all-purpose tool, active schemas consuming excessive context, sensitive tools appearing in unrelated steps, or a change in one tool causing regressions elsewhere.

Do not use a multi-agent design to conceal a poorly designed catalog. Each specialist still requires a clear candidate set, independent authorization, observability, and contract tests. Agent handoffs are themselves decisions that must be evaluated and governed.

Pre-production checklist

1. Inventory tools by domain, action, owner, data, side effects, and risk tier.
2. Define the catalog, authorized set, and active candidate set separately.
3. Remove semantic duplicates; standardize names, descriptions, negative guidance, and strict schemas.
4. Route by domain or workflow state before selection; filter permissions before materializing candidates.
5. Keep authorization and business policy in the backend after the model proposes a call.
6. Build golden evaluations with no-tool, ambiguous, missing-tool, similar-tool, multi-step, and adversarial cases.
7. Benchmark the full catalog against routed sets and dynamic top-k retrieval on the same data.
8. Monitor selection, arguments, task success, denials, clarifications, latency, tokens, and cost by tool pair.
9. Roll out through shadow and canary stages; provide kill switches by tool, namespace, agent, and tenant.
10. Periodically review unused tools, description drift, schema versions, and the confusion matrix.

The practical conclusion is that an agent does not become stronger simply by receiving more tools. A reliable agent needs the right tools at the right step, with the right authority, validated by task-level evaluations.