How many questions on the CCA-F exam are from Tool Design & MCP?

Tool Design & MCP is 18% of the blueprint. On the 60-question Official Simulation that maps to roughly 11 questions, making it the second-largest domain after Agentic Architecture.

What's the single highest-impact thing to study in this domain?

Tool description quality. A large share of the questions test whether you can recognise a description that gives Claude a clear 'use when' signal plus return content, versus one that only restates the tool name. Rehearsing weak-to-strong rewrites is the fastest way to lift your score here.

Do I need to know MCP server implementation to pass?

No. The exam tests the conceptual model — what Tools, Resources, and Prompts are for, how to shape descriptions and schemas, and how to return errors — not server-side code. You should know that MCP standardises how hosts connect to external context and capabilities, but you will not be asked to write a server.

How should error responses be shaped?

As structured objects with at minimum an error code, a human-readable message, a retryable boolean, and an escalate boolean. Throwing exceptions, returning null, or returning a bare { success: false } are all wrong on the exam because they hide the information Claude needs to choose a recovery path.

When should something be a Resource instead of a Tool?

When it is readable context the host can pull in rather than an action the model needs to invoke. Reference documents, static records, and files the model should treat as input belong as Resources. If the capability performs an action or has side effects, it is a Tool.

Is idempotency actually tested?

Yes, usually inside a larger scenario about retries or parallel calls. The expected reasoning is that idempotent tools are safe to retry and safe to parallelise, while side-effecting tools need idempotency keys, confirmation patterns, or human-in-the-loop approval before they are called more than once.

Tool Design & MCP

18%

Tool Design & MCP is 18% of the CCA-F blueprint. It tests how you describe tools so Claude picks them correctly, how you shape inputs and errors, and when to expose something as a Tool vs. a Resource vs. a Prompt under the Model Context Protocol.

Tool Design & MCP is 18% of the blueprint — roughly 11 of the 60 official-simulation questions. After Agentic Architecture, it is the second-heaviest domain on the exam, and it is the one where candidates most often confuse 'I know what JSON schema is' with 'I know how to design a tool Claude will actually use correctly'. The exam is not asking you to write a schema from scratch. It is asking you which description, which schema, which error shape, and which MCP primitive will make an agent behave correctly in production.

The domain is decision-focused. Almost every question hands you a working tool and asks how to make it better: a vague description that needs to be tightened, an exception-throwing failure mode that needs to become a structured response, an under-specified schema that lets bad inputs through, or a piece of functionality that has been miscast as a Tool when it should have been exposed as a Resource. If you can articulate why one description, schema, or primitive choice changes Claude's behaviour — and what the failure mode of the other options is — you will pass this domain comfortably.

What the exam tests in this domain

·Writing tool descriptions that tell Claude what the tool returns and when to pick it
·JSON schema design: required vs. optional, nullable, strict types, enums for closed sets
·MCP primitives — Tools (actions), Resources (readable context), Prompts (reusable templates)
·Structured error responses with error code, message, retryable, and escalate fields
·Idempotency and side-effect labelling for safe retries and parallel calls
·What MCP is (Model Context Protocol) and what it standardises across servers

Key concepts

Writing tool descriptions Claude can actually select on

A tool description is not documentation for the developer who wrote the tool. It is selection signal for Claude, sitting alongside every other tool in the agent's toolset. A strong description tells Claude three things: what the tool does, what it returns, and when to pick it relative to other tools. 'Retrieves order details including status, items, and shipping information for a specific order ID. Use when the customer references a specific order number or asks about an existing purchase' beats 'Gets data from the orders table' on every axis. The first specifies return content, required input, and trigger condition. The second leaks an implementation detail and gives Claude no situational signal. On the exam, the correct option is almost always the description with an explicit 'use when' clause.

JSON schema for tool inputs

Schemas are the contract Claude reads before generating arguments. Required fields belong in 'required'. Optional fields should be explicitly typed and, where they can legitimately be absent, marked nullable rather than left unconstrained. Closed sets of values (status codes, regions, currencies) should be enums, not free-form strings — this is the single highest-leverage change you can make to reduce tool-call errors. Avoid 'string' as the type for things that are really numbers, dates, or IDs with a specific format. The exam likes to put a loose schema next to a strict one and ask which is better; the answer is the one that constrains the input enough that Claude cannot silently produce malformed calls.

MCP primitives: Tools, Resources, Prompts

The Model Context Protocol exposes three primitives, and the exam expects you to know which is which. Tools are actions the model can invoke — they do something or fetch something on demand. Resources are readable context the host can pull in: files, records, documents the model treats as input rather than as an action. Prompts are reusable templates the server offers — pre-baked instructions a host can surface to the user or inject into a session. The most common exam framing: 'should the server expose this as a Tool, a Resource, or a Prompt?' The rule of thumb is simple. If it performs an action or has side effects, it is a Tool. If it is static-ish content the model should read, it is a Resource. If it is a reusable instruction template, it is a Prompt.

Structured error responses

When a tool fails, the worst thing it can do is throw an exception or return null. Both leave Claude blind: it cannot tell what failed, whether to retry, or whether to escalate. The correct shape is a structured response with at minimum an error code (a stable string Claude can branch on), a human-readable message, a 'retryable' boolean, and an 'escalate' boolean. '{ error: "REFUND_WINDOW_EXPIRED", message: "Order is outside 30-day refund window", retryable: false, escalate: true }' tells the agent the failure category, that retrying will not help, and that a human is the right next step. Exam distractors in this area include 'throw an exception', 'return null', and '{ success: false }' with details only in server logs. All three are wrong for the same reason: they hide the information Claude needs to recover.

Idempotency and side-effects

An idempotent tool can be called twice with the same arguments and produce the same result without doing extra damage — reading an order, fetching a document, looking up a price. Non-idempotent tools have side effects: refunds, deletions, outbound messages, payments. The exam expects you to know that parallel and retry behaviour depend on this distinction. Idempotent tools are safe to retry on transient failures and safe to call in parallel batches. Side-effecting tools need explicit safeguards: idempotency keys, human-in-the-loop approval, or a 'confirm before execute' pattern. A common trap is treating every tool as freely retryable; the correct answer almost always distinguishes between the two classes.

Common traps and distractor patterns

Trap 1 — 'A clear name makes the description optional'

An answer that says the tool name carries enough meaning on its own, or that descriptions only matter for ambiguous tools, is wrong. Claude selects across the whole toolset using the description text. A 'lookup_order' tool with the description 'Retrieves order information' will be picked inconsistently because nothing in the description tells Claude when to prefer it over 'search_orders' or 'get_customer'. The correct answer always favours descriptions that include return content and a 'use when' trigger.

Trap 2 — 'Throwing an exception is a valid error response'

Exceptions are a valid implementation detail inside the server, but they must be caught and translated into a structured error before they reach the agent. An option that says 'throw an exception with the message Failed' or 'let the exception propagate to Claude' is wrong. So is 'return null and let the agent infer the failure'. The correct response shape is a structured object with error code, message, retryable, and escalate fields.

Trap 3 — 'Expose everything as a Tool'

If a distractor frames every server capability as a Tool — including static reference documents or reusable instruction templates — it is wrong. MCP has Resources for readable context the host can pull in, and Prompts for reusable templates. Exposing a 200-page policy PDF as a Tool that returns its contents is the wrong primitive; it is a Resource. Exposing a 'summarise this incident' instruction template as a Tool is also wrong; it is a Prompt.

Trap 4 — 'Loose schemas are fine because Claude will figure it out'

Answers that defend free-form 'string' types for closed sets, or that argue Claude will infer constraints from the description, are wrong. Schema is the only constraint that is enforced before Claude generates arguments. Enums for closed sets, explicit number/date types, and required-vs-optional discipline are what stop malformed tool calls. The correct answer is almost always the stricter schema.

Sample questions with explanations

Question 1
When writing a description for an MCP tool called 'lookup_order', which description is most effective at helping Claude select it correctly?
- A.Gets data from the orders table in the database.
- B.Retrieves order details including status, items, and shipping information for a specific order ID. Use when the customer references a specific order number or asks about an existing purchase.✓ Correct
- C.Use this tool to look up orders. Takes an order_id parameter.
- D.Retrieves order information.
Why B is correct: An effective tool description tells Claude exactly what the tool does, what it returns, and when to use it relative to other tools. The strong version specifies the return content (order details including status, items, and shipping information), the required input (a specific order ID), and the trigger condition (the customer references a specific order number or asks about an existing purchase). That combination lets Claude reliably distinguish this lookup from any similar tool in the toolset. Saying only 'use this tool to look up orders, takes an order_id parameter' restates the function name without telling Claude when to choose it or what it returns. A bare 'retrieves order information' is similarly vague and gives no selection signal. Describing the tool as 'gets data from the orders table in the database' leaks an implementation detail (table-level access) without explaining the user-facing situation in which Claude should pick this tool, and may even encourage misuse for non-order data that lives in the same store.
Question 2
Your MCP tool 'process_refund' fails because the order is outside the 30-day refund window. Which error response structure best enables the agent to handle this gracefully?
- A.Throw an exception with the message 'Refund failed'
- B.Return null and let the agent infer the failure from the absence of a result
- C.Return { error: 'REFUND_WINDOW_EXPIRED', message: 'Order is outside 30-day refund window', retryable: false, escalate: true }✓ Correct
- D.Return { success: false } and log the details server-side
Why C is correct: A structured error response with an explicit error category, a human-readable message, and retryable/escalation flags gives Claude the information needed to choose an appropriate next step. Returning fields like `error: 'REFUND_WINDOW_EXPIRED'`, a clear message, `retryable: false`, and `escalate: true` tells the agent exactly what failed, that retrying will not help (the 30-day window will not change with another call), and that human escalation is the right path. Returning `null` and forcing the agent to infer failure from the absence of a result is ambiguous: null could mean failure, empty results, or a tool bug, and the agent has nothing to reason over. Throwing a generic exception with 'Refund failed' tells Claude something went wrong but provides no category, no retryability signal, and no guidance on recovery. Returning just `{success: false}` with the details logged only server-side leaves the agent blind to the actual cause and to whether retry or escalation is appropriate.
Question 3
What does MCP stand for in the context of Claude integrations?
- A.Model Context Protocol✓ Correct
- B.Managed Compute Process
- C.Multi-Channel Protocol
- D.Message Control Plane
Why A is correct: MCP stands for Model Context Protocol. It is an open protocol designed to allow language models like Claude to connect with external data sources, tools, and services in a standardized way.

How to study this domain

Build a small mental library of 'before and after' pairs and rehearse them. Take a weak tool description and rewrite it with return content and a 'use when' clause. Take a loose schema and tighten it with required fields and enums. Take an exception-throwing failure and rewrite it as a structured error with retryable and escalate flags. Take a feature exposed as a Tool and decide whether it is really a Resource or a Prompt. If you can do those four rewrites on paper without thinking, you will recognise the correct option on the exam in seconds.

Also memorise the MCP primitives cold: Tools are actions, Resources are readable context, Prompts are reusable templates. At least one or two questions will test the bare distinction, and a few more will hide it inside a longer scenario. Do 20–30 practice questions specifically on tool description quality and error response shape — those two sub-topics produce the highest answer-rate lift on this domain.

Frequently asked questions

How many questions on the CCA-F exam are from Tool Design & MCP?: Tool Design & MCP is 18% of the blueprint. On the 60-question Official Simulation that maps to roughly 11 questions, making it the second-largest domain after Agentic Architecture.
What's the single highest-impact thing to study in this domain?: Tool description quality. A large share of the questions test whether you can recognise a description that gives Claude a clear 'use when' signal plus return content, versus one that only restates the tool name. Rehearsing weak-to-strong rewrites is the fastest way to lift your score here.
Do I need to know MCP server implementation to pass?: No. The exam tests the conceptual model — what Tools, Resources, and Prompts are for, how to shape descriptions and schemas, and how to return errors — not server-side code. You should know that MCP standardises how hosts connect to external context and capabilities, but you will not be asked to write a server.
How should error responses be shaped?: As structured objects with at minimum an error code, a human-readable message, a retryable boolean, and an escalate boolean. Throwing exceptions, returning null, or returning a bare { success: false } are all wrong on the exam because they hide the information Claude needs to choose a recovery path.
When should something be a Resource instead of a Tool?: When it is readable context the host can pull in rather than an action the model needs to invoke. Reference documents, static records, and files the model should treat as input belong as Resources. If the capability performs an action or has side effects, it is a Tool.
Is idempotency actually tested?: Yes, usually inside a larger scenario about retries or parallel calls. The expected reasoning is that idempotent tools are safe to retry and safe to parallelise, while side-effecting tools need idempotency keys, confirmation patterns, or human-in-the-loop approval before they are called more than once.

Practice Tool Design & MCP questions

$24.99 lifetime access. 1,000+ scenario-based questions across all 5 domains, adaptive difficulty, written explanations, 7-day refund.

Get Lifetime Access — $24.99

Or try 15 free questions first, or see 10 free sample questions.