40 Tools, Wrong Picks, High Latency: Scoping Tools Per Agent

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 17)

▶ Watch on YouTube & subscribe to The Stack Underflow

An agent starts with three tools and works fine. Six months later, after every team bolted on their own capability, it has 40 — search_web, search_docs, search_internal_kb, get_customer, get_customer_v2, lookup_account, and two dozen more with names and descriptions that blur together. Now the agent picks the wrong tool more often, and every single turn is slower, because the model has to read all 40 tool definitions before it decides what to do. Nobody removed a tool. Somebody just kept adding them, assuming “more capability” and “more tools” were the same thing. They are not — and this question is exactly where that assumption breaks.

The one-sentence version: More tools is not more capable — past a certain point, every tool you add to an agent’s registry makes tool selection worse and every turn slower, so the fix is to reduce and group tools (namespacing or MCP servers) and load only what’s relevant to the task at hand.

The question

An agent has 40 tools registered. Selection is wrong and latency is high. What’s the best design move?

• A) Add more tools for coverage
• B) Reduce and group them — namespacing or MCP servers, load only what’s relevant
• C) Increase max tokens
• D) Lower the passing bar

Pause here and pick an answer before you scroll — this is a Domain 2 (Tool Design & MCP Integration) practice question from the Claude Certified Architect prep series, and the value is in reasoning through the mechanism, not in seeing the letter.

The answer

B — reduce and group the tools. Namespace them, move related capabilities behind dedicated MCP servers, and load only the subset relevant to the current task instead of registering all 40 for every call.

The mechanism is a curve, not a cliff. As you register more tools with an agent, selection accuracy does not degrade gracefully — it holds steady for a while and then falls as the tool list grows past what the model can cleanly discriminate between, especially once descriptions start to overlap. Latency rises in parallel, because every tool’s name, description, and JSON schema gets serialized into the model’s context on every single turn, whether or not that tool is ever called.

SELECTION ACCURACY vs TOOLS REGISTERED

accuracy
  100% │███
       │   ███
       │      ███
       │         ███▄▄
       │              ▀▀▀▄▄▄          ← accuracy falls as tools climb
       │                    ▀▀▀▄▄▄       past the point where descriptions
   0%  │                          ▀▀▀    start overlapping
       └──────────────────────────────────► tools registered
        3      10      20      30     40

latency  ↑ rises the same direction — every tool definition
         is serialized into context on every turn, used or not

The design move is to collapse the flat list into scoped groups:

BEFORE: 40 loose tools, all loaded, every turn
┌────┬────┬────┬────┬────┬────┬────┬────┬────┬────┐
│ t1 │ t2 │ t3 │ t4 │ t5 │ ...│ ...│ ...│ ...│ t40│  → one giant selection surface
└────┴────┴────┴────┴────┴────┴────┴────┴────┴────┘

AFTER: grouped behind namespaces / MCP servers, loaded on demand
┌───────────────┐  ┌───────────────┐  ┌───────────────┐  ┌───────────────┐
│ crm-mcp        │  │ docs-mcp      │  │ billing-mcp    │  │ search-mcp    │
│ (4 tools)      │  │ (6 tools)     │  │ (5 tools)      │  │ (3 tools)     │
└───────────────┘  └───────────────┘  └───────────────┘  └───────────────┘
        ▲                                                          
        └── only the server(s) relevant to THIS task get loaded into context

Namespacing (crm.get_customer instead of a bare get_customer competing with billing.get_customer) removes the ambiguity that causes wrong picks even when you keep the same total tool count. Grouping behind MCP servers goes further: it lets you load a whole capability cluster only when the task actually needs it, so an agent doing a billing lookup never even sees the docs-search tools competing for the model’s attention. Both moves attack the same root cause — the model chooses tools from a flat, ever-growing menu, so the fix is to shrink and organize the menu, not to hand it a bigger one.

Why the other options fail

• A) Add more tools for coverage — this is the opposite of the fix. The problem statement is already “selection is wrong with 40 tools registered.” Adding a 41st, 42nd, and 43rd tool for edge-case coverage widens the exact selection surface that’s causing the wrong picks, and pushes latency further up the same curve. Coverage gaps are a real problem, but you solve them by improving or consolidating existing tools, not by piling on more candidates for the model to sort through.

• C) Increase max tokens — this changes how much output the model can generate, not how well it discriminates between forty candidate tools before it starts generating. A bigger output budget does nothing to fix a selection-accuracy problem, and it does nothing to fix latency either — if anything, allowing longer responses tends to make each turn slower and more expensive, not faster. This option treats a symptom (the run feels slow) with a lever that isn’t even connected to the cause.

• D) Lower the passing bar — there is no “passing bar” in a live agent’s tool-selection mechanism to lower; this reads like it was pulled from grading criteria, not system design. Even read charitably as “accept lower-confidence tool picks,” it doesn’t fix anything — it just stops surfacing the mistake. The agent still calls the wrong tool; you’ve only made the system less likely to flag that it happened.

The concept behind it

This question sits on a general principle worth internalizing beyond the exam: a tool registry is a context-budget line item, and tool selection is a discrimination problem, not a coverage problem.

Every tool you register costs you twice. First, it costs tokens — the name, description, and full JSON schema for every registered tool get serialized into the model’s context on every turn of every conversation that agent handles, whether or not that tool is ever invoked. Second, and more subtly, it costs accuracy — the model has to pick the single best tool out of the full registered set for every action, and the more near-duplicate or loosely-described tools sit in that set, the more often it picks wrong. (That second failure mode — vague, overlapping descriptions causing misfires even with a small tool count — is its own practice question; see Why Does Claude Pick the Wrong Tool? It compounds with tool count: the more tools you have, the more of them are likely to have descriptions that blur together, because nobody audits forty descriptions for overlap the way they’d audit four.)

The fix pattern has three levers, and they combine:

Notice the pattern generalizes past tool design into agent architecture: it’s the same reasoning behind giving a subagent a scoped, minimal toolset rather than the full org-wide registry, and the same reasoning behind splitting one over-loaded agent into several narrower ones. A 40-tool generalist agent and a 4,000-line monolithic function have the same disease — too much undifferentiated surface area for the thing consuming it (a model, or a maintainer) to reason about correctly. The cure is decomposition and scoping, not addition.

One more nuance worth being precise about for the exam: the fix is not “fewer tools, period.” It’s “fewer tools visible to the model at once.” An organization can legitimately need 200 tools across its systems. The design discipline is making sure any single agent, on any single turn, only sees the handful relevant to what it’s actually doing right now — which is precisely what namespacing and per-task MCP loading deliver.

FAQ

How many tools is “too many” for one agent? There’s no fixed universal number — it depends on how distinguishable the descriptions are and how much context budget you’re willing to spend on the registry every turn. The signal to watch isn’t a tool count, it’s the trend: if selection accuracy is dropping and turn latency is climbing as you add tools, you’ve crossed the point where the registry needs to be grouped and scoped, regardless of the exact count.

Does grouping tools behind MCP servers add latency of its own? It can add a small amount — a connection or discovery round-trip to mount a server — but that cost is typically far smaller than the accuracy loss and per-turn token cost of keeping 40 flat tool definitions in context on every single call. You’re trading a one-time or per-task mounting cost for a savings on every turn.

Is namespacing the same thing as using multiple MCP servers? No — they’re complementary, not interchangeable. Namespacing is a naming convention (crm.get_customer) that removes ambiguity even within a single flat registry. Using multiple MCP servers is a deployment and loading decision — it lets you avoid registering tools the current task doesn’t need at all. You can namespace tools within one server, and you can also split namespaced groups across servers for on-demand loading; most well-designed systems do both.

Should every subagent get its own toolset? Generally yes, scoped to what that subagent’s job actually requires. A billing subagent doesn’t need document-search tools in its registry any more than a CRM lookup needs delete-production access. Scoping tools per subagent is the same principle as this question applied at the multi-agent level — it keeps each agent’s selection surface small and relevant.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

Where this fits in the CCA series

This is Domain 2 (Tool Design & MCP Integration, roughly 18% of the exam) — start with the Claude Certified Architect exam guide for all five domains on one diagram, and see MCP explained on one diagram for the mechanism behind the “MCP server” half of this answer.

The tool-selection failure mode here is the volume version of a problem covered in more depth in Why Does Claude Pick the Wrong Tool?, which is really about description quality — a topic revisited directly in How to Write Tool Descriptions That Work. And the “MCP server vs inline” half of this question’s fix gets its own full practice question in Same Tool, Three Agents: Inline Tool or MCP Server?.

Browse all tutorials for the rest of the series.