Domain 218% of the exam
Domain 2: Tool design and MCP integration
Why a model picks the wrong tool, what a failing tool should send back, and where MCP fits. An overview of Claude Certified Architect Domain 2, 18% of the exam.
A model calls the wrong tool when two descriptions blur into each other. It chooses from what you wrote about each tool, and the name counts for little.
Take a calendar assistant with two tools: one described as "gets events" and another described as "gets availability". Ask it whether Thursday afternoon is free and it is a coin toss which one it reaches for, because from the model's side both descriptions promise roughly the same thing. Rename them however you like and nothing improves. Say what each one returns, what it needs as input, and the cases where it beats the other, and the toss goes away.
Tool Design & MCP Integration is 18% of the CCAR-F, around 11 questions. Past better wording it covers tools that fail, agents that hold too many, and the protocol that brings outside systems in.
| Module | In one line |
|---|---|
| 2.1 · Tool interfaces | The first fix to try when an agent picks the wrong tool. |
| 2.2 · Structured errors | What a tool should return when it fails, so the agent can decide what to do next. |
| 2.3 · Tool distribution and choice | How many tools one agent can hold, and how to make a call compulsory. |
| 2.4 · MCP servers | Where a server's settings live, how secrets stay out of the repo, and whether to build one at all. |
| 2.5 · Built-in tools | The narrowest Claude Code tool that does the job. |
Cheapest fix first
Every misselection question starts at Tool interfaces (2.1), and the exam has a firm view on order. Rewriting the descriptions comes first because it is cheap and it targets the cause. The heavier remedies, the ones that change the architecture, come later and only if the cheap one fails. An option that jumps straight to the heavy end loses to the cheap fix, even when the remedy itself is sensible.
The system prompt can pull the model toward a particular tool whatever the descriptions say. If a scenario mentions a system prompt that leans hard on one tool, rewriting descriptions won't help, and the module shows how to spot that case.
Errors are part of the interface
When a tool fails and sends back nothing but a line of text, the agent has to guess whether to retry, try something else, or stop and tell someone. Structured errors (2.2) is about removing the guess. A useful failure says what kind of failure it was and whether trying again could ever work, and the module sorts failures into a small set of kinds, each with its own next move.
That distinction comes back in Domain 5, where a subagent's failure has to reach its coordinator intact.
Count before you fix
Two halves make up Tool distribution and choice (2.3). The first is about how many tools one agent should carry. There is a ceiling, the exam expects you to know roughly where it is, and past it no rewording will save you. A too-many-tools question looks just like a wrong-tool question, because the agent reached for the wrong thing in both. So count the tools in the scenario before you choose a remedy. A handful points at the descriptions. A long list means the toolkit has to be split or consolidated.
The second half is tool_choice, the setting that decides whether the model may answer in plain text or must call something. It has a few modes, and the name of one suggests a promise it doesn't make. When a question asks you to force a call, check whether it needs a tool or this tool.
Where MCP fits
The MCP servers module (2.4) is practical. It covers what contains what: the host holds the client, the client talks to servers, and servers never connect to one another, so an option that has them talking is a distractor. It also covers which configuration file is shared with your team through the repository and which stays on your machine, and how a committed config can point at a credential without containing it. The habit the exam rewards is checking whether a community server already exists before writing one for a common integration.
The most hands-on module in the domain is Built-in tools (2.5). Claude Code ships its own tools for finding and changing files, and the trap is mixing up the one that searches inside files with the one that matches file names. It also deals with what to do when an edit refuses to apply, and why reading a whole codebase up front is the most expensive way to begin.
What the modules add
All five modules go a good deal further than this: the kinds of error and the recovery each one calls for, where the tool ceiling falls and what to do past it, each tool_choice mode and the trap in one of them, the layers of MCP and where its config lives. Each module is short, and its ideas come back as quick recall on later evenings, so the distinctions are still there in the exam room. Full Access opens every one of them, and Spaced decides which you see tonight, so the time you have goes on learning.