What this domain tests
18% — roughly 11 of 60 questions, fourth by weight on CCA-F (behind Agentic at 27% and Claude Code and Prompt Engineering at 20% each). First-hand reports call the Foundations exam the most memorization-dense of the four certifications, and this domain is where the memorizable surface is widest: exact field names in error payloads, exact tool_choice values, exact config file paths, and exactly which built-in tool does which job. "You either know it or you don't" applies here more than anywhere except the agentic loop.
Three of the six published exam scenarios name this domain as primary:
- Customer Support Resolution Agent — a backend reached entirely through custom MCP tools (get_customer, lookup_order, process_refund, escalate_to_human). Error structure and tool boundaries dominate.
- Multi-Agent Research System — tool distribution across coordinator and subagents, and what happens when a synthesis agent can reach a web search tool.
- Developer Productivity with Claude — built-in tools (Read, Write, Bash, Grep, Glob) plus MCP server integration.
Question species split roughly evenly. Recall items ask which value, which file, which flag. Judgment items ask rename-or-split, custom-server-or-community-server, restrict-tools-or-improve-descriptions. The judgment items almost always have a distractor that "adds more instructions to the system prompt" — that is the tell, not the answer.
Background worth one sentence and no more: MCP servers are reached over local (subprocess) or remote (HTTP) transports, and Claude can request several tools in one assistant turn. Neither transport internals nor parallel-call mechanics appear in this domain's objectives — do not spend study time there.
Theory outline
1. Tool descriptions and boundaries (Task 2.1)
The single most important claim in this domain: the tool description is the primary mechanism the model uses to select a tool. Not the name, not the schema, not the system prompt. If selection is unreliable, the description is the first place to look — and a minimal description ("Analyzes content") is the named cause of unreliable selection among similar tools.
What a description must carry:
| Element | Why the exam cares |
|---|---|
| Input formats | The model must know what shape of argument is valid before it commits to the call |
| Example queries | Concrete cases anchor selection far better than an abstract summary |
| Edge cases | Tells the model when the tool will not work, which is half of choosing correctly |
| Boundary explanation | Explicit "use this instead of X when …" is what separates near-identical tools |
The canonical failure: analyze_content and analyze_document sit side by side with near-identical descriptions, and the agent misroutes between them. The guide gives two distinct repairs, and the exam expects you to pick the one that fits the stem:
| Repair | Use when |
|---|---|
| Rename + rewrite the description — analyze_content becomes extract_web_results with a web-specific description | Two tools genuinely do different things; only the labeling overlaps |
| Split the generic tool — analyze_document becomes extract_data_points, summarize_content, verify_claim_against_source, each with a defined input/output contract | One tool is doing several jobs, so no description can be unambiguous |
The diagnostic: if the overlap disappears once you say what each tool is for, rename. If the tool is genuinely multi-purpose, no wording saves it — split it.
The buried variable: the system prompt. Tool selection is also keyword-sensitive. A system prompt line like "always research thoroughly before answering" can create an unintended association that pulls the agent toward a research tool even when the descriptions are clean. When a stem says descriptions were rewritten and misrouting persists, the answer is to review the system prompt for keyword-sensitive instructions overriding them.
2. Structured error responses for MCP tools (Task 2.2)
MCP communicates tool failure with the isError flag. (Distinguish this from the Messages API, where a tool_result content block carries is_error — the concept is the same, the spelling is not, and near-miss field names are exactly what a memorization-heavy exam tests.)
Flagging the error is the floor. The graded skill is what metadata rides along, because the agent's recovery decision is only as good as the information it gets back.
The four error classes:
| Class | Examples | Agent should |
|---|---|---|
| Transient | Timeouts, service unavailable | Retry — the same call may succeed |
| Validation | Invalid input, malformed argument | Fix the arguments and re-call; retrying unchanged is pointless |
| Business | Policy violation (return window expired) | Stop and explain to the user in human terms |
| Permission | Caller not authorized | Stop; escalate or request access — never retry |
The fields to memorize:
- errorCategory — transient / validation / permission.
- isRetryable — boolean. This is what prevents wasted retry attempts; without it the agent guesses, and a non-retryable business error gets hammered five times.
- A human-readable description — so the agent can explain rather than parrot a code.
- retriable: false plus a customer-friendly explanation on business rule violations, so the agent tells the customer what actually happened instead of "the operation failed."
Why uniform errors are an anti-pattern: a generic "Operation failed" collapses all four classes into one, and the agent cannot make an appropriate recovery decision. It will either retry things that can never succeed or give up on things that would have worked on the second attempt. Structured metadata is not politeness — it is the input to a control decision.
Where recovery happens. In multi-agent systems, subagents implement local recovery for transient failures and propagate to the coordinator only what they cannot resolve locally — and when they do propagate, they carry partial results and what was attempted. A subagent that escalates every timeout turns the coordinator into a retry loop; a subagent that swallows an unrecoverable failure hands up a silent gap.
Access failure versus valid empty result. A search that timed out and a search that ran cleanly and matched nothing are opposite facts that look identical if you report both as "no results." The first needs a retry decision; the second is a successful query and should be reported as such. This distinction recurs in Domain 5's error-propagation objectives — expect it twice.
3. Tool distribution and tool_choice (Task 2.3)
Tool count degrades selection reliability. The guide is quantitative about it: giving an agent 18 tools instead of 4–5 increases decision complexity and makes selection less reliable. This is the answer to a whole family of scenarios where an agent with a sprawling toolbelt picks wrong — the fix is scoping, not a longer system prompt.
Agents misuse tools outside their specialization. The named example: a synthesis agent that has web search will attempt web searches instead of synthesizing what it was given. Scoped tool access means each agent gets only what its role requires.
But scoping absolutely is not the goal — limited cross-role tools for specific high-frequency needs are correct design. The guide's example: give the synthesis agent a narrow verify_fact tool so it can check a claim inline, and route complex verification through the coordinator. The pattern is "narrow tool for the common case, coordinator for the hard case," not "one tool per agent, ever."
Constrain rather than generalize. Replace a generic fetch_url with a load_document that validates document URLs. A constrained alternative removes a class of misuse instead of documenting against it.
tool_choice — three configurations, all memorizable:
| Setting | Behavior | Use for |
|---|---|---|
| "auto" | Model decides whether and which tool to call | The default agentic case |
| "any" | Model must call some tool — it cannot return conversational text | Guaranteeing an action happens instead of a chatty non-answer |
| Forced: {"type": "tool", "name": "..."} | This specific tool is called | Guaranteeing an ordering, e.g. forcing extract_metadata before any enrichment tool runs |
The ordering nuance the exam likes: forced selection guarantees the first call, and you then process subsequent steps in follow-up turns. Forcing a tool does not script the whole pipeline — it pins step one, and the loop continues normally afterward.
4. Integrating MCP servers (Task 2.4)
Scopes — memorize both paths:
| Scope | File | For |
|---|---|---|
| Project | .mcp.json | Shared team tooling — lives in version control, so every teammate gets the server |
| User | ~/.claude.json | Personal or experimental servers — not shared |
The diagnostic scenario writes itself: a teammate doesn't have the MCP server everyone else uses, because it was configured at user level instead of project level. (Domain 3 runs the identical shape for CLAUDE.md — same reasoning, different file.)
Environment variable expansion in .mcp.json handles credentials: reference a token as ${GITHUB_TOKEN} rather than pasting the secret, and the config can be committed safely. Any option that involves committing a literal token is wrong on security grounds alone.
Discovery: tools from all configured MCP servers are discovered at connection time and are available simultaneously. There is no per-turn loading step to design around — which is also why tool sprawl (section 3) is a real risk once several servers are configured.
Resources are the underused primitive. MCP resources expose content catalogs — issue summaries, documentation hierarchies, database schemas — so the agent can see what data exists without making exploratory tool calls to find out. When a stem complains about wasted turns spent discovering what is available, resources are the answer, not a bigger context window or a better prompt.
Descriptions matter for MCP tools too, with a specific failure mode: if an MCP tool's description is thin, the agent will prefer a built-in like Grep over a more capable MCP tool. The repair is to enhance the MCP tool description to explain its capabilities and outputs in detail — same principle as Task 2.1, applied at the integration boundary.
Build versus adopt: choose existing community MCP servers for standard integrations (Jira is the guide's example) and reserve custom servers for team-specific workflows. Writing your own Jira server is the wrong answer when a maintained one exists.
5. Built-in tools: Read, Write, Edit, Bash, Grep, Glob (Task 2.5)
The most mechanically recallable block in the domain. Learn the split cold:
| Tool | Searches / acts on | Canonical use |
|---|---|---|
| Grep | File contents | Find all callers of a function; locate an error message string; find import statements |
| Glob | File paths by pattern | Find files by name or extension — the guide's example pattern is **/*.test.tsx |
| Read | Whole file | Load full contents before reasoning or rewriting |
| Write | Whole file | Full-file write |
| Edit | A targeted region | Modify using unique text matching |
The Edit failure mode is a named exam fact: when Edit cannot find a unique text match, the reliable fallback is Read + Write — load the full file, then write it back with the modification. Retrying Edit with the same non-unique anchor is the wrong answer; so is deciding the file cannot be modified.
Exploration strategy, which is judgment rather than recall: build codebase understanding incrementally — start with Grep to find entry points, then Read to follow imports and trace flows. Reading all files upfront is the named anti-pattern; it fills context with material that turns out to be irrelevant (and Domain 5 will make you pay for it).
Tracing usage across wrapper modules has a specific two-step shape worth memorizing: first identify all exported names, then search for each name across the codebase. A single Grep for the original function name misses everything that reaches it through a re-export.
Worked problems
Problem 1. A research agent has two tools: analyze_content ("Analyzes content and returns insights") and analyze_document ("Analyzes documents and returns insights"). The agent routes web search results to analyze_document about a third of the time. Descriptions were recently lengthened but the misrouting persists. What is the highest-value fix?
A. Increase the model's thinking budget so it deliberates longer before calling a tool B. Rename analyze_content to extract_web_results and rewrite its description to be web-specific, stating what it handles and when to use it instead of the document tool C. Set tool_choice to "any" so the model always calls a tool D. Merge both into one analyze tool with a source parameter
Approach: Two tools whose descriptions are near-identical is the guide's own example of description-caused misrouting. The repair when the tools genuinely do different things is rename plus a differentiated description, including the explicit boundary ("use this for web results, not documents").
Why the others fail: A treats a specification problem as a reasoning problem — the model isn't confused about how to think, it lacks the information to distinguish two labels. C guarantees a tool is called, which was never the problem; the wrong tool is still a tool. D looks tidy but moves the ambiguity into a parameter the model must now also select correctly, and it runs against the guide's direction of travel (split generic tools into purpose-specific ones, not the reverse).
Answer: B
Problem 2. An MCP tool returns { isError: true, message: "Operation failed" } for every failure — timeouts, invalid order IDs, and returns outside the 30-day window alike. Logs show the agent retrying expired-return requests up to five times and telling customers "something went wrong." What should the tool return instead?
A. The raw exception and stack trace, so the agent has maximum information B. Structured metadata — errorCategory (transient / validation / permission), an isRetryable boolean, and a human-readable description; with retriable: false and a customer-friendly explanation for policy violations C. isError: false with an empty result, so the agent moves on gracefully D. A retry count in the message so the agent knows when to stop
Approach: The symptom is exactly what uniform errors cause — the agent cannot tell a retryable outage from a permanent policy decision, so it retries the unretryable and can't explain the outcome. The guide names the fields: errorCategory, isRetryable, human-readable description, and retriable: false plus a customer-friendly explanation on business rule violations.
Why the others fail: A gives volume, not structure — a stack trace does not tell the agent whether to retry, and it dumps internals into context and possibly to the customer. C is the explicitly named anti-pattern of silently suppressing errors as success; the agent then reports a nonexistent refund as processed. D bounds the waste without fixing the cause: the expired return should not be retried once, let alone counted down from five.
Answer: B
Problem 3. In a multi-agent research system, the synthesis subagent has access to all 18 tools the coordinator can reach, including web_search. Traces show it running its own searches instead of synthesizing the findings it was handed, and its tool choices are erratic. What is the correct design change?
A. Add "do not use web_search" to the synthesis agent's system prompt B. Restrict the synthesis agent to its role's tools, adding a narrow verify_fact tool for the high-frequency case of checking a single claim, with complex verification routed through the coordinator C. Give every subagent all 18 tools so behavior is consistent across agents D. Set tool_choice to forced selection on a synthesize tool for every turn
Approach: Two named facts stack here — 18 tools instead of 4–5 degrades selection reliability, and agents with tools outside their specialization tend to misuse them (the guide's example is literally a synthesis agent attempting web searches). The fix is scoped access. The refinement that separates a good answer from a naive one is the limited cross-role tool: the synthesis agent still has a legitimate need to check facts, so it gets a narrow verify_fact rather than nothing.
Why the others fail: A is prompt-based guidance against a capability the agent still has — probabilistic, and it does nothing about the 17 other tools inflating decision complexity. C amplifies the exact cause. D forces one tool every turn, which breaks any multi-step synthesis that legitimately needs to verify something first.
Answer: B
Problem 4. A new engineer clones the team repo, runs Claude Code, and finds the shared internal-docs MCP server missing — everyone else has it. The server was added months ago by the tech lead and works on their machine. Where was it configured, and what is the fix?
A. It was added at user level in ~/.claude.json; move it to a project-level .mcp.json committed to the repo, with the auth token referenced through environment variable expansion B. The new engineer needs to restart Claude Code so tools are re-discovered C. It was added at project level; the new engineer should copy the tech lead's ~/.claude.json D. MCP servers cannot be shared across a team; each engineer configures their own
Approach: One person has it, nobody else does, and nothing was committed — that is the user-scope-versus-project-scope diagnostic. Project-level .mcp.json is the scope for shared team tooling precisely because it travels through version control. The second half of the answer matters: the token is handled with environment variable expansion so the committed file carries no secret.
Why the others fail: B addresses discovery timing — tools from configured servers are discovered at connection time, but a server that isn't in this machine's config will never be configured. C makes the problem permanent by hand-copying personal config, and would leak the tech lead's credentials. D is false; project scope exists for exactly this.
Answer: A
Problem 5. An agent exploring an unfamiliar TypeScript repo needs to find every test file, then find all callers of a function named resolveInvoice. Which built-in tools, in which roles?
A. Glob for both — pattern matching handles filenames and code alike
B. Glob with a pattern like **/*.test.tsx to locate test files by path, and Grep to search file contents for resolveInvoice
C. Read every file in the repo, then reason over the contents
D. Bash with a custom find pipeline for both, since built-ins are limited
Approach: The clean split is the recall fact: Glob matches file paths by pattern, Grep searches file contents. "All test files" is a filename-pattern question; "all callers of a function" is a contents question.
Why the others fail: A misapplies Glob to a contents search — a path pattern cannot find a function invocation inside a file. C is the named anti-pattern for codebase exploration: reading everything upfront instead of building understanding incrementally (Grep for entry points, then Read to follow imports), and it torches the context budget. D reaches for a shell when purpose-built tools exist; nothing in the stem exceeds what Grep and Glob do.
Answer: B
Problem 6. An enrichment pipeline must always call extract_metadata before any enrichment tool, because enrichment depends on the extracted fields. The system prompt says so; occasionally the model enriches first and produces garbage. What guarantees the ordering?
A. tool_choice: "auto" with a stronger instruction in the system prompt B. tool_choice: "any" so the model always calls a tool C. tool_choice forced to {"type": "tool", "name": "extract_metadata"} on the first turn, with subsequent steps processed in follow-up turns D. Remove the enrichment tools from the definition list until extraction completes
Approach: "Must always" plus an occasional violation means the prompt is doing enforcement work it cannot guarantee. Forced tool selection is the configuration that pins a specific tool — and the guide's framing includes the follow-up: it guarantees the first call, and the rest of the pipeline proceeds in subsequent turns normally.
Why the others fail: A leaves the decision with the model — "auto" plus louder wording is still probabilistic. B guarantees some tool is called, not which one; the model can still call an enrichment tool first. D describes dynamic tool-list mutation, which is not the mechanism the guide names for ordering, and it would confuse the model about what capabilities exist mid-conversation.
Answer: C
Exam traps
- "Improve the system prompt" as the fix for tool misrouting. Selection runs primarily on tool descriptions. Reach for the prompt only in the specific case the guide names: keyword-sensitive instructions creating unintended tool associations that override good descriptions.
- Rename versus split. Rename plus a differentiated description when two tools do different things and only the labels overlap; split into purpose-specific tools when one tool is doing several jobs. Both options appear together and the stem decides which.
- isError versus is_error. MCP uses the isError flag; the Messages API tool_result block uses is_error. Read the field name in the stem before you read the option.
- Generic error strings. "Operation failed" for everything is the named anti-pattern — it blocks recovery decisions. The graded answer names errorCategory, isRetryable, and a human-readable description, with retriable: false for business-rule violations.
- Retrying non-retryable errors. Validation, business, and permission failures do not get better on the second attempt. Only transient errors are retry candidates, and the flag exists so the agent doesn't have to guess.
- Silent error suppression. Returning an empty result as success hides a failure the coordinator needed to see. So does terminating the whole workflow on one subagent failure. Both are anti-patterns; local recovery plus structured propagation is the pattern.
- Access failure versus valid empty result. A timeout and a zero-match query must not report the same way. This is tested in both Domain 2 and Domain 5.
- More tools as a capability upgrade. 18 tools instead of 4–5 degrades selection reliability. Scoping is the fix — but do not over-correct: limited cross-role tools for high-frequency needs (verify_fact for the synthesis agent) are correct design, not a violation.
- tool_choice value confusion. "any" forces a tool, not a specific tool. Only forced selection, {"type": "tool", "name": "..."}, pins which one. Distractors swap these.
- .mcp.json versus ~/.claude.json. Project scope is the shared, version-controlled one; user scope is personal and experimental. "Only one teammate has it" always resolves to user scope. Committing a literal token instead of using environment variable expansion is wrong even when the scope is right.
- Missing MCP resources. When agents waste turns discovering what data exists, expose a content catalog as an MCP resource. Distractors offer better prompts or more tools.
- Building a custom server for a standard integration. Community servers for standard systems (Jira); custom servers for team-specific workflows.
- Grep/Glob inversion. Grep searches contents, Glob matches paths. Choosing Glob to find function callers is the most common single-fact miss in this domain.
- Retrying Edit after a non-unique match. The named fallback is Read + Write. Options that re-attempt Edit or declare the edit impossible are both wrong.