Designing tool interfaces, building MCP servers, taking them to production, and choosing between built-in tools and custom integrations.
A tool's interface is a contract with the model, not with a human developer — naming, parameter clarity, and description quality directly determine whether Claude selects the right tool and fills it in correctly. Vague names (process) and overloaded parameters cause more real-world tool failures than any model capability gap.
Tools should fail with structured errors, not bare exceptions or empty strings. A good tool error tells the caller what went wrong, what was attempted, and whether retrying makes sense — the same distinction (transient vs. validation vs. permission) that shows up again in Domain 5's multi-agent failure handling.
When several tools could plausibly handle a request, tool choice depends on how distinctly each tool's description stakes out its territory. Overlapping descriptions across multiple tools push the selection burden onto the model at inference time, which is exactly the failure the schema should have prevented.
Full breakdown & examples → 2.1 Fundamentals
The Model Context Protocol standardizes how an external system exposes capability to Claude, in three shapes: tools (actions Claude can invoke), resources (data Claude can read), and prompts (reusable templates the server offers). An MCP server is the provider; the client — Claude Code, the API, or another host — is the consumer.
Transport is a real architectural choice, not an implementation detail: local/stdio transport suits a server running on the same machine as the client, while a hosted server needs a network transport with its own connection lifecycle, reconnection behavior, and auth story.
A well-designed MCP server mirrors the same interface principles as any tool — clear naming, scoped capability, predictable errors — but at the level of an entire integration rather than a single function.
Full breakdown & examples → 2.2 Building MCP Servers
Taking an MCP server from prototype to production adds concerns that don't show up in a demo: authentication and credential handling, versioning so client and server can evolve independently, monitoring for latency and failure rates, and scaling for concurrent sessions.
Claude ships with certain capabilities natively — web search, code execution, file creation are common examples — and the exam expects you to know when reaching for a built-in tool is the right call versus when the task genuinely needs a custom MCP integration to a system Claude has no native access to.
The general rule: use a built-in tool when the capability is generic and already provided; build or connect an MCP server when the task depends on private, proprietary, or organization-specific systems and data that no built-in tool can reach.
Full breakdown & examples → 2.3 MCP Production & Built-in Tools
update accepts a single freeform data string parameter. What's wrong with this design, in Domain 2 terms?