Domain 8: Tools and MCPs
10.6% of examImplement tools and understand the function-calling loop
Key Points
- Tool-use loop: pass a tools array (name, description, input_schema) -> Claude emits a tool_use block (stop_reason "tool_use") -> your code executes it -> return a tool_result matched by tool_use_id -> Claude continues to end_turn.
- Claude never executes a tool itself -- it only requests the call; your application code runs it.
- Tool description quality (what it does, when to use it, what each parameter means) is the single biggest driver of correct tool selection.
- A precise input_schema (types, required fields, enums, per-field descriptions) produces well-formed arguments but doesn't replace a good description.
- Structured errors (an is_error flag or message) let Claude recover or retry instead of guessing; right-size the tool set to avoid overlap and context bloat.
Decision Rules
When: Claude's response has stop_reason "tool_use"
→Execute the tool yourself and return a tool_result block matched by tool_use_id.
When: Claude keeps picking the wrong tool
→Improve the tool's description first, not just the schema or the temperature.
When: Designing the tool catalog for an agent
→Keep it focused and non-overlapping rather than maximizing the number of tools offered.
When: A tool call fails
→Return a structured, informative error so Claude can recover or retry intelligently.
✗ Anti-Patterns to Reject
- "Claude executes the tool" -- it only requests the call; your code runs it.
- Forgetting to feed the tool_result back with the matching tool_use_id.
- Assuming more tools or a bigger catalog is strictly better.
Understand MCP servers, their primitives, and transports
Key Points
- MCP (Model Context Protocol) is an open standard ("a USB-C port for AI") for connecting AI applications to external systems; build once, reuse across any MCP-compatible client.
- Three core primitives: tools (model-callable actions), resources (readable data/content loaded into context), and prompts (reusable parameterized templates) -- not just tools.
- The client lives inside the AI application and connects to one or more servers; each server advertises and handles its own tools/resources/prompts.
- Transports: stdio (local subprocess, single-user) vs. Streamable HTTP/sockets (remote, multi-client).
- Canonical use case: a capability that must be reusable across multiple Claude applications and maintained independently.
Decision Rules
When: A capability (e.g., an internal REST service) must be reusable across multiple Claude apps and maintained independently
→Build an MCP server, not app-local integration logic.
When: Asked what MCP exposes
→Answer tools, resources, AND prompts -- not just tools.
When: The deployment is a local, single-user integration
→Use stdio; for a remote/shared service serving multiple clients, use Streamable HTTP/sockets.
✗ Anti-Patterns to Reject
- "MCP only exposes tools."
- Hard-coding integration logic into each app's prompt instead of building a shared MCP server.
- Picking HTTP/sockets for a local, single-user subprocess scenario, or vice versa.
Choose the right agentic customization mechanism
Key Points
- Four mechanisms: built-in tools (Anthropic-provided, least effort), custom tools (app-specific logic living with one app), Skills (packaged instructions/procedures via SKILL.md, no running service), MCP servers (reusable across apps, independently maintained).
- Selection heuristic: does a built-in already do it? Use it. App-specific? Custom tool. Reusable know-how, no service needed? Skill. Shared across apps, independently maintained? MCP server.
- Built-in tools have fixed capabilities and cannot automatically reach an arbitrary internal API.
Decision Rules
When: The capability already exists as a built-in (web search, code execution, computer use)
→Use it rather than rebuilding it.
When: A capability is app-specific and lives with one application
→Build a custom tool.
When: The need is reusable knowledge/procedure with no running service required
→Package it as a Skill, not an MCP server.
When: A capability must be reused across multiple apps and maintained independently
→Build an MCP server, not an app-local custom tool.
✗ Anti-Patterns to Reject
- "A built-in tool can reach any internal REST API."
- Confusing a Skill (packaged instructions) with a deployed service.
- Standing up an MCP server for reusable knowledge that needs no running service -- that's over-engineering; it's the Skill sweet spot.