Tools and MCPs

What this domain tests

10.6% — roughly 6 of the 53 scored items. The exam guide splits it into three named skills: Tool Implementation (4.4%), MCP Server Development (2.1%), and Agentic Customization (4.1%).

Read those weights carefully, because they are counterintuitive. Agentic Customization — the tradeoffs among built-in tools, custom tools, Skills, and MCPs — is nearly as heavy as tool implementation itself, and twice the weight of MCP server development. Candidates who study "how do I write an MCP server" and skip "when is an MCP the right answer at all" are optimizing the smallest slice. The published sample item for this domain is a selection question: given a requirement (an internal service, reusable across several applications, maintained independently of any one app), pick the right mechanism. That is the shape to prepare for.

The distractors in these items are category errors, not near-misses: the wrong options don't propose a slightly worse tool design, they propose a mechanism that structurally cannot do the job — pasting live data into context and calling it integration, hard-coding an API into a prompt, or assuming a built-in tool can reach an arbitrary internal endpoint. Learning what each mechanism fundamentally cannot do is worth more here than memorizing configuration syntax.

The other half is recall, and it is precise: which parameter controls tool selection, where results go, what a stop reason means, which side executes which tool. The agent loop itself — decomposition, coordination, delegation — belongs to Domain 1 (Agents and Workflows); this domain owns the tools that loop calls.

Theory outline

1. Tool Implementation (4.4%)

The official skill statement: tool use and function calling, configuration for external system interaction, tool description writing, error handling, tool usage patterns (agentic harness dispatch, client-side versus server-side tools, approval patterns), and tool set construction best practices.

Anatomy of a tool definition. Three fields:

Details the exam rewards:

• Describe each property, not just the tool. A parameter with no description is a guess waiting to happen.
• Use enum for fixed value sets. A unit parameter that accepts celsius or fahrenheit should say so in the schema, not in prose.
• Mark only truly required parameters required. Over-requiring forces the model to invent values it doesn't have.
• Descriptions should be prescriptive about triggering. "Call this when the user asks about current prices or recent events" measurably outperforms a description that only states what the tool does — recent Claude models reach for tools conservatively, and the trigger condition in the description is the lever that moves should-call rate. When a scenario says a tool is under-used, "write a better description that states when to call it" is a live correct answer, not a cop-out.
• Strict tool use (a flag on the tool definition) guarantees the tool input validates exactly against your schema. It requires additionalProperties set to false plus a required list, and it lives on the tool definition — not on the tool-choice parameter.

Controlling selection: tool_choice.

Any of these can additionally carry a flag disabling parallel tool use, forcing at most one tool call per response.

Parallel tool use and result handling. Parallel tool use is on by default: a single assistant message can contain multiple tool_use blocks. The handling rule is the highest-value recall item in this section:

Execute them, then return all tool_result blocks in a single user message.

Splitting the results across multiple messages doesn't just look untidy — it teaches the model to stop making parallel calls, and the symptom (an agent that mysteriously serialized itself) shows up far from the cause. Two more rules ride alongside: every tool_result must carry the tool_use_id of the call it answers, and a tool that failed returns a tool_result with an error flag set and an informative message. Do not drop a failed call's result — a missing result is a broken conversation, whereas an error result lets the model adapt or ask for clarification.

Error handling. Return errors as tool results, not as exceptions swallowed by the harness. An informative message ("no customer found with that ID") lets the model correct course; a generic failure or a silent drop does not. Distinguish this from the integration layer: a network failure calling your service is your harness's problem to retry; a semantic failure (bad ID, empty result, permission denied) is information the model needs.

Agentic harness dispatch, and the bash-versus-dedicated-tool decision. Claude emits tool calls; your harness executes them. The shape of those calls determines what the harness can do about them, and this is the design insight the exam tests:

A bash tool gives Claude enormous breadth — it can do almost anything — but hands the harness an opaque command string, identical in shape for every action. A dedicated tool gives the harness an action-specific hook with typed arguments it can intercept, gate, render, audit, or schedule.

Promote an action from bash to a dedicated tool when you need any of:

Rule of thumb: start with bash for breadth; promote to dedicated tools when you need to gate, render, audit, or parallelize. Reversibility is the useful criterion for which actions get promoted first.

Approval patterns. Tools with side effects — sending, deleting, paying, deploying — should be gated behind human confirmation. The mechanics matter less than the principle, but know that gating can live in two places: inside the tool's own execution function (prompt for approval, and return a "user declined" tool result instead of executing), or in the harness before dispatch (inspect the pending tool call and allow or deny it before the function runs). Managed agent surfaces express the same idea declaratively as a per-tool permission policy — allow automatically, or always ask, in which case the session pauses until a confirmation event arrives.

The exam angle: "the agent must never do X without approval" is not a prompting problem. Approval belongs in the execution path, where it is deterministic.

Client-side versus server-side tools. Three categories, and confusing them is a reliable distractor:

Two consequences worth memorizing:

• Server-side tools need no execution loop on your side. You declare them and their results arrive as content blocks in the same response.
• Client-implemented tools are schema-less to declare: you give a type and a name and nothing else, because the input schema is built into the model. Passing your own input schema, or defining a custom tool that happens to be named bash, produces something different — a user-defined tool without the built-in behavior.

pause_turn. When server-side tools are in play, the API runs its own server-side sampling loop. If that loop hits its iteration limit, the response comes back with a pause_turn stop reason. The correct handling is to append the assistant turn and re-send — the server resumes where it left off. Do not add an extra user message saying "Continue"; the API detects the trailing server-tool state on its own. Bound the resumptions with a continuation cap so a pathological case can't loop forever.

Tool set construction. Two rules:

1. Keep the set focused. Too many tools confuses selection. If your application has dozens, that is a design signal.
2. For genuinely large libraries, use tool search with deferred loading. Tools marked for deferred loading are known to the request but not loaded into context until the model searches and surfaces them. The property that matters: discovered schemas are appended rather than swapped in, so the cached prefix survives — which is exactly why the alternative (rebuilding the tool list per request) is so costly, since tools render at position zero and any change there invalidates the entire cache. Constraint to remember: the search tool itself cannot be deferred, and at least one tool must be non-deferred, or the request is rejected.

Programmatic tool calling is the advanced pattern for chains: instead of one round trip per tool call, Claude writes a script that runs in the code-execution container and invokes tools as functions. Results return to the running code, not to Claude's context; only the script's final output comes back. Use it when there are many sequential calls or large intermediate results you want filtered before they hit the window. It carries real incompatibilities — it does not combine with strict tool use, with parallel tool use disabled, with a forced tool choice, or with MCP tools.

2. MCP Server Development (2.1%)

The official skill statement: MCP server development practices including server authoring, deployment, integration with Claude applications, MCP resources, tools, and prompts, and communication patterns (stdio, sockets, client versus server).

What MCP is for. The Model Context Protocol is a standard interface between a model application (the client) and a capability provider (the server). The point is not that it is the only way to call an API — it is that the capability becomes reusable across applications and maintainable independently of any one of them. Build an MCP server when the same capability must serve several Claude applications, or when the team that owns the underlying system should own the integration. Write a plain custom tool when the capability belongs to exactly one application.

The three primitives an MCP server exposes. This is the recall item for this skill:

An option that describes an MCP server as "tools only" is incomplete, and the resource-versus-tool distinction (read context versus perform operation) is the natural question to build on it.

Client versus server. The client is the Claude application (or the platform acting on its behalf); the server is the process exposing capabilities. Servers hold the credentials and the connection to the underlying system. The client discovers what a server offers and routes calls to it. Keeping that direction straight resolves most confusion in this section: your application does not "install tools into" the server; it connects to a server and adopts what the server publishes.

Communication patterns. The exam guide names stdio, sockets, client versus server. Two deployment shapes follow from that vocabulary:

• Local, over standard input/output. The client launches the server as a subprocess and speaks the protocol over its stdin and stdout. This is the shape for servers that need local resources — the filesystem, a local database, a CLI on the same machine. There is no network listener and no URL.
• Remote, over a network endpoint. The server runs as a network-attached service that the client reaches at a URL. This is the shape for shared, multi-application servers and for hosted third-party servers, and it is the form the API-level connector accepts.

The decision rule is about locality and sharing, not preference: a server that must touch the local machine runs as a local subprocess; a server that many clients share runs as a network service.

Integration with Claude applications. At the API level, connecting to a remote MCP server takes two halves that must agree:

1. A server declaration — its type, a name, and its URL.
2. A toolset entry in the tools array that references that server by the same name.

Declaring the server without the matching toolset entry is a validation error, not a silent no-op. That pairing is a clean recall item, and the name mismatch between the two halves is its natural distractor.

Credentials are supplied separately from the declaration. The server declaration carries connection information, not secrets. Auth is attached at the point of use — in managed surfaces, by attaching a credential store to the session, with the credential matched to the server by URL and refreshed automatically. Two facts that generate real-world bugs and good exam stems: a hosted MCP server's auth is typically an OAuth bearer token, not the underlying service's native API key (those are different auth systems, and the native key will simply not work), and an invalid credential does not block session creation — it surfaces as an error when the tool is first used. See Domain 7 for why keeping credentials out of the agent's reachable surface matters.

3. Agentic Customization (4.1%)

The official skill statement is one line, and it is the second-heaviest skill in the domain: tradeoffs among built-in Tools, custom Tools, Skills, and MCPs for selecting and applying the appropriate approach for a given use case.

This is a selection skill. Internalize the table:

The two axes that decide most questions:

1. Knowledge or reach? A Skill supplies knowledge — how to do something, what conventions to follow, what the output should look like. A tool or MCP supplies reach — the ability to touch a system outside the model. A scenario about the model not knowing your report format is a Skill; a scenario about the model not being able to read your database is not, no matter how well documented the database is.
2. One consumer or many? One application, one operation, owned by that app's team: custom tool. Several applications, or an integration that should outlive any one app: MCP server.

How Skills load — progressive disclosure. A skill's description sits in context by default; the model reads the full file only when the task calls for it. That is the mechanism behind the usual claim that skills scale better than stuffing everything into a system prompt: the fixed cost is one line per skill, and detail loads on demand. Anthropic publishes prebuilt skills for common document work (presentations, spreadsheets, documents, PDFs); custom skills are authored and versioned by you. On the Messages API, skills are enabled alongside the code-execution tool — they execute in the container rather than being pure prompt text.

The trap taxonomy this skill is built from. Distractors for selection questions come from a small, learnable set:

• "Hard-code it into the system prompt." Neither reusable nor maintainable, and it cannot execute anything. Wrong for any question about an operation against a live system.
• "Paste the current data into the context window each request." Gives you a snapshot, not access — stale immediately, and it burns context proportional to the data size. Wrong for anything described as live, queried, or changing.
• "Use a built-in tool, since built-ins can reach any internal endpoint." They cannot. Built-in tools are generic capabilities, not a universal client for your private infrastructure.
• "Write a Skill for it." Correct when the gap is knowledge; wrong whenever the gap is access. A skill teaches the model how to do something it can already reach.
• "Build an MCP server" for a single application's single operation — technically functional, disproportionate to the need. The tell that MCP is genuinely right is reuse across applications plus independent maintenance, and the sample item states both explicitly.

Worked problems

Problem 1. A coordinator issues three read-only tool calls in one assistant message. The developer executes them concurrently and appends each result as its own separate user message before sending the next request. Over the following turns, the agent stops issuing parallel calls and reverts to one tool per turn. What happened?

A. Parallel tool use has to be re-enabled on each request B. All tool_result blocks for one assistant message must be returned in a single user message; splitting them across messages trains the model to stop making parallel calls C. Read-only tools cannot be parallelized D. The tool_use_id values were consumed by the first result message

Approach: Parallel tool use is on by default, so nothing needed enabling. The documented handling rule is that results for a batch of parallel calls go back in one user message. Splitting them changes what the conversation demonstrates, and the model adapts — which is why the symptom (serialization) shows up turns later and far from the cause.

Why the others fail: A invents a per-request toggle; the real parameter goes the other direction, disabling parallelism. C is false — read-only tools are the best parallel candidates. D misattributes the failure to identifier handling; the ids were correct, the message packaging was not.

Answer: B

Problem 2. A team exposes an internal pricing service, reachable only inside their network, to Claude. Three separate applications need it, and the pricing team wants to own the integration and ship changes without touching any of those applications. Which approach fits?

A. A custom tool implementing the pricing calls, added separately to each of the three applications B. A Skill documenting the pricing service's endpoints and query conventions C. An MCP server exposing the pricing operations, with all three applications connecting to it D. A nightly export of the price table loaded into each application's context

Approach: Two markers point to MCP and only MCP: reuse across several applications, and maintenance independent of any one of them. Run the second axis — one consumer or many? — and the answer falls out. An MCP server centralizes both the capability and its ownership, so the pricing team ships changes to the server and every client picks them up.

Why the others fail: A is the real near-miss. It works, and it is the right answer if only one application needed the service — but three copies means three places to fix a bug, and ownership sits with the application teams rather than the pricing team, which is exactly what the stem rules out. B mistakes the axis: documentation supplies knowledge, and the gap here is reach — no amount of endpoint documentation lets the model call a service it has no connection to. D is a snapshot, stale the moment a price changes, and it spends context proportional to the table rather than to the question.

Answer: C

Problem 3. An agent produces quarterly reports. It can already query every data source it needs, but the reports keep coming back in the wrong structure — the team's house format has a required section order, specific table conventions, and a fixed summary style. Which mechanism addresses this?

A. An MCP server for the reporting system B. A custom tool called format_report C. A Skill containing the house reporting conventions, loaded when a report task comes up D. Additional built-in tools

Approach: Run the two axes. Reach is not the problem — the stem says the agent can already query everything. The gap is knowledge: what the format is and how to follow it. That is precisely what a Skill supplies, and progressive disclosure means the conventions load only when a report task arises rather than sitting in every system prompt.

Why the others fail: A and D add reach the agent already has. B is a real option only if formatting requires executing something the model can't do itself; as stated, the failure is that the model doesn't know the conventions, and wrapping a knowledge gap in a function signature doesn't teach it.

Answer: C

Problem 4. A developer declares a remote MCP server in the request — its type, name, and URL — and sends the request. The API rejects it as invalid. The URL is correct and reachable. What is missing?

A. A matching toolset entry in the tools array referencing the server by name B. The credentials, which belong in the server declaration C. A local stdio transport configuration D. Nothing — remote MCP servers cannot be used from the Messages API

Approach: API-level MCP integration is two halves that must agree: the server declaration, and a toolset entry in the tools array naming the same server. Declaring the server alone is a validation error, not a silent no-op — which is exactly what the stem describes.

Why the others fail: B misplaces auth: the declaration carries connection information, and credentials are attached separately at the point of use. C confuses deployment shapes — a URL-addressed server is the network form; stdio is for a locally-launched subprocess, and mixing them isn't a fix. D contradicts the connector's existence.

Answer: A

Problem 5. An agent runs shell commands through a bash tool. The team needs every outbound customer email to require human approval, and they want the approval dialog to show the recipient and subject. Right now emails are sent with a command-line mail client through bash. What should change?

A. Add a system-prompt rule requiring the agent to ask before sending email B. Promote sending email to a dedicated tool with typed arguments, and gate that tool behind human confirmation in the execution path C. Disable parallel tool use so emails are sent one at a time D. Post-process the bash tool's output and alert on anything that looks like an email

Approach: This is the bash-versus-dedicated-tool decision with an approval requirement stacked on it. Bash hands the harness an opaque string — it cannot reliably tell a send from any other command, and it has no structured recipient or subject to render in a dialog. A dedicated tool gives typed arguments the harness can inspect, gate, and display. And "must require approval" is an execution-path requirement, not a prompting one.

Why the others fail: A is probabilistic where the requirement is absolute. C changes concurrency, not authorization — one unapproved email at a time is still unapproved. D fires after the send; detecting a violation is not preventing one, and pattern-matching command strings is fragile besides.

Answer: B

Problem 6. An application declares web search alongside custom tools. On a research-heavy request the response comes back with a pause_turn stop reason and a partial answer. What is the correct handling?

A. Treat it as an error and restart the request from scratch B. Append the assistant turn to the conversation and re-send, letting the server resume; bound the resumptions with a continuation cap C. Append the assistant turn plus a user message saying "Continue" D. Increase the token ceiling and retry

Approach: pause_turn means the API's server-side sampling loop for server tools hit its iteration limit. Re-sending with the assistant turn appended resumes the work — the server detects the trailing server-tool state on its own. Adding an explicit "Continue" message is specifically called out as unnecessary. A continuation cap is the standard guard against a pathological loop.

Why the others fail: A discards completed work and will hit the same limit again. C is the near-miss and the reason the item exists — the extra user message is superfluous and perturbs the conversation. D treats a loop-iteration limit as an output-length limit; the response wasn't truncated for tokens.

Answer: B

Exam traps

• Splitting parallel tool results. All tool_result blocks answering one assistant message go back in a single user message. Splitting them silently trains the model out of parallel calls.
• Dropping a failed tool's result. Return the result with the error flag set and a useful message. Omitting it leaves an unanswered tool_use and breaks the conversation; the model can recover from an error, not from silence.
• Mismatched or missing tool_use_id. Every result names the call it answers. An option that returns results positionally is wrong.
• Giving a client-implemented tool your own schema. Bash, text editor, and memory are Anthropic-defined and schema-less to declare — type and name only. A custom tool you happen to name bash is a different tool without the built-in behavior.
• Confusing who executes what. Server-side tools (web search, web fetch, code execution, tool search) run on Anthropic's infrastructure with no loop on your side. Client-implemented tools are Anthropic-defined but executed by your harness. An option claiming you must implement web search yourself, or that bash runs on Anthropic's servers, is inverted.
• "Continue" after pause_turn. Append the assistant turn and re-send; do not add a user message telling it to continue. And pause_turn is not an error and not a token-limit problem.
• The strict flag on tool_choice. It goes on the tool definition, and it needs additionalProperties set to false plus a required list.
• Missing the second half of MCP integration. A server declaration without a matching toolset entry naming the same server is a validation error. Watch for name mismatches between the two halves.
• Credentials in the MCP server declaration. The declaration carries connection information; auth is attached separately at the point of use. A hosted MCP server usually wants an OAuth bearer token, not the underlying service's native API key.
• "MCP servers expose tools." Incomplete — tools, resources, and prompts. Resources supply readable context; tools perform operations.
• Skill versus tool confusion. Skills supply knowledge and load on demand; tools and MCPs supply reach. A skill cannot fetch live data or perform an external operation, and no tool teaches the model your house conventions.
• Built-in tools reaching internal systems. They cannot. Any option resting on a built-in tool calling an arbitrary private endpoint is a category error.
• Pasting data instead of integrating. A snapshot in the context window is stale on arrival and scales badly. Wrong whenever the scenario says live, queried, or changing.
• MCP for a single application's single operation. Functional but disproportionate. The tells for a genuine MCP answer are reuse across applications plus independent maintenance — usually stated outright in the stem.
• Rebuilding the tool list per request. Tools render first in the prompt, so changing them invalidates the entire cache. For large libraries, tool search with deferred loading appends schemas instead of swapping them — and the search tool itself can never be the deferred one.