2.3 Tool Distribution & Tool Choice

What You Need to Know

The number of tools you give an agent directly affects how reliably it selects the right one. That sounds like an implementation detail. It isn’t — it’s an architectural decision that determines whether your multi-agent system works in production.

The Tool Overload Problem

Giving a single agent 18 tools degrades selection reliability. Every additional tool adds decision complexity, and error rates climb as the toolkit grows. The optimal range is 4-5 tools per agent, scoped to that agent’s specific role.

Quantity isn’t the whole story, though — relevance matters just as much. A synthesis agent should NOT have web search tools. A web search agent should NOT have document analysis tools. Give an agent tools outside its specialisation and it will tend to misuse them: a synthesis agent with access to web_search might run its own searches instead of using the results already handed to it, duplicating work and wasting context.

The principle: each agent gets only the tools it needs for its defined role. Nothing more.

Consolidating Near-Duplicate Tools

Splitting by role is the obvious answer to tool overload. It’s the wrong one when the tools all do the same kind of work.

Take a data platform server with 22 tools: three query tools, one per data source, and 19 transformations — pivot_table, calculate_percentile, normalise_currency, on down the list. Split that by role and you hand a transformation agent 19 tools, which is the original problem moved one level down. The agent still can’t choose reliably.

Those 19 collapse instead, because they share a shape. Data in, an operation, data out:

{
  "name": "transform_data",
  "description": "Apply a transformation to a dataset. Use transform_type to select the operation.",
  "input_schema": {
    "type": "object",
    "properties": {
      "dataset": { "type": "string" },
      "transform_type": {
        "type": "string",
        "enum": ["pivot", "percentile", "normalise_currency", "..."]
      },
      "options": { "type": "object" }
    },
    "required": ["dataset", "transform_type"]
  }
}

Twenty-two tools become four. Nothing is lost: every transformation is still reachable, now as an enum value the model picks inside a single call rather than a tool it has to find among nineteen near-identical descriptions. Selection accuracy improves because the hard choice got smaller, not because the capability did.

So which fix applies?

The tools are…	The fix
Few enough to handle, but two of them read alike	Sharpen the descriptions (Task Statement 2.1)
Different jobs (query, transform, export)	Split by role, 4-5 tools each
Variations on one job, sharing a shape	Consolidate into one parameterised tool
Doing more than the agent should be able to do	Constrain them (next section)

The first row is the one candidates trip on. Task Statement 2.1 teaches descriptions as the fix for misrouting, and it is right when the toolkit is small enough to reason about. An agent choosing get_customer over lookup_order from a set of five is a description problem. The same symptom from a set of 22 is not: the agent is past the point where any description quality rescues selection, and rewriting all 22 leaves the decision complexity exactly where it was. Same symptom, different disease. Count the tools before you pick the remedy.

Watch the third row: it pulls the other way, and the exam likes that tension. Consolidation reduces how many tools an agent chooses between. Constraining reduces what any one tool can reach. Collapsing 19 transformations into transform_data doesn’t hand the agent new powers, so it doesn’t undo least privilege. Replacing fetch_url with load_document does the opposite job and both can be right in the same system.

One fix that isn’t a fix: moving tools onto a second MCP server. Server boundaries are invisible to the model. A client hands it every tool from every connected server as one flat list, so a 22-tool problem split across two servers is still a 22-tool problem.

The tool_choice Configuration

The tool_choice parameter controls how the model interacts with available tools. Three settings, three distinct jobs.

"auto" (default) The model decides whether to call a tool or return text. Use this for general operation where the model needs flexibility to respond conversationally when no tool call is appropriate.

{
  "tool_choice": { "type": "auto" }
}

"any" The model MUST call a tool but chooses which one. Use this when you need guaranteed structured output from one of multiple schemas — the model will always produce a tool call, never plain text.

{
  "tool_choice": { "type": "any" }
}

Extraction pipelines are where this earns its keep. If you have multiple extraction schemas (one for invoices, one for receipts, one for contracts) and the document type is unknown, "any" guarantees the model picks one and produces structured output rather than returning a conversational response.

Forced selection The model MUST call a specific named tool. Use this to enforce mandatory first steps — the model cannot skip or reorder the required operation.

{
  "tool_choice": { "type": "tool", "name": "extract_metadata" }
}

This is the tool for enforcing workflow ordering. If metadata extraction must happen before any enrichment tools run, forced selection guarantees it. The model can’t decide to skip extract_metadata and jump straight to enrichment. After the forced call completes, subsequent turns can use "auto" for the remaining steps.

Scoped Cross-Role Tools

Sometimes an agent needs occasional access to a capability that belongs to another role. The naive approach is to route every such request through the coordinator. The problem: this adds 2-3 round trips per request and can increase latency by 40% or more.

The solution is a scoped cross-role tool: a constrained version of the capability, given directly to the agent that needs it.

Say a synthesis agent needs to verify simple facts constantly during report generation. The naive design routes every verification back to the coordinator, which delegates to the search agent, waits for results, and returns them. For 85% of verifications — simple lookups that take milliseconds — that round trip is pure waste.

The fix: give the synthesis agent a scoped verify_fact tool that handles simple lookups directly. Complex verifications (requiring multiple sources, cross-referencing, or real judgement) still route through the coordinator. The 85% simple case is handled locally; the 15% complex case uses the full pipeline.

The exam guide’s sample Question 9 tests this pattern directly.

Replacing Generic Tools with Constrained Alternatives

Instead of giving a subagent fetch_url (which can fetch anything from anywhere), give it load_document that validates document URLs only. The constrained tool:

Prevents misuse (the agent cannot fetch arbitrary URLs)
Makes the tool’s purpose clearer (the description is specific, not generic)
Reduces the risk of unintended side effects (no fetching of non-document resources)

This is least privilege applied to tool design. Each tool does exactly what the agent needs and nothing more.

Role-Specific Tool Scoping in Practice

Here is how tool distribution looks in a well-designed multi-agent research system:

Agent	Tools (4-5 each)
Web Search	`search_web`, `fetch_page`, `extract_links`, `save_snippet`
Document Analysis	`extract_metadata`, `extract_data_points`, `summarize_content`, `verify_claim`
Synthesis	`compile_report`, `verify_fact` (scoped), `format_citation`, `assess_coverage`
Coordinator	`Agent` (formerly `Task`, used to spawn subagents), `review_output`, `request_revision`

Each agent has exactly the tools it needs. The synthesis agent has a scoped verify_fact for simple lookups. The coordinator runs the workflow without holding any domain-specific tools itself.

Exam Traps

Practice Scenario

A synthesis agent frequently returns control to the coordinator for simple fact verification, adding 2-3 round trips per task and 40% latency. Analysis shows 85% of verifications are simple lookups. What is the most effective solution?

A. Give the synthesis agent a scoped verify_fact tool for simple lookups, routing only complex verifications through the coordinator.
B. Increase the coordinator parallelism so that verification requests are processed concurrently and the queueing delay disappears entirely.
C. Cache all verification results at the coordinator level so that repeated lookups return instantly without a second round trip to any subagent.
D. Remove the fact verification step from the synthesis workflow entirely so no task ever pays the round-trip latency.

Answer & explanation

Correct: A

A — A scoped cross-role tool handles the 85% simple case directly, eliminating round-trip latency. Complex cases still route through the coordinator for proper handling.
B — Faster processing does not eliminate unnecessary round trips. The latency comes from the routing overhead itself, not the coordinator speed.
C — Caching helps with repeated lookups but does not address the fundamental round-trip overhead for first-time verifications, which constitute the majority.
D — Removing verification compromises output quality. The goal is to make verification faster for the common case, not to skip it entirely.

Sources

Claude Certified Architect Foundations Exam Guide — Domain 2, Task Statement 2.3 — Anthropic
Tool use — Anthropic API Documentation — Anthropic
Claude Agent SDK — Tool Configuration — Anthropic

Exam Simulator

Five exam-style multiple-choice questions on Tool Distribution & Tool Choice. Pick an answer, then open the explanation.

Question 1

A. Increase the coordinator’s parallelism to process verifications faster.
B. Cache verification results at the coordinator so repeated lookups return instantly.
C. Give the synthesis agent its own scoped verify_fact tool, routing only complex checks to the coordinator.
D. Remove fact verification from the synthesis workflow altogether, which eliminates the round trips and the latency they cause.

Answer & explanation

Correct: C

C is correct because a scoped cross-role tool handles the 85% simple case in place, which is where the round-trip latency is going. The complex remainder still routes through the coordinator, so nothing is lost.
A is wrong because a faster coordinator does not remove unnecessary round trips. The latency comes from the routing itself, not from how quickly the coordinator works.
B is wrong because caching only helps the second time a fact is checked. First-time verifications are the majority here, and they still pay the full round trip.
D is wrong because dropping verification trades quality for speed. The goal is to make the common case fast, not to stop checking.

Question 2

A document analysis pipeline must always extract metadata before running any enrichment tools. Which tool_choice configuration enforces this?

A. tool_choice: { type: “tool”, name: “extract_metadata” } for the first call, then { type: “auto” } after.
B. tool_choice: { type: “auto” }, since the model extracts metadata first anyway.
C. tool_choice: { type: “any” }, since the model must call a tool and will pick extract_metadata.
D. List extract_metadata first in the tools array, since the model prefers whatever comes first.

Answer & explanation

Correct: A

A is correct because forced selection guarantees extract_metadata runs first: the model cannot skip it or reorder it. Switching to “auto” afterwards leaves the enrichment tools free to be chosen on their merits.
B is wrong because “auto” lets the model decide whether to call a tool at all. It may jump straight to enrichment or answer in prose.
C is wrong because “any” guarantees a tool call but not which tool. An enrichment tool satisfies it just as well as extract_metadata.
D is wrong because array position carries no ordering guarantee. Selection runs on descriptions and context, not on where a tool sits in the list.

Question 3

An agent has 18 tools available and is consistently selecting the wrong tool for user queries. What is the most likely root cause?

A. The tool descriptions need considerably more detail than they currently carry, so the model can tell them apart.
B. The model needs few-shot examples so it can learn the correct selection patterns from worked cases in the prompt.
C. tool_choice should be set to “any” so that a tool call is always forced.
D. The agent has too many tools, which degrades selection reliability, and 4-5 scoped tools is the range.

Answer & explanation

Correct: D

D is correct because selection reliability falls away as the tool count climbs, and 18 options is well past the point where descriptions can carry the decision. Scoping an agent to 4-5 tools matched to its role is the fix.
A is wrong because better descriptions help but cannot undo the sheer number of choices. Even perfectly written, 18 tools is too many to select from reliably.
B is wrong because few-shot examples add token overhead on every request without reducing the number of options the model is choosing between.
C is wrong because “any” forces a call without helping the model pick correctly from 18. It removes the option of answering in text, which makes matters worse.

Question 4

A subagent currently has access to fetch_url, which can fetch any URL from any domain. What is the correct least-privilege improvement?

A. Add URL validation to the system prompt to restrict what the agent fetches.
B. Replace fetch_url with load_document, which validates document URLs and rejects everything else.
C. Keep fetch_url as it is and add request logging so the team can monitor everything the agent fetches.
D. Remove fetch_url entirely and route every fetch through the coordinator, which then owns all outbound requests.

Answer & explanation

Correct: B

B is correct because swapping a generic tool for a constrained one puts least privilege into the interface itself. load_document accepts document URLs, refuses the rest, and reads unambiguously as a result.
A is wrong because system prompt instructions are advisory. The model can still call fetch_url with any URL it likes, so the constraint has to live in the tool.
C is wrong because logging catches misuse after it has happened. Preventing it in the tool is preferable to detecting it in a dashboard.
D is wrong because routing every fetch through the coordinator adds a round trip to a common operation. A constrained local tool gets the same safety without the latency.

Question 5

An extraction pipeline handles invoices, receipts, and contracts. The document type is unknown at input. You need guaranteed structured output from the correct schema. Which tool_choice should you use?

A. tool_choice: { type: “auto” }, since the model will recognise the document type without being forced.
B. tool_choice: { type: “tool”, name: “extract_invoice” }, forcing the invoice schema on every document.
C. tool_choice: { type: “any” }, which guarantees a tool call while the model picks the schema.
D. Process every document through all three extraction tools in turn, then keep whichever result looks most complete.

Answer & explanation

Correct: C

C is correct because “any” guarantees a tool call, which is what makes the output structured, while leaving the choice of schema to the model. That combination is precisely what “any” exists for.
A is wrong because “auto” permits a conversational reply instead of a tool call. Where structured output is required, that is not a guarantee.
B is wrong because forcing a tool assumes a document type that is unknown by definition. An invoice extractor cannot correctly process a receipt or a contract.
D is wrong because running all three burns API calls and context on two results that will be discarded. One call with “any” settles it.