Tools and MCPs

10.6% of the Claude Certified Developer – Foundations blueprint — roughly 6 of the 53 questions on a real sitting.

Tools and MCPs is 10.6% of the CCDV-F blueprint — roughly 6 of the 53 scored questions. It splits into Tool Implementation (4.4%), Agentic Customization (4.1%) and MCP Server Development (2.1%), which tells you something useful straight away: two-thirds of the domain is about tools you write and capability surfaces you shape, and only a fifth is about the Model Context Protocol as such.

The implementation half is decision-focused rather than syntax-focused. You will not be asked to write a JSON Schema from memory. You will be handed a working tool and asked what makes it work better: a description that gives Claude a reason to pick this tool over its neighbour, a schema tight enough that malformed calls become impossible rather than merely unlikely, an error shape the model can act on, a result payload that does not flood the context window.

The MCP portion rewards the protocol's shape and trust boundary rather than its wire details. Know that MCP is an open, JSON-RPC-based protocol — not an Anthropic API feature — letting any compliant host connect to any compliant server. Know the three server primitives and who controls each, the transports, and what the specification demands of a server listening on HTTP. And know that MCP revisions move quickly, so anchor on what has survived every revision rather than on a handshake you memorised.

What the exam actually tests

  • —Tool descriptions as selection signal — what the tool returns and when to prefer it over a sibling
  • —Schema discipline: enums for closed sets, `required`, and `strict: true` with `additionalProperties: false`
  • —The tool-use loop: `stop_reason: "tool_use"` → execute → `tool_result` carrying the matching `tool_use_id`
  • —Returning failures as structured, actionable results rather than exceptions or nulls
  • —MCP primitives and the control split — tools are model-controlled, resources application-controlled, prompts user-controlled
  • —MCP server security: Origin validation, localhost binding, OAuth 2.1 audience binding, and the token-passthrough prohibition

A tool definition is selection signal, not documentation

Claude chooses between tools by reading their definitions, so the description is the highest-leverage field you control. A strong one states what the tool does, what it returns, and when to prefer it — 'Returns order status, line items and shipping events for a single order ID. Call this when the user references a specific order number' beats 'Queries the orders service' on every axis. Be prescriptive about the trigger condition, not just the behaviour; on current models a description that says when to call a tool measurably improves the should-call rate. The schema does the rest of the work: closed value sets belong in `enum`, genuinely required fields in `required`, and `strict: true` with `additionalProperties: false` turns 'usually well-formed' into a guarantee.

The tool-use loop and parallel calls

When Claude wants a tool it returns `stop_reason: "tool_use"` with one or more `tool_use` blocks. Your loop appends the assistant's full content to the message list, executes the tools, and sends back a user message of `tool_result` blocks, each carrying the matching `tool_use_id`. Two details are heavily tested. First, a single assistant turn may contain several `tool_use` blocks — execute them concurrently, then return **all** results in one user message; splitting them across messages teaches the model to stop making parallel calls. Second, a tool that fails still gets a `tool_result`, with `is_error: true` and a message the model can act on. Dropping the block entirely leaves an unanswered call and breaks the conversation.

What MCP is and what it standardises

The Model Context Protocol is an open, JSON-RPC 2.0 protocol for connecting a host application to context and capability servers. Its value is the many-to-many property: any compliant host can talk to any compliant server, so an integration written once is reusable across clients. Servers expose three primitives, and the specification is explicit about who drives each: tools are **model-controlled** (the model discovers and invokes them), resources are **application-controlled** (the host decides what context to attach), and prompts are **user-controlled** (templates a user explicitly selects, surfaced as slash commands or menu items). The everyday method names — `tools/list`, `tools/call`, `resources/list`, `resources/read`, `resources/templates/list`, `prompts/list`, `prompts/get` — have been stable across revisions and are the ones worth knowing cold.

MCP transports and the server trust boundary

Two transports are current: **stdio**, where the host launches the server as a subprocess and exchanges newline-delimited JSON-RPC over stdin and stdout, and **Streamable HTTP** for servers reached over the network. The older HTTP+SSE transport has been deprecated since the 2025-03-26 revision and should not be adopted by new implementations. An HTTP server carries obligations the specification states normatively: it **MUST** validate the `Origin` header to prevent DNS rebinding, **SHOULD** bind to localhost rather than all interfaces when running locally, and **SHOULD** authenticate connections. Where authorization is implemented it is OAuth 2.1 — the server acts as a resource server, advertises protected-resource metadata (RFC 9728), and clients send RFC 8707 resource indicators so tokens are audience-bound.

Shaping the capability surface

Agentic customization is largely the discipline of not exposing everything. Every tool definition sits in the context window on every request, so a sprawling catalogue costs tokens continuously and makes selection harder. Three levers matter. Deferred loading with a tool-search tool lets a large library stay out of context until something relevant is needed — and because schemas are appended rather than swapped, the prompt cache survives. Skills package task-specific instructions and files that load only when relevant, so the fixed context stays small. And the bash-versus-dedicated-tool choice is a real design decision: a bash tool gives breadth but hands your harness an opaque command string, while promoting an action to its own tool gives you typed arguments you can gate, audit, render or parallelise.

Where candidates go wrong

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

Distractors suggest that a well-named tool needs only a one-line description, or that descriptions matter solely for ambiguous tools. Claude selects across the whole toolset from description text, so `get_order` described as 'Retrieves order information' will be picked inconsistently next to `search_orders` and `get_customer`. The correct option nearly always favours the description that names the return content and states an explicit trigger condition — Anthropic's own guidance calls detailed descriptions by far the most important factor in tool performance and suggests aiming for at least three or four sentences each. Under-description, not over-description, is the common failure here.

Trap 2 — 'On failure, throw an exception or return null'

Exceptions are fine inside your implementation and wrong at the boundary. The model cannot see a stack trace; it sees a missing or empty result and guesses. Return a `tool_result` with `is_error: true` and a message describing the failure category and whether retrying could help. In MCP the same distinction is spelled out explicitly: malformed requests and unknown tools are protocol errors returned as JSON-RPC errors, while execution failures — API errors, validation failures, business-rule rejections — belong in the result with `isError: true`, precisely so the model can self-correct.

Trap 3 — 'readOnlyHint tells me the tool is safe to auto-approve'

MCP tool annotations — `readOnlyHint`, `destructiveHint`, `idempotentHint`, `openWorldHint` — look like a permission model and are not one. The specification is blunt: every property in the annotations object is a **hint**, not a guarantee, and clients must treat annotations as untrusted unless they come from a trusted server. A malicious or careless server can label a destructive tool read-only. Any option that uses an annotation as the basis for skipping approval is the wrong answer; approval policy belongs to the host, and the specification expects a human in the loop with the ability to deny a tool invocation.

Trap 4 — 'The MCP details I learned last year are still current'

MCP revisions are dated and backwards-incompatible changes do happen. The connection handshake, protocol-level sessions, and several client-side features have all been reworked or removed across revisions, so answers built on a half-remembered lifecycle detail are risky. What has survived every revision is the conceptual core: JSON-RPC 2.0 messaging, the three primitives and their control split, tools returning content plus an error flag, stdio and Streamable HTTP as the transports, and the security posture around origin validation, audience-bound tokens and no token passthrough. Anchor there.

How to study this domain

Weight your prep the way the sub-skills do: Tool Implementation and Agentic Customization are 4.4% and 4.1%, MCP Server Development only 2.1%. Spend most of your time on tool design, not protocol trivia.

The fastest way to internalise tool design is to write one deliberately bad tool and fix it: a vague description, a free-string parameter that should be an enum, no `required` array, and an implementation that throws on failure. Repair it one change at a time and note what each buys — the description improves selection, the enum eliminates a class of malformed call, `strict: true` with `additionalProperties: false` makes the contract enforceable, and the structured error lets the model recover instead of guessing.

For MCP, build the smallest server that exposes one tool, one resource and one prompt, and run it against the reference inspector. You will learn the control split by feeling it — the model reaches for the tool, the host attaches the resource, the prompt appears only when you select it. Then memorise the security posture: validate `Origin`, bind to localhost, treat annotations as untrusted, never forward a token not issued for your server.

Common questions

How many CCDV-F questions come from Tools and MCPs?

It is 10.6% of the blueprint — roughly 6 of the 53 scored questions. The sub-skills are Tool Implementation (4.4%), Agentic Customization (4.1%) and MCP Server Development (2.1%).

Is MCP an Anthropic API feature?

No. MCP is an open protocol built on JSON-RPC 2.0, with its own specification, transports and SDKs, usable by any compliant host and server. Anthropic products connect to MCP servers, and the Claude API has a connector for reaching them, but the protocol itself is independent of any one vendor's API.

When should something be a tool rather than a resource?

Follow the control split. If the model should decide to invoke it — it performs an action, or fetches something on demand — it is a tool. If it is contextual data the host application decides to attach, it is a resource. If it is a reusable template a user explicitly selects, it is a prompt. 'Performs an action or has side effects' is the reliable tiebreaker for tool versus resource.

How should a tool report an error?

As a result, not an exception. On the Messages API return a `tool_result` with `is_error: true` and a message that names the failure and whether a retry could help. In MCP, execution failures go in the result with `isError: true` so the model can self-correct, while malformed requests and unknown tools are returned as JSON-RPC protocol errors.

Do I need to memorise MCP method names and the wire format?

Know the everyday method names — `tools/list`, `tools/call`, `resources/list`, `resources/read`, `prompts/list`, `prompts/get` — and that everything is JSON-RPC 2.0. Do not sink time into lifecycle minutiae: those have changed across revisions, and the exam is more interested in primitive choice, error handling and server security than in the exact shape of a handshake.

What is the single most-tested idea in this domain?

That the tool definition is what Claude reads to decide, so the description and schema are behaviour, not paperwork. Almost every implementation question reduces to making a tool easier for the model to choose correctly and harder for it to call incorrectly.

Practise this domain

The CCDV-F bank is weighted to the blueprint above, so 10.6% of what you practise is this domain — and every option carries a written explanation, not just the correct one.

See CCDV-F

Other CCDV-F domains

Not affiliated with or endorsed by Anthropic. Domain names and weightings are taken from the published exam guide; always check the official guide before booking.