Tool Distribution Choice
Give each agent 4-5 role-scoped tools, use tool_choice to control invocation, and add scoped cross-role tools to cut coordinator latency.
How you distribute tools across agents is an architectural decision, not a detail. Overload one agent with tools and its selection accuracy collapses; scope each agent tightly to its role and the whole system becomes reliable. The guiding number the exam expects is 4-5 tools per agent, each relevant to that agent's defined job.
The tool overload problem
Every additional tool widens the decision space and raises the error rate. Beyond roughly five tools, selection reliability degrades measurably. Relevance matters as much as count: a synthesis agent handed web search will run redundant searches instead of using the results it was already given, wasting context tokens. Each agent gets only the tools its role requires — nothing more.
| Agent | Role-scoped tools (4-5) |
|---|---|
| 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 | spawn_subagent, review_output, request_revision |
Piling every tool onto one agent (18 tools "so it can do anything") widens the decision space past ~5 tools and selection accuracy collapses. Handing a synthesis agent web search makes it re-search data it already has.
Scope each agent to 4-5 role-relevant tools. The coordinator holds no domain tools, and irrelevant capabilities are removed so every option Claude sees is one it should actually consider.
The coordinator holds no domain tools. No tool appears across multiple agents except a deliberate scoped cross-role tool. Prefer a constrained load_document (validates document URLs) over a generic fetch_url that can reach anything.
The tool_choice modes
The tool_choice parameter controls whether and which tool Claude must call. Three modes cover the common needs.
| Mode | Behaviour | Use when |
|---|---|---|
| auto (default) | Model decides whether to call a tool | Flexibility; tool calls are optional |
| any | Model must call a tool, picks which | Guaranteed structured output, unknown input type |
| forced (tool) | Model must call a named tool | Mandatory first step in an ordered workflow |
# Force the metadata step first, then let the model choose
first = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
tools=tools,
tool_choice={"type": "tool", "name": "extract_metadata"},
messages=messages,
)
# Guarantee a structured extraction of an unknown document type
extract = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
tools=tools,
tool_choice={"type": "any"},
messages=messages,
)Routing every request through a coordinator adds 2-3 round trips and up to ~40% latency. If 85% of a synthesis agent's fact checks are simple single-source lookups, give it a scoped verify_fact tool for those and route only the complex 15% through the coordinator.
If a step must produce a tool call — say a mandatory extraction — leaving tool_choice on auto risks a conversational reply instead. Use 'any' or a forced tool. Likewise, assigning 18 tools to one agent guarantees unreliable selection.
How the exam will try to trick you
The distractors below look right under time pressure — learn the tell.
- The trap
Route all simple verification requests through the coordinator when 85% are single-source lookups.
Correct answerGive the synthesis agent a scoped
verify_facttool for the simple cases; route only the complex 15% through the coordinator.Why: Coordinator round trips add 2-3 hops and up to ~40% latency for work the agent could do locally.
- The trap
Leave
tool_choiceon auto when a step must produce a structured tool call.Correct answerUse
anyto guarantee some tool call, or a forced named tool for a mandatory step.Why: With auto the model may reply conversationally instead of invoking the required tool.
- The trap
Give one agent 18 tools so it can handle anything.
Correct answerScope each agent to 4-5 role-relevant tools.
Why: Selection reliability degrades measurably past ~5 tools as the decision space widens.
- The trap
Hand a subagent a generic
fetch_urltool when a constrainedload_documentwould do.Correct answerUse the constrained tool that validates URLs and enforces least privilege.
Why: Generic tools invite misuse and blur the agent's purpose.
Key takeaways
- Target 4-5 role-scoped tools per agent; more tools measurably degrades selection accuracy.
- Relevance beats count — irrelevant tools cause redundant work and wasted context.
- tool_choice auto lets Claude decide; any forces some tool; forced names a specific tool.
- Use 'any' or forced tool_choice when structured output or step ordering is mandatory.
- Scoped cross-role tools handle high-frequency simple cases locally, cutting coordinator latency.
- Prefer constrained tools (load_document) over generic ones (fetch_url) for least privilege.
Frequently asked questions
How many tools should a Claude agent have?+
Around 4-5 tools scoped to that agent's specific role. Beyond that, the decision space grows and selection reliability drops. If an agent seems to need many more, that usually signals it should be split into multiple role-focused agents.
What is the difference between tool_choice auto, any, and forced?+
auto lets Claude decide whether to call a tool or answer conversationally. any requires a tool call but lets the model pick which one, guaranteeing structured output. Forced (type tool with a name) requires a specific tool, which is how you enforce a mandatory first step.