❯ Tool Design & MCP Integration

Roughly 18% of the exam.

Anatomy of a tool

A user-defined tool is three fields: name, description, and input_schema (JSON Schema). The description is the single highest-leverage design surface — Claude uses it to decide when to call the tool, so state the trigger condition, not just the function ("Call this when the user asks about current prices"), and describe every property. Use enum for fixed value sets, mark only truly required parameters as required, and give optional ones sensible defaults so the model never has to invent values.

tool_choice

• auto — Claude decides (default).
• any — must call at least one tool, Claude picks which.
• tool + name — must call that exact tool.
• none — tools are visible but cannot be called.
• Any of these accepts disable_parallel_tool_use: true to cap at one call per response.

Handling results

• Every tool_result goes in a user message and must carry the matching tool_use_id.
• Parallel calls → all results together in one user message.
• Failures → is_error: true plus an informative message; Claude will retry differently or ask for clarification.
• Always parse tool input as JSON (JSON.parse / json.loads) — never string-match the serialized form; escaping can vary.

Strict tool use & structured outputs

strict: true on a tool guarantees the model's parameters validate against your schema. It is the tool-side sibling of structured outputs (which constrain the response format) — the exam likes testing that you know which side each governs.

Server-side tools

Web search, web fetch, and code execution run on Anthropic's infrastructure: declare them in tools and the API handles execution — no client-side work, results appear as server tool result blocks. Contrast with client tools (yours) and with the memory tool, which is defined by Anthropic but executed by your harness.

Model Context Protocol

MCP standardizes how applications provide context and capabilities to models.

• Architecture — a host application (IDE, chat app) runs one MCP client per connection to an MCP server. Servers expose capabilities; clients consume them.
• Primitives — tools (model-invoked actions, side effects allowed), resources (application-controlled data/context, read-style), and prompts (user-invoked templates). Distinguishing tools from resources is a recurring exam item.
• Transports — stdio for local child-process servers; streamable HTTP for remote servers.
• Auth — remote servers use OAuth handled by the client/host layer. Never put credentials in prompts or tool parameters: conversation history persists, so a secret pasted there is durably stored.

Scaling the tool set

Too many overlapping tools degrades selection. First fix: consolidate to a focused set with distinct names and clear when-to-use descriptions. For genuinely large libraries, use tool search — relevant schemas load on demand and are appended rather than swapped, preserving the prompt cache.

→ Drill this domain in practice mode