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 made-up example throughout: a print shop run by a small team of agents. An order agent handles orders and customer messages, and an artwork agent prepares files for the press. A quoting agent prices jobs, a stock agent tracks paper, and a coordinator hands 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 print shop, each agent chooses only between the few tools that its role needs.
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, an agent that has a search tool outside its role may run its own searches instead of using the results that it already received. Those extra searches duplicate work and waste context. If the print shop's quoting agent has a search tool, it may search the orders again rather than price the job that it received. 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. Take a server with 22 tools. 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.
The print shop's artwork operations share a shape too. Resizing, adding bleed and converting to CMYK each take a file in and return a file. One artwork tool with an operation parameter replaces those three operations.
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 print shop's order agent holds five tools and picks get_customer when it needed lookup_order, 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. Server boundaries are invisible to the model, 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 print shop's artwork agent needs customer files, 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 does the opposite job.
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. 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 print shop's quoting agent checks paper stock for nearly every quote, so it gets a scoped check_stock tool for simple lookups. Harder checks still go through the coordinator to the stock 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": "check_stock",
"description": "Check how many sheets of one paper stock are in the warehouse. Takes a single stock code. For substitutions, supplier lead times or anything that needs judgement, ask the coordinator.",
"strict": true,
"input_schema": {
"type": "object",
"properties": {
"stock_code": { "type": "string", "pattern": "^PS-[0-9]{4}$" }
},
"required": ["stock_code"],
"additionalProperties": false
}
}This schema accepts one stock code and nothing else. It has no free-text query, no supplier field and no list of codes. So the quoting agent cannot use the tool to browse the stock agent's data. 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 code in the right format.
Build the limit into the structure of the schema. Strict tool use 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. So "one stock code 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 quote.
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 print shop's order agent fits: some messages need a lookup, some only a reply.
{
"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 a pipeline has one schema each for invoices, receipts and contracts, and the document type is unknown. Then "any" guarantees that the model picks one schema and produces structured output, not a conversational response. The print shop's order agent needs "any" when an order could be for business cards, posters or banners.
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. If metadata extraction must happen 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". The print shop's artwork agent could force a file check first in the same way.
Current state
Exam guide v1.0 names all three modes and tests "any" and forced selection for those jobs. Current state (checked 6 October 2026): the define-tools page says Claude 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 make mistakes on the first row of the fix table. 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, a synthesis agent sends every fact verification through the coordinator, and 85% of them are simple lookups. For frequent simple fact verifications, the synthesis agent gets a scoped verify_fact tool. 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. Scope verify_fact the way check_stock is scoped. It takes one claim in and gives a verdict out. It has no query or URL field that would let the synthesis agent run its own searches.
In a multi-agent research system, the synthesis agent should not have web search tools, or it might run its own searches. The web search agent should not have document analysis tools. A well-designed layout:
| 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 |
The coordinator holds no domain-specific tools itself.
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
- CCAR-F Exam Guide v1.0: Sample Question 9 — Anthropic