4.1 Tool Design and MCP Integration

Tool Design Checklist

Tool Design & MCP Integration is an 18% domain on the CCA-F, and it tests whether you can specify a tool that Claude picks correctly and your code can trust. When a scenario adds a tool, evaluate it against these dimensions:

A well-named, narrowly scoped tool with a strict schema lets Claude pick correctly and lets your code reject bad arguments before any side effect runs. The description should be prescriptive about when to use the tool ("Call this when the user asks about current order status"), not merely what it does — recent Claude models reach for tools more conservatively, so the trigger condition in the description measurably improves the should-call rate.

How a Tool Call Actually Flows

Claude does not execute tools itself. When it decides a tool is needed, it emits a tool_use block containing the tool name and a JSON arguments object. Your application code runs the real function, then sends back a tool_result block (referenced by tool_use_id) in the next user turn. Only then does Claude continue. This loop is the heart of agentic systems: the model proposes, your trusted code disposes.

• Claude emits tool_use with {name, input}.
• Your code validates input against the schema and checks authorization.
• Your code executes and returns tool_result (success payload or structured error).
• Claude reads the result and either calls another tool or answers.

Because the model only proposes arguments, the trust boundary lives in your executor, never in the prompt. Two operational details the exam expects: parallel tool calls (multiple tool_use blocks in one response) should be executed and returned together in a single user message of tool_result blocks — splitting them across messages trains Claude to stop calling in parallel; and a failed tool should return a tool_result with is_error: true rather than be dropped.

MCP: The Three Primitives

The Model Context Protocol (MCP), introduced by Anthropic in November 2024, standardizes how applications expose capabilities to models. An MCP server publishes three primitives, and the exam tests the distinction precisely:

The most common MCP trap is confusing resources (read-only, URI-addressed context that never mutates state) with tools (actions that change state). If a scenario describes pulling a schema or a log file for context, that is a resource; if it describes doing something, that is a tool.

Transport Is a Trust-Boundary Decision

An MCP client lives inside the host application (Claude Desktop, an IDE, your agent) and connects to servers over a transport:

• stdio — a local subprocess. It runs with the user's machine privileges, so the boundary is the local machine. Use it for local file/process access.
• streamable HTTP — a remote service across a network boundary. It needs authentication and scoping, because anything reachable over the network is a larger attack surface.

The transport choice mirrors the trust boundary: local stdio servers inherit local privileges; remote HTTP servers must authenticate and be scoped. The exam frames this as a security decision, not a convenience one.

Least Privilege and the Confused-Deputy Risk

The CCA-F repeatedly returns to least privilege: a tool should hold only the permissions one task legitimately needs. A search tool reads; it must not also delete. Splitting read and write into separate, separately authorized tools means a misfired call can never escalate from a lookup into destruction. Treat the model as an untrusted planner: it may be steered by a prompt-injection string hidden inside a retrieved document, so the executor enforces who-can-do-what, not the prompt. This is the confused-deputy problem: the model holds broad credentials and an attacker tricks it into misusing them.

The defense is narrow tools, server-side authorization keyed to the real end-user, and never passing raw secrets into the context window where they could be echoed back. For MCP credentials specifically, store them outside the model's reach (a vault or environment substitution) so the sandbox sees only a placeholder, and the real secret is injected at egress.

Structured Errors Enable Recovery

A tool that fails should return a structured error Claude can reason about, for example {"error":"not_found","detail":"order 4192 does not exist"}, not an opaque stack trace. With a typed error, Claude can apologize, try a corrected argument, or call a different tool. With an unstructured 500, it tends to hallucinate a plausible-but-wrong answer. On the exam, prefer the option that returns a machine-readable error code plus a human-readable detail over the option that silently swallows the failure or crashes the whole turn.

Quick Decision Table

Memorizing this mapping lets you answer most Domain 2 scenario questions in seconds: read the clue, pick the move. When a scenario introduces any new tool or MCP integration, mentally answer four questions — what inputs does it need, what outputs does it return, what permissions must it hold, and what is the failure recovery path. If you cannot answer all four, the integration is under-specified.