Tool Design and MCP Integration Exam: Domain 2 Deep Dive

Domain 2 of the Claude Certified Architect, Foundations exam covers tool design and MCP integration, and it carries 18% of your total score. That is 10 to 11 items out of 60, enough to shift a borderline result by 50 to 80 scaled points. This guide maps every task statement in the domain, shows you what separates a high-quality exam answer from a weak one, and walks through the failure modes that appear most often in scenario items. If you are preparing for the tool design and MCP integration exam domain specifically, this is where to start.

What does Domain 2 actually cover, and how is it weighted?

Domain 2 sits at 18% of the CCAR-F exam, making it the third-largest domain behind Domain 1 (Agentic Architecture, 27%) and the joint second-place domains 3 and 4 (Claude Code Configuration and Prompt Engineering, 20% each). Domain 5 (Context Management) trails at 15%.

Within Domain 2, the exam tests five clusters of skill: writing tool descriptions that route correctly, designing error responses that propagate cleanly, managing tool overload and the tool_choice parameter, scoping MCP servers to the right context level, and selecting or building MCP servers for a given integration need. Every item is scenario-based, so the exam never asks you to recite a definition. It asks you to diagnose a broken system or choose between two plausible designs.

Our Tool Design & MCP Integration concept library maps all of these clusters to the 30 task statements in the full exam blueprint.

How do tool descriptions function as a routing mechanism?

Tool descriptions are the primary signal Claude uses to decide which tool to call. They are not documentation for human readers; they are selection criteria for the model. A description that is vague, overlapping with another tool, or contradicted by the system prompt will cause misrouting, and misrouting is the most common failure mode tested in Domain 2 scenario items.

The exam tests three things here:

1. Specificity. A description that says "retrieves data" is almost always wrong. A description that says "retrieves the current account balance for a single customer ID from the billing database; do not use for transaction history" is almost always right.
2. Non-overlap. When two tools share a description space, Claude will pick arbitrarily. The fix is tool splitting for specificity: decompose a broad tool into two narrow ones, each with a description that covers exactly one use case.
3. Conflict resolution. If the system prompt says "always use the audit tool for financial queries" but the tool description for the audit tool says "use for compliance reporting only," Claude faces a conflict. The exam expects you to know that system prompt and description conflicts must be resolved at the description level, not papered over with additional prompt instructions.

A practical diagnostic: if you can imagine two different tools whose descriptions would both match a given user request, you have a tool-splitting problem. If you can imagine the model ignoring a tool entirely because its description sounds optional, you have a salience problem.

{
  "name": "get_account_balance",
  "description": "Returns the current balance for a single customer account. Input: customer_id (string). Use ONLY for balance lookups. For transaction history, use get_transaction_history instead.",
  "input_schema": {
    "type": "object",
    "properties": {
      "customer_id": { "type": "string" }
    },
    "required": ["customer_id"]
  }
}

Compare that to a weak description like "Gets account information". The weak version will misroute on roughly half of realistic prompts involving account data.

What is the MCP isError flag, and why does the exam test it so heavily?

The Model Context Protocol defines a structured error response format. When a tool call fails, the server should return a result object with isError: true and a content array carrying a machine-readable error message. This pattern matters because it keeps the agentic loop running: Claude can read the error, decide whether to retry, escalate, or route to a fallback, rather than treating a failed tool call as a successful empty result.

The exam distinguishes four error categories that architects must route differently:

The last row is the one candidates most often get wrong. An empty result set is not an error. Returning isError: true for a query that legitimately returns nothing will cause Claude to retry indefinitely or escalate unnecessarily. The access failure vs valid empty result distinction is a standalone concept in our library because it appears in exam scenarios repeatedly.

{
  "isError": true,
  "content": [
    {
      "type": "text",
      "text": "ERROR_CODE: PERMISSION_DENIED | resource: billing_records | customer_id: C-4821 | suggested_action: escalate_to_billing_team"
    }
  ]
}

Structured error metadata like this gives Claude enough signal to make a routing decision without hallucinating a cause. A plain "error occurred" string forces the model to guess.

How does tool overload degrade performance, and what does the exam expect you to do about it?

Tool overload occurs when Claude is presented with more tools than it can reliably discriminate between. The tool overload problem is not just a performance concern; it is a reliability concern. When the tool list is long and descriptions overlap, the model's selection accuracy drops, latency increases, and the probability of an unnecessary tool call rises.

The exam tests two remedies:

1. tool_choice configuration. The tool_choice parameter lets you constrain which tools Claude may call in a given turn. Setting it to {"type": "tool", "name": "specific_tool"} forces a single tool call. Setting it to {"type": "any"} allows any tool but prevents a text-only response. Setting it to {"type": "auto"} (the default) gives Claude full discretion. The exam presents scenarios where the wrong tool_choice setting causes either over-calling or under-calling, and asks you to identify the correct configuration.

2. Tool distribution across agents. In a multi-agent system, the right answer is often to give each subagent a narrow, role-specific tool set rather than giving every agent access to the full catalogue. Scoped cross-role tools and tool distribution strategy design cover this pattern in detail.

# Forcing a specific tool call for a high-stakes financial operation
response = client.messages.create(
    model="claude-opus-4-5",
    max_tokens=1024,
    tools=tools,
    tool_choice={"type": "tool", "name": "audit_log_write"},
    messages=[{"role": "user", "content": user_message}]
)

The exam consistently rewards deterministic solutions over probabilistic ones when stakes are high. Forcing tool_choice for a compliance-critical write operation is the kind of answer that scores well.

What is the MCP scoping hierarchy, and how does it affect exam answers?

MCP servers can be scoped at three levels: user-level (available across all projects for a given user), project-level (available to all agents in a project), and session-level (available only for the current session). The MCP scoping hierarchy determines which agents can see which servers, and getting the scope wrong is a common architectural mistake.

The exam presents scenarios where a server scoped too broadly creates a security or governance problem, and scenarios where a server scoped too narrowly causes agents to fail because they cannot reach a required resource. The correct answer is almost always the narrowest scope that satisfies the functional requirement.

Environment variable expansion in MCP configuration is a related concept. Credentials should never be hardcoded in MCP config files; they should be injected via environment variables at runtime. The environment variable expansion in MCP config pattern is tested in scenarios involving credential management and team configuration.

{
  "mcpServers": {
    "billing-api": {
      "command": "npx",
      "args": ["-y", "@company/billing-mcp-server"],
      "env": {
        "BILLING_API_KEY": "${BILLING_API_KEY}",
        "BILLING_API_URL": "${BILLING_API_URL}"
      }
    }
  }
}

Hardcoding "BILLING_API_KEY": "sk-live-abc123" in a config file that is committed to version control is the kind of mistake the exam expects you to identify and fix.

What does a high-quality Domain 2 exam answer look like versus a weak one?

The CCAR-F exam is scenario-based throughout. Every item presents a situation and asks you to diagnose, design, or choose. Here is the pattern that separates high-scoring answers from low-scoring ones in Domain 2.

Scenario: An agentic customer service system has a tool called handle_customer_request that is being called for billing queries, refund requests, and account updates. The system is producing incorrect results for refund requests. What is the most appropriate fix?

The exam rewards root-cause tracing and proportionate fixes. A scenario about tool misrouting should be fixed at the tool description level, not the system prompt level, unless the scenario explicitly states that tool definitions cannot be changed.

How should you approach MCP server build-vs-use decisions in exam scenarios?

The exam tests whether you know when to build a custom MCP server versus when to use an existing one. The build vs use decision for MCP servers framework comes down to three questions:

1. Does a community or vendor MCP server already exist for this integration?
2. Does the existing server expose the specific operations and error semantics you need?
3. Does building a custom server provide a security, compliance, or performance benefit that justifies the maintenance cost?

If the answer to questions 1 and 2 is yes, the exam expects you to use the existing server. If the existing server exposes too many operations (creating a tool overload problem) or uses error semantics that do not match your error propagation strategy, building a thin wrapper or a custom server is justified.

MCP resources are a related concept that the exam tests separately from MCP tools. Resources expose read-only content catalogues (documentation, configuration files, reference data) that Claude can retrieve without making a tool call. The MCP resources for content catalogs pattern is appropriate when the data is static or changes infrequently and does not require transactional semantics.

How does error propagation work in multi-agent systems, and what does the exam test?

In a multi-agent system, a tool error in a subagent does not automatically surface to the coordinator. The coordinator only knows about the error if the subagent's response includes structured error information that the coordinator can parse. Error propagation in multi-agent systems is therefore an architectural concern, not just a tool-level concern.

The exam tests three propagation patterns:

1. Silent failure. The subagent catches the error, returns a partial result, and does not signal the coordinator. The coordinator proceeds as if the task succeeded. This is almost always the wrong answer.
2. Structured escalation. The subagent returns a structured error object that the coordinator can route: retry, escalate to a human, or invoke a fallback tool. This is almost always the right answer for transient or access errors.
3. Immediate termination. The subagent halts and returns nothing. The coordinator times out. This is the right answer only when continuing would cause irreversible harm.

The four error categories concept maps each category to the appropriate propagation pattern. Memorising this mapping is one of the highest-leverage preparation activities for Domain 2.

For broader context on how Domain 2 connects to the rest of the exam, our full Tool Design & MCP Integration concept library covers all 30 task statements across the five domains, and the Agentic Architecture & Orchestration library shows how tool design decisions ripple into orchestration patterns.

How complete does your Domain 2 preparation need to be?

Domain 2 is 18% of the exam. To pass at 720 on a 100-to-1000 scale, you need consistent performance across all five domains. Overinvesting in Domain 2 at the expense of Domain 1 (27%) is a common preparation mistake.

A practical benchmark: if you can correctly diagnose tool misrouting scenarios, select the right tool_choice configuration, distinguish access failures from valid empty results, and choose the correct MCP scoping level for a given scenario, you are prepared for the majority of Domain 2 items. The writing effective tool descriptions and diagnosing tool misrouting concepts are the highest-frequency topics in our practice exam data.

AI Skill Certs is an independent prep platform; we are not affiliated with or endorsed by Anthropic. Our practice exams mirror the real CCAR-F format: 60 scenario-based items, scored 100 to 1000, with 720 as the passing bar. The adaptive engine tracks your mastery at the concept level and surfaces Domain 2 items until you reach the 0.90 mastery threshold, so you spend revision time where it matters most.