Claude Certification Blog
Tool design on CCAR-F: 18%, and two objectives nobody drills
The second-largest domain on the architect foundations exam contains two objectives almost nobody drills, and one of them turns on a distinction most candidates get backwards.
Tool design on CCAR-F is an 18% domain — about 11 of 60 items — and the second-largest on that paper. Its five objectives cover interfaces and boundaries, structured errors, distributing tools and configuring tool choice, integrating MCP servers, and selecting among the built-in tools. Two of the five get almost no attention in circulating study material, and together they are worth roughly four items.
Five objectives, eleven items
| Objective | Subject | What it turns on |
|---|---|---|
| O08 | Interfaces, descriptions and boundaries | How a tool gets chosen at all |
| O09 | Structured error responses | What a caller can do with what came back |
| O10 | Tool distribution and tool choice | Who holds what, and whether a call is required |
| O11 | MCP server integration | Configuration and scope, not deployment |
| O12 | Selecting the built-in tools | Using the one that fits, and reading before editing |
The description is the interface
A model picks a tool by reading what the tool claims to do. That makes the description the interface in a way the schema is not — a schema constrains the shape of an argument and says nothing about which tool should have been called.
So the recurring failure is two tools whose stated purposes overlap, and the recurring wrong answer is a stronger prompt telling the model which to prefer. Repair it at the point of ambiguity: say what each one covers and, more usefully, where it stops. The other half of the contract — arguments, permitted values, units — is in tool use and structured output.
Empty is not an error
The structured-error objective is decided by whether a caller can act on what it received. Three outcomes need to be distinguishable, and the middle one is where candidates go wrong: a search that ran perfectly and found nothing has produced information, not a fault.
Call it a fault and something downstream repeats work that was already complete. Return it bare, with nothing saying what happened, and it reads exactly like a call that never executed. The general form of this — a failure travelling with enough context for the receiver to choose a response — is in troubleshooting on the Claude exams.
Who holds which tool
The distribution objective is two decisions in one. The first is which agent holds which capability, and it is a control rather than a convenience: a component that never needs a destructive action should not be able to take one, because what is reachable constrains behaviour more reliably than what is requested.
The second is tool choice as configuration. Where a call must happen, that is a setting rather than a hope; where a plain answer is sometimes correct, forcing a call is wrong. And selection accuracy falls as the set grows, so trimming an agent’s tools improves its decisions and its exposure at once — the same judgment CCAR-P names as capability bloat in its integration domain.
Fix the contract, not the prompt
Almost every item in this domain resolves the same way. If the wrong tool fired, something about the description, the boundary or the set is wrong. An option that adds instruction is treating a contract problem as a wording problem, and it is offered because that is what people try first.
The built-in tools nobody drills
One objective covers selecting and applying the tools that come with the environment, and it is skipped because it reads as too elementary to revise. It is about two items, and the judgments in it are ordinary and specific: use the one that answers the question you actually have.
Looking for text inside files is a different job from looking for files by name, and picking the second when you needed the first returns confident nothing. Opening every file to find one line costs in proportion to how much code exists, not to how narrow the question was. And changing something you have not looked at is a guess about its current contents dressed as an edit — locate first, then change what you found.
Integration, not infrastructure
The MCP objective is about wiring a server into a workflow: how it is configured, who can see it, what it offers, and how a failure behaves. Deploying and hosting one is on the out-of-scope list — CCAR-F being the only track that publishes such a list at all.
The scoping judgment is the reliably examinable part. A server the whole team depends on belongs where the team gets it; something personal or experimental belongs at an individual scope, where it does not silently become everyone’s dependency. What the protocol is and where each track weights it is in MCP explained for the Claude exams.
Key takeaways
- Eighteen percent, eleven items, five objectives. Second-largest domain on CCAR-F behind agentic architecture.
- The description is how selection happens. Overlapping purposes are a contract defect, not a prompting one.
- A correct search that found nothing is a finding. Call it a failure and something downstream repeats completed work.
- Trimming a tool set does two jobs. Better selection and smaller exposure from one decision.
- The built-in tools are worth two items. Match the tool to the question, and locate before you change anything.
- Integration is in scope; hosting is not. Configuration, discovery, scoping and failure behaviour are what get asked.
Four items sitting in the objectives nobody revises
Error semantics and built-in tool selection both read as too obvious to study, and both are worth about two items each on a 60-item paper. A timed paper is the quickest way to find out whether obvious and automatic are the same thing for you. Our claude certification study guide covers how to sequence them.
See the CCAR-F blueprintQuestions
Frequently asked
The follow-up questions people search next.
How big is the tool design domain on CCAR-F?
Tool Design and MCP Integration is 18% of the exam — about 11 of 60 items — across five objectives, which makes it the second-largest domain on that paper behind agentic architecture at 27%.
Why does a tool description matter so much?
Because it is how selection happens. A model chooses a tool from what its description says it does and where it stops. Two descriptions that overlap produce selection errors no prompt can fix, so the repair belongs in the contract rather than in the instruction.
Should an empty result be reported as an error?
No, and this is examined directly. A query that executed correctly and matched nothing has told you something true. Call it a failure and something downstream will run again a call that had already done its job, and a bare empty response looks exactly like a call that never executed.
Are the built-in tools really examined?
One objective covers selecting and applying them, which is roughly two items. It reads as too basic to revise, and the judgments are real: search contents when you need contents, match names when you need names, and locate before you change anything.
Does the exam test how to deploy an MCP server?
No. Deploying and hosting servers appears on the CCAR-F out-of-scope list — the only such list published across the four guides. Configuration, discovery, scoping and what happens when a server fails are examined; infrastructure is not.
Keep reading
Related posts
Not affiliated with, or endorsed by, Anthropic or Pearson VUE. Details are summarised from publicly published program information and can change — always confirm against the official exam guide before booking.