This domain is about 18% of the exam, roughly 11 of its 60 questions.

Every point below comes from Anthropic's official documentation; each section lists its sources.

Think first When an agent keeps calling the wrong one of two similar tools, what should you change first, and why?

Why it matters: Questions describe an agent that misroutes requests and ask which change to its tools or prompt fixes it first.

Claude picks a tool by matching the user's request against each tool's name and description. Vague or overlapping descriptions cause misrouting. The recommended first fix is to expand each tool's description.

Tool descriptions are the main signal for tool selection. With the default tool_choice of auto, Claude calls a tool when the request matches its described capability and the answer is not already in context. With an MCP server attached, a general question about that service gets a direct answer, not a tool call.

Exam trap A clear tool name is not enough on its own. When descriptions are minimal, the model lacks the context to tell similar tools apart.

Name, title and description serve different readers. An MCP tool also carries an inputSchema for its parameters. If a tool declares an output schema, servers must return structured results that conform to it, and clients should validate them.

Three fields of an MCP tool definition compared

Cover inputs, example queries, edge cases and boundaries. Say what the tool is for, what it accepts and returns, and when to use it over a similar tool. Describe parameters too: the get_weather example asks for a city and state. A stateful server should put its retention policy in the creation tool's description.

Near-identical descriptions send requests to the wrong tool. In the guide's scenario, an agent calls get_customer for order questions instead of lookup_order. Both had one-line descriptions and took similar identifiers. The same risk applies to analyze_content and analyze_document.

Exam trap Few-shot examples, a keyword routing layer or merging the tools are not the first fix. Examples cost tokens without curing the cause, routing bypasses the model's language understanding, and merging is more work than a first step.

You can also rename, split or constrain the tools themselves. Renaming analyze_content to extract_web_results, with a web-specific description, removes its functional overlap. Splitting breaks one generic tool into separate tools. Constraining swaps a generic tool for a narrower alternative.

Renaming, splitting and constraining a tool compared

More tools make selection less reliable. The guide contrasts 18 tools with 4-5: each extra tool adds decision complexity. For dozens of tools across several MCP servers, set defer_loading to true with the Tool search tool. Only relevant tools then reach each query; the default is false.

Prompt wording can override well-written tool descriptions. Keyword-sensitive instructions can tie words to the wrong tool, so review the system prompt as well as the descriptions. Wording also shifts how readily Claude calls tools at all.

How system prompt wording shifts tool use

Exam trap Rewriting descriptions will not help if a system prompt line keeps steering a keyword to one tool. Check the prompt for such lines too.

• Descriptions are the main signal Claude uses to choose between similar tools.
• Fix misrouting first by expanding descriptions with input formats, examples, edge cases and boundaries.
• Rename or split overlapping tools so each has one purpose and clear inputs and outputs.
• Review the system prompt for keyword-sensitive lines that pull requests toward the wrong tool.

Sources: Tool use with Claude - Claude Platform Docs · MCP connector - Claude Platform Docs · Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Give Claude custom tools - Claude Code Docs · Tools - Model Context Protocol · Schema Reference - Model Context Protocol

Think first What should an MCP tool return when it fails, so the agent can choose the right recovery?

Why it matters: Questions describe a tool failure that the agent mishandles and ask which error response or recovery pattern fixes it.

A failed tool call should say so with isError and explain why in structured fields. A category and a retryable flag let the agent retry transient failures, stop on business rule violations, and explain clearly to users.

Set isError to true so Claude knows the call failed. In the Messages API, the matching field on a tool_result block is is_error. Given an error result, Claude can retry, try another tool or explain the failure. A handler error does not stop the agent loop.

Transient, validation, business and permission errors differ. Each type calls for a different move from the agent, so the tool should say which one occurred rather than just that something failed.

How three error types are handled

Return retriable: false and a customer-friendly explanation. A policy violation will not succeed on a retry. The friendly explanation gives the agent words it can pass on, so it explains the business error to the customer appropriately.

Separate access failures from valid empty results. A timeout needs a retry decision, while a query that ran and found no matches succeeded. Hiding errors by returning empty results as success is an anti-pattern. So is ending a whole workflow on one failure.

Exam trap An empty result caused by a timeout is not "no matches". Report it as an access failure so the coordinator can decide what to do.

Subagents handle transient failures themselves. A subagent should recover from transient failures locally. It passes up only errors it cannot resolve, with what it attempted and any partial results. A generic status like "search unavailable" hides that context from the coordinator.

Exam trap Escalating every transient timeout to the coordinator is not the pattern. Recover locally first and propagate only unresolved errors.

• Signal tool failures with isError: true, and add structured details.
• Include errorCategory, isRetryable and a human-readable description in error responses.
• Business rule violations get retriable: false and a customer-friendly explanation.
• A valid empty result is a success; an access failure needs a retry decision.

Sources: Give Claude custom tools - Claude Code Docs · Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Handle tool calls - Claude Platform Docs

Think first How do you decide which tools each agent gets, and when should you force a tool call?

Why it matters: Questions describe an agent that picks the wrong tool or skips one, and ask how to scope its tools or set tool_choice.

Each agent should hold only the few tools its role needs, because more tools mean harder choices and more misuse. The tool_choice setting then controls whether the model may call a tool, must call one, or must call a named one.

Too many tools hurt tool selection. The exam guide's example is 18 tools instead of 4 to 5: every extra tool adds decision complexity. Anthropic notes that selection degrades past 30 to 50 tools. Merging related operations into fewer tools with an action parameter reduces ambiguity.

Exam trap Adding more specialized tools to one agent does not make it more reliable. More choices lower its tool selection reliability.

Give each subagent only the tools its role needs. A synthesis agent that holds web search tends to misuse it. Restrict each subagent's tools through its AgentDefinition. For a frequent need, add one scoped cross-role tool, such as verify_fact, and route complex cases through the coordinator.

Swap a generic tool for a narrow, validating one. For example, replace a generic fetch_url tool with load_document, a constrained alternative that validates document URLs. Anthropic gives similar advice for computer use, the most general option: prefer narrower tools when they cover the use case.

auto may call a tool; any must; tool must call one named tool. With auto, the default when tools are provided, the model may answer in text instead. none blocks tools and is the default when no tools are given. Set any to guarantee a tool call rather than conversational text.

The four tool_choice settings compared

Exam trap any does not pick a specific tool. To make sure extract_metadata runs, force it by name.

Force one tool first, then continue in follow-up turns. Forcing extract_metadata makes sure that extraction runs before any enrichment tools. Later steps then run in follow-up turns. A forced response starts with the tool_use block, with no text and no thinking block before it.

Works: A tool_choice value that forces Claude to call the extract_metadata tool.

{"type": "tool", "name": "extract_metadata"}

• "type": "tool": forces one particular tool

Fails: any requires some tool call, but it does not make extract_metadata the one Claude calls.

{"type": "any"}

Check the model before forcing tools. On Claude Opus 5.5, Sonnet 5.5, Fable 5.1 and Mythos 5.1, any and tool return a 400 error. Changing tool_choice between requests can also cause prompt cache misses, so keep it stable.

Exam trap Do not assume forced tool choice works on every model. On those four models, a request with any or tool fails with a 400 error instead of forcing a tool call.

• Give each agent a small, role-specific tool set; extra tools reduce selection reliability.
• Use any to guarantee a tool call, and tool with a name to guarantee a specific one.
• auto is the default when tools are provided, and the model may then reply with text.
• Add a scoped cross-role tool like verify_fact for frequent needs, and route complex cases via the coordinator.

Sources: Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Define tools - Claude Platform Docs · Tool use with Claude - Claude Platform Docs · Tool search tool - Claude Platform Docs · Tool combinations - Claude Platform Docs · Troubleshooting tool use - Claude Platform Docs

Think first Where should a team's MCP servers be configured, and how do you make sure the agent actually uses them well?

Why it matters: Questions describe a team adding MCP servers and ask where to configure them, how to handle secrets, or why the agent ignores a tool.

Shared servers live with the project and personal ones with the user. Every configured server's tools are available together once connected. Clear tool descriptions and resources then steer the agent to the right tool and data.

Shared servers go in .mcp.json; personal ones in ~/.claude.json. Put team tooling at the project level so everyone gets it. Keep experiments at the user level so they stay yours.

The two MCP configuration scopes compared

Exam trap A personal experimental server does not belong in the project's .mcp.json. Configure it in user-scoped ~/.claude.json instead.

Reference tokens as ${GITHUB_TOKEN} in .mcp.json. The config file can be shared while each person supplies the token through the environment. No secret is committed.

Tools from every configured server load when the agent connects. They are all available to the agent at the same time. A project server and a personal server can both be in use in one session.

Rich MCP tool descriptions stop the agent from defaulting to Grep. Claude reads a tool's description to decide when to call it. Explain what the tool can do and what it returns, so the agent picks the more capable MCP tool.

Exam trap When the agent keeps choosing Grep over a more capable MCP tool, look at that tool's description first. Spell out its capabilities and outputs in detail.

Resources show the agent what data exists without exploring. Issue summaries, documentation trees and database schemas make good resources. The agent sees what is available up front, so it makes fewer exploratory tool calls.

Use a community server for standard integrations like Jira. Save custom servers for workflows that are specific to your team. For a standard integration, the existing community server is the better choice.

• Configure shared team servers in project-scoped .mcp.json and personal ones in ~/.claude.json.
• Use ${VAR} expansion in .mcp.json so credentials are never committed.
• Describe MCP tools in detail so the agent picks them over built-ins such as Grep.
• Prefer community MCP servers for standard integrations; build custom ones for team-specific workflows.

Sources: Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Resources - Model Context Protocol · Tools - Model Context Protocol · Give Claude custom tools - Claude Code Docs · MCP connector - Claude Platform Docs

Think first Given a task in an unfamiliar codebase, how do you decide between Grep, Glob, Read, Write, Edit and Bash?

Why it matters: Questions describe a coding task and ask which built-in tool, or which order of tools, fits it best.

Each built-in tool has one job: Grep searches file contents, Glob matches file paths, Read and Write handle whole files, and Edit makes targeted changes. Edit needs a unique text match, so Read plus Write is its fallback. Explore step by step instead of reading everything upfront.

Grep searches inside files; Glob matches file paths. Ask what you are looking for. Text inside code, such as a function name or an error message, calls for Grep. A file name or extension pattern calls for Glob.

Matching a search task to Grep or Glob

Exam trap Glob never looks inside files. If the task is to find where a function name appears in code, the answer is Grep, not Glob.

Read and Write handle full files; Edit changes one part. Choose Edit for a small, targeted change that can anchor on text appearing once in the file. Choose Read to load a full file and Write to replace its full contents.

Fall back to Read plus Write. Edit depends on a unique text match. If the text appears more than once, the edit fails. Read the full file, then Write the corrected version. The API text editor tool works the same way: a str_replace matching several places should return an error with is_error: true.

Exam trap Retrying Edit with the same non-unique text keeps failing. Give it more surrounding context to make a unique match, or switch to Read then Write.

Its commands are view, create and str_replace. view reads a whole file, a range of lines, or a directory listing. In view_range, line numbers start at 1, and -1 as the end line reads to the end. create writes a new file from file_text. str_replace needs old_str to match exactly, including whitespace and indentation.

Start with Grep for entry points, then Read to trace flows. Avoid reading every file upfront, because each file read adds to the context window. From an entry point, follow imports with Read. Large research reads can go to a subagent, which keeps them in its own context.

Exam trap Reading all files before starting is the wrong choice. It fills context with files that may not matter instead of following the flow from an entry point.

List the exported names first, then search for each one. Identify every name the wrapper module exports, then Grep for each name across the codebase. In a large codebase, code intelligence plugins can also jump to definitions and find references through a language server.

Built-in Grep and Glob try to hide denied paths; Bash does not. Claude Code makes a best-effort attempt to omit Read-denied paths from built-in Grep and Glob results. A Bash grep -r or find still lists those files. Content searches respect .gitignore by default, so folders such as node_modules/ stay out.

Exam trap Denying Read on a path does not hide it from a Bash grep -r or find over that directory.

One shell stays alive across tool calls. The working directory, environment variables and created files carry over to the next command. Sending restart: true starts a clean session. Interactive commands such as vim or less cannot run. Validate commands with an allowlist, since a blocklist misses commands it did not foresee.

• Grep finds text inside files; Glob finds files by path pattern.
• Edit needs a unique text match; when it fails on a non-unique match, use Read then Write.
• Explore with Grep first, then Read along the imports, rather than reading every file upfront.
• To trace a function through wrapper modules, list every exported name and search for each one.

Sources: Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Text editor tool - Claude Platform Docs · Explore the context window - Claude Code Docs · Set up Claude Code in a monorepo or large codebase - Claude Code Docs · Bash tool - Claude Platform Docs