Tools and MCPs
10.6% of examExtend Claude beyond text by defining function-calling tools, building MCP servers that expose reusable tools/resources/prompts, and choosing correctly among built-in tools, custom tools, Skills, and MCP servers for a given requirement.
3
task statements
8
concepts
36
practice questions
Domain Mastery
Implement tools and understand the function-calling loop
Defining well-formed tools with name, description, and input_schema, and driving the tool_use / tool_result loop that lets Claude request actions your code executes.
Knowledge of
- The tool-use loop: you pass a tools array, Claude responds with stop_reason 'tool_use' and a tool_use block (name + input), your code executes the tool, and you return a tool_result block matched by tool_use_id
- That Claude never executes a tool itself -- it only requests a call; your application code runs it
- That tool description quality (what it does, when to use it, what each parameter means) is the single biggest driver of correct tool selection
- The role of a precise input_schema (JSON Schema with types, required fields, enums, per-field descriptions) in producing well-formed arguments
- Structured error handling (e.g., an is_error flag or message in the tool_result) so Claude can recover or retry instead of guessing
- Client-side vs. server-side tool execution, and the value of right-sizing the tool set to avoid overlap and context bloat
- Approval patterns that require human or hook-based sign-off before a sensitive or destructive tool executes
Skills in
- Writing tool descriptions detailed enough to drive correct tool selection rather than vague ones that get misused or ignored
- Authoring precise input_schema definitions with types, required fields, enums, and per-parameter descriptions
- Implementing the full tool_use -> execute -> tool_result loop, matching results to the correct tool_use_id
- Returning structured, informative errors from a failed tool call instead of a bare failure
- Right-sizing a tool set to a focused, non-overlapping list, and distinguishing client-side execution from server-side built-in tools
- Gating sensitive or destructive tool calls behind an approval pattern
Concepts
The Tool-Use Loop: tool_use, tool_result, and Who Executes
✎CoreThe loop is: send tools array -> Claude emits a tool_use block (name + input) -> your code executes it -> you return a tool_result matched by tool_use_id -> Claude continues or ends the turn
Writing Good Tool Definitions: Descriptions, Schemas, and Errors
✎CoreTool description quality -- what it does, when to use it, what each parameter means -- is the top driver of correct tool selection
disable_parallel_tool_use: Forcing One Tool Call Per Turn
✎CoreCurrent models default to parallel tool calling: multiple independent tool_use blocks in one turn, executed concurrently, with all tool_result blocks returned together
Understand MCP servers, their primitives, and transports
Understanding the Model Context Protocol as a standard for exposing reusable tools, resources, and prompts, and matching transport (stdio vs. HTTP/sockets) to deployment.
Knowledge of
- MCP as an open standard ('a USB-C port for AI') for connecting AI applications to external systems so a capability is built once and reused across any MCP-compatible client
- The three core primitives an MCP server can expose: tools (model-callable actions), resources (readable data/content loaded into context), and prompts (reusable parameterized templates)
- The client/server roles: the client lives inside the AI application and connects to one or more servers; the server advertises and handles calls to its tools/resources/prompts
- Transport options -- stdio for a local, single-user subprocess integration, and Streamable HTTP/sockets for a remote server serving multiple clients
- The canonical MCP use case: a capability that must be reusable across multiple Claude applications and maintained independently of any single app
Skills in
- Recognizing when a requirement (reusable, independently maintained, shared across apps) calls for an MCP server rather than app-local logic
- Distinguishing MCP's three primitives (tools, resources, prompts) instead of assuming MCP only exposes tools
- Matching transport to deployment: stdio for local/single-user, HTTP/sockets for remote/multi-client
- Avoiding the anti-pattern of hard-coding integration logic into each app's prompt when a shared MCP server is the reusable, maintainable answer
Concepts
MCP Primitives: Tools, Resources, and Prompts
✎CoreMCP is an open standard ('USB-C for AI') that lets a capability be built once and reused across any MCP-compatible client
MCP Transports: stdio vs. Streamable HTTP/Sockets
✎Corestdio: local subprocess transport, ideal for local, single-user integrations
The API MCP Connector: mcp_toolset, defer_loading, and enabled
✓AdvancedThe API MCP Connector attaches a remote MCP server directly via the Messages API using an mcp_toolset object in the tools array, with a default_config block plus optional per-tool configs keyed by tool name
MCP Configuration Scope (Four Levels) and the Secrets-in-Config Anti-Pattern
✎CoreMCP configuration has four scope levels: Local (~/.claude.json, per-project, not shared), User (personal, across all projects, not shared), Project (.mcp.json at repo root, committed, shared with clones), and Enterprise (admin-managed, org-wide)
Choose the right agentic customization mechanism
Selecting among built-in tools, custom tools, Skills, and MCP servers based on reusability, maintainability, and where the capability's logic should live.
Knowledge of
- Built-in tools (Anthropic-provided, e.g., web search, code execution, computer use) as the least-effort option when the capability already exists
- Custom tools as app-specific function-calling logic that lives with a single application
- Skills as packaged instructions plus optional scripts/resources (SKILL.md) that Claude loads when relevant, for reusable know-how without a running service
- MCP servers as the mechanism for a capability reused across many apps and maintained independently, possibly remotely
- That built-in tools have fixed capabilities and cannot automatically reach an arbitrary internal API -- that requires a custom tool or an MCP server
Skills in
- Applying the selection heuristic: use a built-in if it already does the job; use a custom tool for app-specific logic; use a Skill for reusable procedural know-how without a service; use an MCP server for a capability shared across apps and maintained independently
- Recognizing when a scenario describes reusable knowledge/procedure (Skill) versus a reusable, independently maintained service (MCP server)
- Avoiding the mistaken assumption that a built-in tool can reach any internal REST API
Concepts