What You Need to Know
An agent's tools are the functions it can call. Tool selection is the model's choice of which tool to call. Tool distribution is the choice of which agent in a multi-agent system holds which tools. The number of tools an agent holds directly affects how reliably it selects the right tool. So tool distribution is an architectural decision that determines whether a multi-agent system works in production.
This lesson uses one example throughout, based on the exam guide's multi-agent research system, which writes research reports. A web search agent finds sources, a document analysis agent reads them, a synthesis agent writes the report, and a coordinator passes work between them.
The Tool Overload Problem
When you give a single agent 18 tools, the agent selects tools less reliably. Every additional tool makes the decision more complex, so error rates increase as the toolkit grows. Keep each agent's set of tools small and scoped to its role. In the research system, each agent holds only the few tools that its role needs.
| Agent | Tools |
|---|---|
| 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 |
The coordinator holds no domain-specific tools itself.
The relevance of the tools matters as much as their number. An agent that has tools outside its specialisation tends to misuse them. For example, if the synthesis agent has web search tools, it may run its own searches instead of writing from the findings that it received. Those extra searches duplicate work and waste context. For the same reason, the web search agent has no document analysis tools. Each agent gets only the tools that its defined role needs.
Consolidating Near-Duplicate Tools
Splitting tools by role is the wrong fix when the tools all do the same kind of work. Suppose the document analysis agent also connects to a statistics server with 22 tools, for the figures in its sources. Three are query tools, one for each data source. The other 19 are transformations, such as pivot_table, calculate_percentile and normalise_currency. If you split these tools by role, a transformation agent gets 19 tools. The transformation agent now has the original problem: it still cannot choose reliably.
The 19 transformations share a shape: data in, an operation, data out. So combine them into one tool whose parameter names the operation:
{
"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, and nothing is lost. Each transformation is now an enum value that the model picks inside a single call, not a tool to find among nineteen near-identical descriptions. The model selects more accurately because it now chooses between fewer tools. The capability stays the same.
To pick the fix:
| 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, a small set each (the guide's example is 4-5, against 18) |
| 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) |
Task Statement 2.1 teaches more specific descriptions as the fix when the model selects the wrong tool. That fix is right when the toolkit is small enough to reason about. If the document analysis agent holds four tools and picks summarize_content when it needed extract_data_points, that is a description problem. The same symptom from a set of 22 tools is not a description problem. At that size, no description quality fixes selection, and rewriting all 22 descriptions leaves the decision as complex as it was. Count the tools before you pick the fix.
Moving tools onto a second MCP server is no fix. A client gives the model every tool from every connected server as one flat list. In Claude Code, the server name appears as a prefix on each tool's name, as in mcp__<server>__<tool>. So 22 tools on two servers are still 22 tools.
Replacing Generic Tools with Constrained Alternatives
A fetch_url tool can fetch anything from anywhere. A load_document tool validates document URLs and accepts those only. Giving a subagent load_document instead:
- 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)
Giving the agent load_document applies least privilege to tool design. Each tool does exactly what the agent needs and nothing more. The document analysis agent needs only documents, so load_document is enough.
Consolidating tools reduces how many tools an agent chooses between. Constraining tools reduces what any one tool can reach. Combining 19 transformations into transform_data gives the agent no new capabilities, so consolidation does not undo least privilege. Replacing fetch_url with load_document leaves the number of tools the same and reduces what the tool can reach.
Scoped Cross-Role Tools
Sometimes an agent needs occasional access to a capability that belongs to another role. The naive approach routes every such request through the coordinator, which delegates, waits for the result and passes it back. That adds 2-3 round trips per request and can increase latency by 40% or more. A round trip is one message sent and its reply received. For simple lookups that take milliseconds, the round trip is waste.
A scoped cross-role tool is a constrained version of the capability. The agent that needs the capability gets this tool directly. The agent uses it for simple requests that happen at high frequency. Complex cases still route through the coordinator. These cases need multiple sources, cross-referencing or real judgement. The synthesis agent checks a simple fact, such as a date or a figure, for nearly every paragraph it writes. So it gets a scoped verify_fact tool for simple lookups. Harder verifications still go through the coordinator to the web search agent.
The tool's input schema defines the scope. If the schema omits a field, the agent cannot make a request with that field.
{
"name": "verify_fact",
"description": "Check one simple factual claim, such as a date, a figure or a name, against one source already collected. For claims that need new searches, several sources or judgement, ask the coordinator.",
"strict": true,
"input_schema": {
"type": "object",
"properties": {
"claim": { "type": "string" },
"source_id": { "type": "string", "pattern": "^SRC-[0-9]{4}$" }
},
"required": ["claim", "source_id"],
"additionalProperties": false
}
}This schema accepts one claim and one source ID and nothing else. additionalProperties: false means that a call cannot add any other field. It has no search query, no URL field and no list of claims. So the synthesis agent cannot use the tool to run its own searches. The description names what the tool does not do and where to send those requests. With strict: true, the API constrains Claude's tool inputs to the schema, so every call contains exactly one claim and one source ID in the right format.
Build the limit into the structure of the schema. Strict tool use, the strict: true setting, supports enum, pattern and an array minItems of 0 or 1. The API rejects maxItems, maxLength, minimum and maximum with a 400 error when the API receives the schema unchanged. A 400 error means that the API refused the request. So "one claim per call" is a single string field, not an array with maxItems: 1. A limit that the schema cannot express belongs in the code that runs the tool. An example is how many checks the agent may run for one report.
The tool_choice Configuration
The tool_choice parameter controls how the model interacts with the tools available. Each of its three settings has its own job.
"auto" (default)
The model decides whether to call a tool or return text. Use it for general operation, where the model needs flexibility to respond conversationally when no tool call is appropriate. The synthesis agent fits: it calls verify_fact when a claim needs checking and otherwise writes text.
{
"tool_choice": { "type": "auto" }
}"any"
The model must call a tool but chooses which one. Use it when you need guaranteed structured output from one of multiple schemas. The model always produces a tool call, never plain text.
{
"tool_choice": { "type": "any" }
}Extraction pipelines are the usual case. Say the document analysis agent has one extraction schema each for research papers, news articles and government reports, and the document type is unknown. In a request that offers only those three extraction tools, "any" guarantees that the model picks one schema and produces structured output, not a conversational response.
Forced selection The model must call one specific named tool. Use it to enforce a mandatory first step: the model cannot skip or reorder the required operation.
{
"tool_choice": { "type": "tool", "name": "extract_metadata" }
}Forced selection enforces the order of the workflow. Enrichment tools add further detail to the metadata. If the document analysis agent must extract metadata before any enrichment tools run, forcing extract_metadata guarantees that order. The model cannot go directly to enrichment. After the forced call completes, later turns can use "auto".
Current state
Exam guide v1.0 names all three modes and tests "any" and forced selection for those jobs. Current state (checked 14 November 2026): the define-tools page says Claude Fable 5.2, Mythos 5.2, Opus 5.5, Sonnet 5.5, Fable 5.1 and Mythos 5.1 reject {"type": "any"} and {"type": "tool"} with a 400 error. Manual extended thinking rejects both on any model. In those cases, the documented route is "auto" with strict tool use for schema-valid inputs. The prompt guides which tool the model picks. The claude-sonnet-5 model in this lesson's code is not on that list, so the code runs as written. On the exam, answer with "any" and forced selection.
In the exam
The guide compares 18 tools with 4-5 per agent. That comparison is an illustration, not a hard limit.
Candidates often choose sharper descriptions for a set of tools that is too large for that fix. Sharper descriptions fix a small set in which two tools read alike. The exam also favours questions about how consolidation and constraint seem to conflict. Both can be right in the same system.
The guide's sample Question 9 tests scoped cross-role tools directly. In that question, the synthesis agent sends every fact verification through the coordinator, and 85% of them are simple lookups. The correct answer is the scoped verify_fact tool above. Complex verifications, the other 15%, still go to the web search agent through the coordinator. The guide's reasoning is least privilege: the synthesis agent gets only what the 85% case needs.
Key Concept
Keep each agent's tools few and scoped to its role. Scoped cross-role tools let high-frequency simple operations avoid the coordinator round trip.
Current state (checked 6 October 2026): Anthropic's tool search docs say Claude's ability to pick the right tool degrades once you exceed 30 to 50 available tools. On the exam, use the guide's 18-versus-4-5 framing.
Exam Traps
Routing all simple verification requests through the coordinator when 85% are simple lookups
Coordinator round-trips add 2-3 extra hops per request. A scoped verify_fact tool on the synthesis agent handles the 85% simple case directly, cutting latency by up to 40%.
Using tool_choice 'auto' when structured output is required
With 'auto', the model may return conversational text instead of calling a tool. The exam guide says 'any' guarantees a tool call and forced selection a specific one. Current docs (October 2026) say some models reject both and point to 'auto' with strict tool use.
Giving an agent 18 tools and expecting reliable selection
Every additional tool adds decision complexity, so selection reliability degrades. Split tools by role into small sets, as the guide's 18 against 4-5 shows. Current docs (October 2026) place the degradation point at 30 to 50 tools.
Giving a subagent a generic fetch_url tool for loading documents
Generic tools enable misuse. Constrained alternatives (load_document that validates document URLs only) enforce the principle of least privilege and make the tool's purpose clearer.
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. No claim may reach the report unconfirmed. What is the most effective solution?
Build Exercise
Configure Tool Distribution Across a Multi-Agent System
What you'll learn
- Give each agent role a small, scoped set of tools (the example in the guide is 4-5, not 18)
- Implement scoped cross-role tools to avoid coordinator round-trip latency
- Configure tool_choice modes (auto, any, forced) for different workflow requirements
- Apply least-privilege tool design by replacing generic tools with constrained alternatives
- Verify that tool distribution prevents cross-role misuse in multi-agent systems
- Design three agent roles (web search, document analysis, synthesis) and assign each a small set of tools (the example in the guide is 4-5, against 18), scoped to its role
Why: Tool overload degrades selection reliability. The exam tests the principle that each agent gets a small set of tools scoped to its specific role, with 4-5 as the exam guide example. Giving a single agent 18 tools is a known anti-pattern that causes misrouting.
You should see: A configuration object or table listing three agents, each with a small set of tools (the example in the guide is 4-5, against 18). No tool appears in more than one agent role (except scoped cross-role tools added later). Tool names clearly indicate their purpose and scope.
- Add a scoped verify_fact tool to the synthesis agent that handles simple lookups directly
Why: Routing every fact verification through the coordinator adds 2-3 round trips and up to 40% latency. The exam tests the scoped cross-role tool pattern — give the agent a constrained version of a capability for the 85% simple case, routing only complex cases to the coordinator.
You should see: A verify_fact tool added to the synthesis agent toolset with a description that explicitly limits it to simple single-source lookups and states that complex multi-source verifications should be escalated to the coordinator.
- Configure tool_choice forced selection on the document analysis agent to ensure extract_metadata runs as the mandatory first step
Why: Forced selection enforces workflow ordering. The exam tests your knowledge of all three tool_choice modes: auto lets the model choose freely, any guarantees a tool call, and forced selection guarantees a specific tool call. This prevents the model from skipping mandatory steps.
You should see: A document analysis agent configuration where the first API call uses tool_choice with type: tool and name: extract_metadata, and subsequent calls switch to tool_choice: auto for the remaining analysis steps.
- Replace a generic fetch_url tool with a constrained load_document that validates document URLs only
Why: This applies the principle of least privilege to tool design. A generic fetch_url tool can fetch anything from anywhere, enabling misuse. A constrained load_document that validates URLs prevents the agent from fetching arbitrary resources. The exam tests this pattern directly.
You should see: A load_document tool definition that includes URL validation logic (checking for document file extensions or trusted domains) and rejects non-document URLs with a clear error message.
- Test with a query that requires all three agents and verify that no cross-role tool misuse occurs
Why: End-to-end testing validates that your tool distribution works in practice. Cross-role misuse — such as a synthesis agent running its own web searches instead of using provided results — is a common failure the exam expects you to prevent through proper scoping.
You should see: A test run log showing: the web search agent using only its tools, the document analysis agent starting with extract_metadata (forced), and the synthesis agent using compile_report plus verify_fact for simple checks. No agent calls a tool outside its assigned set.
Sources
- Claude Certified Architect Foundations Exam Guide — Domain 2, Task Statement 2.3 — Anthropic
- Tool use — Anthropic API Documentation — Anthropic
- Define tools: Forcing tool use — Anthropic API Documentation — Anthropic
- Strict tool use — Anthropic API Documentation — Anthropic
- Structured outputs: JSON Schema limitations — Anthropic API Documentation — Anthropic
- Claude Agent SDK — Tool Configuration — Anthropic
- Connect Claude Code to tools via MCP — Anthropic
- CCAR-F Exam Guide v1.0: Sample Question 9 — Anthropic