Tool Design & MCP Integration accounts for 18% of the CCA-F exam. Questions in this domain test your ability to write tool definitions that Claude can use reliably, configure MCP servers correctly, and design error contracts that let the model recover gracefully when a tool call fails. Poor tool design is one of the most common causes of real-world agentic system failure, and the exam reflects that.
A tool definition has three parts: a name, a description, and an input schema. The description is the most important part. Claude reads the description to decide whether a given tool is the right one for the current step. If the description is ambiguous, Claude will sometimes pick the wrong tool. If it is too vague, Claude will call the tool with inputs the tool cannot handle. The exam will present tool definitions and ask you to identify which one will cause disambiguation failures or incorrect invocations.
Disambiguation is the problem Claude faces when multiple tools could plausibly handle a given request. Good tool design solves disambiguation in the description, not by adding complex routing logic to your application code. The description should state precisely what the tool does, what inputs it expects (with examples for edge cases), and crucially what it does NOT do. The last part — the negative boundary — is what most developers omit and what the exam tests.
MCP (Model Context Protocol) is the standard protocol for exposing tools to Claude in a structured, server-managed way. An MCP server declares its tools in a manifest, handles the JSON-RPC calls Claude makes when it invokes a tool, and returns structured responses. The exam tests MCP configuration at the level of: which fields in the manifest are required, how tool schemas map to Claude's tool use API, what happens when the MCP server is unavailable, and how to configure multiple MCP servers without name collisions.
Error contracts define what your tool returns when it cannot fulfil a request. A well-designed error contract returns a structured error object with a machine-readable code and a human-readable message. The model can then decide whether to retry, to fall back to a different tool, or to surface the error to the user. An unstructured error (a raw exception stack trace, or a 500 response with no body) leaves the model with no information to act on, which typically causes it to hallucinate a recovery action.
Scenario: A company has two tools: get_customer_orders (described as 'retrieves customer orders') and get_archived_orders (described as 'retrieves archived customer orders'). A user asks for orders from 18 months ago. Claude calls get_customer_orders, receives an empty result, then reports that the customer has no orders. The actual orders exist in the archive.
The problem is that get_customer_orders has no description of its temporal scope. Claude had no way to know that this tool only covers recent orders. The correct fix is to update the get_customer_orders description to say 'retrieves orders placed within the last 90 days' and update get_archived_orders to say 'retrieves orders older than 90 days.' With both tools scoped explicitly, Claude will correctly route an 18-month-old query to the archive tool. The distractor — adding application-level routing that checks the date before dispatching the tool call — is a worse answer because it moves the routing logic out of the tool definition and into application code, making future maintenance harder and removing the model's ability to reason about the choice.