Domain 2 · Statement 2.3 3 of 5

Distribute tools appropriately across agents and configure tool choice

What you need to know

Giving an agent 18 tools instead of 4–5 degrades selection reliability by increasing decision complexity on every turn.
Agents with tools outside their specialization misuse them — a synthesis agent with web search will start searching instead of synthesizing.
Scope each agent to its role, then add only limited cross-role tools for specific high-frequency needs (for example verify_fact for the synthesis agent).
Replace generic tools with constrained alternatives: load_document that validates document URLs instead of an open fetch_url.
The guide tests three tool_choice values: "auto" decides, "any" guarantees some tool, {"type": "tool", "name": "..."} forces one.
Forced tool_choice pins the first step only — sequence the remaining steps across follow-up turns, and route complex cross-role cases through the coordinator.

Every extra tool is a decision the model has to get right

Tool selection reliability degrades as the tool set grows. An agent holding 18 tools instead of 4–5 is not more capable — it faces higher decision complexity on every turn, and picks wrong more often. The exam frames this as a hard design principle, not a tuning preference: scope each agent's tool set to its role.²⁴²⁵

The second failure this prevents is out-of-specialization misuse. An agent given tools outside its job will use them. A synthesis agent that can reach a web-search tool starts doing its own searches instead of synthesizing what the search agent already gathered — duplicating work, spending context, and producing findings the coordinator never asked for.

Scoped access with deliberate exceptions

The pattern is scoped tool access: each agent gets only what its role needs, plus a small number of scoped cross-role tools for specific high-frequency needs.²⁶ The worked example is a synthesis agent that legitimately needs to check facts often; give it a narrow verify_fact tool rather than the full research toolkit, and route complex cases back through the coordinator. That keeps the common path cheap and the rare path correct.

Constraining tools also means replacing generic ones with bounded alternatives. Swapping a wide-open fetch_url for a load_document that validates document URLs removes a whole class of misuse without removing the capability the agent actually needs.

`tool_choice`: making invocation deterministic where it matters

tool_choice controls whether and which tool is called on a turn.¹⁹ The guide tests three values:

`tool_choice`	Guarantee	Who picks the tool	Use it when
`"auto"`	May call a tool, may return plain text	Model	Default agentic behavior
`"any"`	Must call some tool	Model	The turn has to produce a tool call rather than conversational text
`{"type": "tool", "name": "..."}`	Must call that tool	You	One specific call has to happen first, such as `extract_metadata` before enrichment

Forced selection guarantees which tool is called on this turn — that and nothing more. It is enough to make one specific call happen first: force extract_metadata on the opening turn, then let the enrichment steps proceed on follow-up turns under "auto". It is not a pipeline mechanism. Because forcing binds a single turn, ordering across steps is expressed as a sequence of turns, not as one clever configuration value. A genuine multi-step prerequisite — "never call process_refund before get_customer has returned a verified ID" — needs a programmatic gate instead. That is what gates are for; see 1.4.

Scoped tool sets across a coordinator and four subagents

Show that each subagent holds only a few role-relevant tools, that one scoped cross-role tool is a deliberate exception, and that complex cross-role work is routed back through the coordinator instead of widening a tool set.

Worked examples

Splitting an 18-tool monolith across four subagents

Scenario 3 · Multi-Agent Research System

The research system started as one agent holding every tool: web search, document loading, extraction, summarization, citation lookup, report rendering, and more — eighteen in total. Selection accuracy was poor and the agent frequently re-searched material it had already analyzed.

The fix distributes the same capabilities across the four specialized subagents, each holding four to five tools relevant to its role. The synthesis agent gets one deliberate exception: a scoped verify_fact tool, because fact-checking is a high-frequency need during synthesis. Anything more involved than a single fact check goes back through the coordinator rather than expanding the synthesis agent's tool set.

typescript

const toolsByRole = {
  webSearch:  ['search_web', 'extract_web_results', 'rank_sources'],
  documents:  ['load_document', 'extract_data_points', 'summarize_content'],
  // one scoped cross-role tool for a high-frequency need:
  synthesis:  ['merge_findings', 'detect_contradictions', 'verify_fact'],
  reporting:  ['render_report', 'cite_source', 'format_citations'],
};

// load_document replaces a generic fetch_url: it validates that the URL
// points at a document before the agent can reach arbitrary endpoints.

Scoped tool sets per subagent

Forcing the first tool call, then continuing in follow-up turns

Scenario 3 · Multi-Agent Research System

Enrichment tools are only meaningful once metadata has been extracted, but the model sometimes skips straight to enrichment. Forcing extract_metadata with tool_choice guarantees the first call, and the rest of the pipeline proceeds on subsequent turns under "auto".

Note what tool_choice cannot do: it does not express a multi-step ordering. If a stem asks how to guarantee a sequence, the answer is a forced first turn plus follow-up turns — not a single configuration value.

json

// Turn 1 — guarantee metadata extraction happens first
{ "tool_choice": { "type": "tool", "name": "extract_metadata" } }

// Turn 2+ — let the model choose among the enrichment tools
{ "tool_choice": { "type": "auto" } }

// Alternative: guarantee *some* tool is called rather than a chat reply
{ "tool_choice": { "type": "any" } }

Turn 1 forces one tool; later turns return to auto

Guaranteeing a tool call instead of a conversational reply

Scenario 1 · Customer Support Resolution Agent

The support agent occasionally answers a billing question conversationally — plausibly, and without ever calling get_customer or lookup_order. That is a correctness problem: the reply is ungrounded in backend data.

Setting tool_choice: "any" on the classification turn guarantees the model calls a tool rather than returning conversational text, forcing the agent to ground itself in get_customer or lookup_order before it composes an answer. Keep the tool set small — four tools (get_customer, lookup_order, process_refund, escalate_to_human) is squarely in the reliable range, which is part of why this agent routes well in the first place.

Anti-patterns

Giving one agent every tool it might conceivably need instead of scoping to 4–5 role-relevant tools because decision complexity degrades selection reliability.
Granting an agent tools outside its specialization "just in case" instead of routing those needs through the coordinator because agents reliably misuse out-of-role tools.
Exposing a generic fetch_url instead of a constrained load_document that validates document URLs because the generic tool invites uses the role never needed.
Trying to enforce a multi-step tool order with a single tool_choice setting instead of forcing the first tool and continuing in follow-up turns because forced selection applies to one turn only.

How it is examined

A stem that reports declining tool-selection accuracy alongside a growing tool count is testing the 4–5 versus 18 principle. The credited answer restricts tool sets per role; distractors improve descriptions or add prompt instructions instead.
Know the three tool_choice values the guide lists, by their exact spelling: "auto", "any", and {"type": "tool", "name": "..."}. The live API has a fourth, "none", which the guide does not test. If it appears as an option, it is not the credited answer. Items frequently hinge on choosing "any" (guarantee a tool call) versus forced selection (guarantee a specific tool).
Cross-role access questions have a two-part answer: a narrow scoped tool for the high-frequency case, and coordinator routing for the complex case. An option that grants full cross-role access, or one that refuses any exception, is incomplete.

References — 4 sources

Define tools Anthropic The normative tool-definition reference — name, `description`, `input_schema` — with Anthropic's own guidance on description quality, and the place to check whether the unit's four description components are the source's four. It is also where `tool_choice` is enumerated: "there are four possible options", `auto`, `any`, `tool` and `none`. With `any` or `tool` the API prefills the assistant message, so no natural-language text precedes the `tool_use` block.
Manage tool context Anthropic The four documented remedies for exactly the pressure the 4–5 versus 18 rule describes: tool search, programmatic tool calling, prompt caching, and context editing. It answers the question the rule raises and closes off — what to do when you genuinely need 18 tools.
Scale to many tools with tool search Anthropic On-demand tool loading at the Claude Code and Agent SDK layer — how the platform now expresses this unit's principle: keep few tools *in context*, not few tools *configured*.
Client Best Practices Model Context Protocol The spec's own quantified threshold for "too many tools": switch to progressive discovery once tool definitions occupy 1–5% of the context window. It turns the unit's unthresholded scoping rule into a number.

All sources verified · Aug 21, 2026

Live product docs — where they differ from the exam guide, answer from the guide. All references

Exam guide, verbatim — what is measured

Knowledge of

The principle that giving an agent access to too many tools (e.g., 18 instead of 4-5) degrades tool selection reliability by increasing decision complexity
Why agents with tools outside their specialization tend to misuse them (e.g., a synthesis agent attempting web searches)
Scoped tool access: giving agents only the tools needed for their role, with limited cross-role tools for specific high-frequency needs
tool_choice configuration options: "auto", "any", and forced tool selection ({"type": "tool", "name": "..."})

Skills in

Restricting each subagent's tool set to those relevant to its role, preventing cross-specialization misuse
Replacing generic tools with constrained alternatives (e.g., replacing fetch_url with load_document that validates document URLs)
Providing scoped cross-role tools for high-frequency needs (e.g., a verify_fact tool for the synthesis agent) while routing complex cases through the coordinator
Using tool_choice forced selection to ensure a specific tool is called first (e.g., forcing extract_metadata before enrichment tools), then processing subsequent steps in follow-up turns
Setting tool_choice: "any" to guarantee the model calls a tool rather than returning conversational text