Domain 2 · Task 2.3

Tool Distribution & Tool Choice

Distribute tools across agents and configure tool_choice.

The more tools an agent can see, the harder every selection decision becomes: 18 tools is far worse than 4–5. Agents also misuse tools outside their specialization (a synthesis agent that has web-search tools will try to search). The design rule is least privilege per role plus the smallest tool set that does the job — and when one role has a frequent, simple need for another role's capability, you give it a narrow scoped tool rather than exposing the full set. tool_choice then controls *whether and which* tool the model must call on a given request.

Key concept

Least privilege per role + the smallest tool set that does the job. For the ~85% common, simple need, give a narrow scoped tool; route the ~15% complex cases through the coordinator.

What you need to know

Too many tools degrade selection

Tool count directly affects selection reliability. Going from 4–5 tools to 18 sharply increases decision complexity, and the model starts making worse choices. Giving an agent extra tools "to be safe" backfires. Equally bad: giving an agent tools outside its specialization — a synthesis agent handed web-search tools will attempt web searches it has no business running, violating separation of concerns. The remedy is scoped access: each agent gets only its role's tools, with a small number of limited cross-role tools for genuinely high-frequency needs.

Scoped tools for the common case

The canonical pattern: a synthesis agent needs frequent, simple fact-checks (say 85% of its verification needs) but should not own the full web-research toolkit. The right move is a single narrow, scoped tool — a verify_fact tool — for that common case, while the complex 15% routes through the coordinator. This preserves least privilege (the synthesis agent still can't run arbitrary searches) while removing a blocking dependency for the everyday need.

Also prefer constrained alternatives to generic tools: replace a broad fetch_url with a load_document that validates document URLs, so the tool can only be used the intended way.

Why the alternatives are wrong

Contrast the scoped-tool answer with the usual distractors:

Give it all web tools — violates separation of concerns; the synthesis agent will misuse them.
Batch the fact-checks through another agent — creates a blocking dependency and adds latency for a high-frequency need.
Speculatively cache/pre-fetch facts — you can't predict which facts will be needed, so this wastes work and still misses cases.

The scoped verify_fact tool beats all three because it satisfies the common case directly, cheaply, and within least-privilege boundaries.

Configuring tool_choice

tool_choice controls the model's tool behavior on a request:

"auto" (default) — the model decides whether to call a tool or answer in prose.
"any" — the model must call *some* tool (use this to guarantee a tool call instead of free-text).
Forced — {"type":"tool","name":"..."} runs one specific tool; use it to make the model call, say, extract_metadata first before enrichment.

(Current docs also add "none" and a disable_parallel_tool_use flag, but for the exam baseline the three modes above are what's tested.) Use forced to pin a mandatory first step and "any" when you need structured output via a tool rather than prose.

json

// Force a specific tool to run first (e.g. extract metadata before enrichment):
{ "tool_choice": { "type": "tool", "name": "extract_metadata" } }

// Guarantee the model calls SOME tool instead of replying in prose:
{ "tool_choice": { "type": "any" } }

// Default — model decides whether/which tool to call:
{ "tool_choice": { "type": "auto" } }

Exam traps

The trap	The reality
Giving each agent all 18 available tools makes it more capable and avoids missing a needed tool.	More tools degrade selection reliability. Apply least privilege — scope each agent to ~4–5 role-appropriate tools.
A synthesis agent that occasionally fact-checks should get the full set of web tools.	That violates separation of concerns and invites misuse. Give it one scoped `verify_fact` tool; route complex verification through the coordinator.
Batching a synthesis agent's fact-checks through the research agent is an efficient design.	Batching creates a blocking dependency for a high-frequency need. A scoped local tool removes the dependency.
Speculatively caching likely-needed facts avoids the round-trips a scoped tool would incur.	You can't predict which facts will be needed, so caching wastes work and still misses cases. Use a narrow on-demand tool.

Practice scenario

Real questions from the bank that test this topic — the correct answer is highlighted.

For structured data extraction, you want Claude to always emit a specific tool call ( extract_record ) and never finish without one. Multiple turns are allowed; on each turn Claude must call extract_record until it has enough records, at which point it can stop.

Which tool_choice setting forces a tool call on every turn until the model decides to stop?

A{"type": "auto"} — Claude will call tools when needed

B{"type": "any"} — Claude must use some tool on each turn

C{"type": "tool", "name": "extract_record"} — Claude must use this specific tool on every turnCorrect

D{"type": "required"} — a flag that requires tool use without specifying which

Why: Pinning a specific tool with {"type": "tool", "name": "..."} forces Claude to call exactly that tool on every turn until you change the tool_choice. When you want to allow stopping, you'd switch to {"type": "auto"} . {"type": "any"} (B) forces some tool but doesn't restrict which. The {"type": "required"} option (D) is invented.

A teammate writes: "Setting disable_parallel_tool_use: true reduces latency because the model thinks more carefully before each call."

Most accurate correction?

ACorrect as stated; serial execution gives the model more "thinking time"

BWrong claim about latency — disable_parallel_tool_use: true actually increases end- to-end latency (one tool per turn instead of multiple in parallel) but provides deterministic ordering when tools have dependenciesCorrect

CThe parameter doesn't exist; parallel tool use is controlled by tool_choice

DThe parameter exists but only on the Claude Agent SDK, not the raw Messages API

Why: disable_parallel_tool_use: true exists, exists on the Messages API directly, and increases latency (serializes tool calls that could have been parallel). It's worth the trade only when tools have ordering dependencies you need guaranteed. A inverts the latency claim. C wrongly denies the parameter's existence. D wrongly restricts it to the SDK only.

Build exercise

Scope tools across a two-agent workflow

~45 min

1
Stand up a coordinator, a research agent (web tools), and a synthesis agent, and initially give the synthesis agent every tool.
Why: You need the over-provisioned baseline to observe the selection degradation and misuse it causes.
You should see: The synthesis agent occasionally runs web searches it shouldn't, and tool selection gets noisier.
2
Restrict each agent to its role's tools; give the synthesis agent exactly one scoped verify_fact tool for the common fact-check case.
Why: Least privilege plus a narrow scoped tool satisfies the 85% case without exposing the full toolkit.
3
Route the complex 15% of verifications through the coordinator instead of the scoped tool.
Why: Keeps hard cases in the role that owns full research capability while the common case stays local.
4
Replace a generic fetch_url with a constrained load_document that validates document URLs.
Why: Constrained alternatives make it impossible to misuse a tool for an unintended purpose.
5
Add a forced tool_choice to run extract_metadata first on a request, then switch to "any" to guarantee a tool call, and observe the difference.
You should see: Forced pins the exact first tool; "any" guarantees some tool call but lets the model choose which.

Sources

Tool use with Claude (tool_choice)Building effective agents Claude Docs

Drill Tool Design & MCP Integration

Practice only this domain’s questions, untimed, with instant explanations.