CCDV-F Glossary - Tools & MCPs

Quick-lookup definitions for every domain, with exam context and links back to the lesson that covers each term.

Tool Description: The description field on a tool definition is the primary signal Claude uses to decide whether and when to call that tool over another, before it ever looks at the parameters. A vague description ("handles user requests") gives the model nothing to discriminate on; a specific one with an explicit trigger condition ("call this when the user asks about current conditions or the forecast for a specific place") and an explicit negative case ("do not use for placing new orders") gives it a clear boundary.; Exam context: The exam's default fix for wrong-tool-selection bugs is tightening descriptions to be specific and mutually exclusive - not switching models, lowering temperature, adding a fixed seed, or adding a few-shot example inside the description as a substitute for resolving the actual overlap.; See also: 5.1 Designing Tool Schemas Claude Can Use Reliably
input_schema: A tool's JSON Schema object (type: "object", a properties map, and a required array). Each parameter benefits from the same specificity as the description: format guidance in a string field's own description (e.g. "ISO 8601") removes ambiguity, and enum should be used whenever valid values are a fixed, small set - it narrows what the model can generate, not just documents the constraint. Flatter schemas outperform deeply nested ones that mirror an internal data model.; Exam context: A common trap is mirroring an internal system's nested object/array structure into input_schema instead of flattening it - every extra nesting level is another place a partially-specified generation can go wrong.; See also: 5.1 Designing Tool Schemas Claude Can Use Reliably
Strict Tool Use (`strict: true`): A top-level field on a tool definition (alongside name, description, and input_schema - not a tool_choice setting) that guarantees tool_use.input validates exactly against the schema. It requires additionalProperties: false and an accurate required array. Without strict, the schema is guidance the model usually follows; with it, malformed or missing-field tool calls become structurally impossible.; Exam context: The exam distinguishes "the model usually gets this right" (default behavior) from "this is enforced" (strict mode) - expect a question testing whether you know strict is a tool-definition field, not a tool_choice value.; See also: 5.1 Designing Tool Schemas Claude Can Use Reliably
Tool Search Tool: The mechanism for handling a large tool library (dozens to hundreds of tools) by letting Claude discover relevant tools on demand instead of holding every schema in context on every request. It's the fix when tool count itself - not description quality - is degrading selection accuracy, since every additional tool definition consumes context and adds a candidate the model has to reason about.; Exam context: Distinguish this from the fix for two overlapping tools (tighten descriptions): the tool search tool addresses a different problem - too many candidate tools loaded at once, not ambiguity between two of them.; See also: 5.1 Designing Tool Schemas Claude Can Use Reliably
Model Context Protocol (MCP): An open, transport-agnostic, JSON-RPC-based standard for connecting an AI application to external tools and data sources through a common interface, instead of hand-writing bespoke tool-calling glue for every external system. An MCP server exposes capabilities that any MCP-compatible client (Claude Code, a custom application, or Claude via the Messages API's MCP connector) can discover and call.; Exam context: MCP's value is reuse/standardization, not performance or correctness - a common wrong answer claims MCP servers run faster or don't need authentication. An MCP server still needs the same auth, input validation, and error handling as any other tool integration.; See also: 5.2 Integrating and Building MCP Servers
MCP Primitives: Tools, Resources, and Prompts: The three kinds of capability an MCP server can expose. Tools are callable functions shaped like a regular tool definition (name, description, JSON Schema input) and are what most exam scenarios focus on. Resources are readable data (a file, a database record) identified by a URI and read directly into context, with no tool call involved. Prompts are reusable, parameterized prompt templates the server exposes. A server isn't required to expose all three - a minimal server might offer tools only.; Exam context: A common mistake is expecting a resource read to show up as a tool_use/tool_result round trip - resources are fetched directly via a conversion helper and inserted as content, not invoked with arguments like a tool.; See also: 5.2 Integrating and Building MCP Servers
Local MCP Server vs. Remote MCP Connector: Two distinct ways Claude talks to an MCP server. A local MCP server runs as a subprocess on the same machine (started over stdio) - the typical Claude Code / Claude Desktop pattern, wired in via a client-side conversion layer with no beta header needed. The MCP connector is a Messages API feature (beta flag mcp-client-2025-11-20) that connects Claude directly to a *remote* server over HTTP, made server-side by Anthropic's infrastructure. It requires both mcp_servers (URL, name, optional authorization_token) and a tools entry of type mcp_toolset referencing that server by name.; Exam context: Confusing the two - e.g. assuming a Claude Code stdio server needs the mcp-client beta header, or that the Messages API connector works without mcp_toolset - is a named exam trap. Omitting mcp_toolset, or naming a server it doesn't reference, is a validation error even with mcp_servers present.; See also: 5.2 Integrating and Building MCP Servers
MCP Server Scoping (Least Privilege): An MCP server connection can be scoped globally (all projects), per-project, or per-session. A server with access to sensitive systems (a production database, PII-bearing internal tools) shouldn't be scoped more broadly than the specific project that needs it - the same least-privilege review applied to any other credentialed dependency, including how the authorization_token credential itself is stored.; Exam context: A recurring exam scenario scopes a sensitive MCP server globally when only one project needs it; the correct fix narrows the scope, not adding more monitoring or trusting the protocol's official status as sufficient safety.; See also: 5.2 Integrating and Building MCP Servers
MCP Tool Results as Untrusted Content: A tool result returned by an MCP server - especially a third-party one you didn't write - is external content and should be treated with the same suspicion as a fetched web page or an uploaded document. A malicious or compromised server can return a result containing an embedded instruction designed to hijack the agent's next action (prompt injection), regardless of MCP being an official, Anthropic-supported protocol.; Exam context: The exam trap is assuming MCP's official status makes its output inherently trustworthy. MCP standardizes the interface, not the trustworthiness of what a given server returns - output still needs the same untrusted-content handling as any other external source.; See also: 5.2 Integrating and Building MCP Servers
tool_choice Modes: Four modes that constrain how a call proceeds: {"type": "auto"} - Claude decides whether and which tool to call (the default when omitted, correct for the overwhelming majority of ordinary agent turns); {"type": "any"} - some tool call is required, model picks which; {"type": "tool", "name": "..."} - forces one specific named tool; {"type": "none"} - suppresses tool calls entirely for that turn. Every mode also accepts disable_parallel_tool_use: true.; Exam context: Defaulting to any "just to be safe" instead of auto is a named trap - it forces a tool call even when none was needed, producing premature calls. auto is the safe default; any/forced-tool are for specific mandatory situations, not general safety nets.; See also: 5.3 Tool Choice and Structured Error Responses
disable_parallel_tool_use: A boolean flag available as a sibling of type inside any tool_choice object (not a separate tool_choice type of its own) that caps a response to at most one tool call, even if the model would otherwise have wanted to make several in parallel.; Exam context: The exam tests whether you know this is a *modifier* on the existing four tool_choice types rather than a fifth type - expect a question that lists it alongside auto/any/tool/none as if it were a peer.; See also: 5.3 Tool Choice and Structured Error Responses
Structured Tool Errors (`is_error`, error categories): A failed tool call should return a tool_result with is_error: true and a categorized, structured error body - e.g. distinguishing invalid_input, not_found, permission_denied, and transient_failure - rather than a generic string or a raw exception/stack trace. Each category implies a different correct follow-up: invalid_input → ask for corrected input; not_found → tell the user the thing doesn't exist; permission_denied → explain the limitation; transient_failure → the one category where a brief automatic retry is actually appropriate.; Exam context: Two linked traps: returning a raw exception/stack trace (unactionable and leaks implementation detail), and retrying automatically regardless of category (a not_found or invalid_input result won't change on retry - only transient_failure should trigger it).; See also: 5.3 Tool Choice and Structured Error Responses
Parallel Tool Call Partial Failure: When Claude requests multiple tools in parallel and one fails while others succeed, each tool_result is reported independently (the failing one with is_error: true and its own structured error, the succeeding ones normally) but all go back together in a single user message so Claude can see the full batch outcome in one turn.; Exam context: The named trap is dropping the failed result or splitting results across separate messages - Claude needs the complete batch outcome in one turn to reason about a sensible combined next step, like proceeding with successful lookups while asking the user to correct the failed one.; See also: 5.3 Tool Choice and Structured Error Responses