Scoped Tool Access for Multi-Agent Systems

1.Why fewer tools per agent means better tool selection

Every tool definition you give an agent is one more option it has to weigh on every turn. The more options there are, the harder the decision, and the more often the agent picks the wrong one. Anthropic's tool search documentation gives a concrete threshold: Claude's ability to pick the right tool degrades once you exceed 30–50 available tools. The fix it describes is to load a focused set: tool search works by loading only the 3–5 tools Claude needs for a given request, so accuracy stays high.

The exam guide puts this as roughly 18 tools versus 4–5. That figure of 18 does not appear in the vendor documentation available here. The documentation gives the 30–50 threshold and the 3–5 focused set. The principle is the same in both: a small toolset matched to the task beats a large general one. In a multi-agent system you don't need tool search to get there. You get the same effect by giving each agent a small toolset that matches its role.

The number of tools isn't the only problem. Overlap matters too. Anthropic's engineering guidance warns that when tools overlap in function or have a vague purpose, agents can get confused about which ones to use, and that too many tools or overlapping tools can also distract agents from pursuing efficient strategies. The tool definition guidance says the same thing from the other side: fewer, more capable tools reduce selection ambiguity and make your tool surface easier for Claude to navigate.

Sources123

2.Restrict each subagent to the tools its role needs

In a multi-agent design, the tool list you give each subagent is the main way to control what it does. An agent that holds a tool outside its specialty may use it even when it shouldn't. The exam guide's example is a synthesis agent that starts running its own web searches instead of working with the research it was given. The vendor documentation here doesn't describe that exact failure. What it does say is that subagents can be limited to specific tools, which reduces the risk of unintended actions. Its example is a doc-reviewer subagent that only has Read and Grep, ensuring it can analyze but never accidentally modify your documentation files. Claude Code lists the same benefit for subagents: enforce constraints by limiting which tools a subagent can use.

Watch the default. If you leave out the tools field, the subagent doesn't get a minimal set. It gets everything. The frontmatter reference says the field inherits every tool available to subagents if omitted. Scoping only happens if you write it down. You can do that two ways: an allowlist (tools) or a denylist (disallowedTools).

---
name: code-improver
description: Scans files and suggests improvements for readability, performance, and best practices. Use after writing or modifying code.
 ? : Read, Grep, Glob
model: sonnet
---

Sources45

3.Constrained tools and narrow cross-role access

Choosing the right number of tools is only part of the job. You also choose which tools an agent gets. A generic tool such as fetch_url lets an agent do far more than its role needs. The exam guide's fix is a constrained replacement, such as a load_document tool that checks the URL really points to a document before fetching it. The documentation here doesn't include that example. It does teach the same principle. It warns against tools that merely wrap existing software functionality or API endpoints, and gives an address-book example: build a search_contacts or message_contact tool instead of a list_contacts tool. In both cases the tool itself does less, so the agent can't use it for the wrong thing.

Claude Code shows a version of this that is enforced outside the model. The db-reader subagent below gets only Bash, which on its own is very broad. A PreToolUse hook then runs a validation script before every Bash call. The script blocks SQL write keywords and allows only SELECT queries. The limit is enforced in code. It doesn't depend on the agent following instructions in its prompt.

---
name: db-reader
description: Execute read-only database queries
tools: Bash
hooks:
  PreToolUse:
    - matcher: "Bash"
      hooks:
        - type: command
          command: "./scripts/validate-readonly-query.sh"
---

Strict scoping causes a problem when an agent has a frequent, small need that belongs to another role. The exam guide's example is a synthesis agent that keeps needing to check a fact. The exam's recommended pattern is a narrow cross-role tool, such as verify_fact, for that one common need, while anything more complex goes back to the coordinator. The synthesis agent doesn't get the research agent's full search toolset. The sources don't describe this pattern directly, so treat it as an application of the scoping principle. The closest documented mechanism is on the coordinator side: a coordinator's tools field can name which subagents it may spawn. Complex work is then routed only to the specialists you allow.

---
name: coordinator
description: Coordinates work across specialized agents
tools: Agent(worker, researcher), Read, Bash
---

Sources25

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Giving every agent the full tool library makes the system more capable, because each agent can handle anything that comes up.Why is that wrong?

   Selection accuracy drops as the number of available tools grows. A focused set of 3–5 relevant tools is what keeps tool choice reliable.

   Covered in Why fewer tools per agent means better tool selection

2. 2.If you don't list any tools for a subagent, it starts with no tools, or only a safe minimal set.Why is that wrong?

   Leaving out the tools field gives the subagent every tool available to subagents. Scoping only happens if you set tools or disallowedTools explicitly.

   Covered in Restrict each subagent to the tools its role needs