Tool Definition
The object you put in the tools array: a name, a description, an input_schema, and optionally properties such as strict, input_examples, defer_loading, cache_control and allowed_callers. Together the first three are everything the model sees when it decides whether to call the tool.
Exam context: The model cannot read your handler, your docstring or your API contract. Every selection failure is therefore a failure of the name, the description or the schema, which is why the answer to "the model chose wrong" is almost never the model.
See also: 8.1 Tool Implementation
Tool Description
The prose field carrying what the tool does, when it should and should not be used, what each parameter means, and the caveats including what the tool does not return. The docs call detailed descriptions "by far the most important factor in tool performance" and set a floor of three to four sentences, more for complex tools.
Exam context: The failure mode is a description that paraphrases the name, because it adds no information the name did not already carry. When a stem describes the wrong tool being chosen, the rewrite is the answer and every option about models, sampling or extra layers is a distractor.
See also: 8.1 Tool Implementation
Disambiguation
The sentence in each of two confusable descriptions that names the sibling tool and says which case belongs to which. Written in both directions, never inferred by the model.
Exam context: The when-not-to-use clause is the half candidates omit and the half the exam keys. Two tools over adjacent parts of the same system will be chosen inconsistently until each description states the boundary explicitly.
See also: 8.1 Tool Implementation
Routing Tool
A third tool added to decide which of two confusable tools to call. It is the move a real developer proposes in a real standup, which is what makes it a strong distractor.
Exam context: It adds a layer instead of removing the cause. The router draws the same distinction from the same uninformative descriptions, the model must now also decide whether to call the router, and a turn is spent arriving back at the original ambiguity. Indirection cannot supply information a description is missing.
See also: 8.1 Tool Implementation
Consolidation
The documented remedy for a sprawling tool surface: group related operations behind a single tool taking an action-style parameter rather than shipping create_pr, review_pr and merge_pr separately. Fewer, more capable tools reduce selection ambiguity.
Exam context: Consolidation fixes sprawl; rewriting descriptions fixes overlap. Both are recommended somewhere in the docs, so the wrong one of the pair is the strongest distractor an item can offer. Count the near-duplicates in the stem before choosing.
See also: 8.1 Tool Implementation
Tool Sprawl
One tool per API endpoint, so eleven endpoints become eleven tools, several of them thin wrappers over adjacent operations. Accuracy falls as the surface grows, because every near-duplicate adds a selection decision and every definition costs context on every request.
Exam context: Anthropic's engineering guidance is explicit that more tools do not always lead to better outcomes. A few thoughtful tools targeting specific high-impact workflows beat wrapping every endpoint.
See also: 8.1 Tool Implementation
Namespacing
Prefixing tool names with the service or resource they belong to, github_list_prs rather than list_prs, so boundaries stay obvious as the library grows. The docs call it especially important once tool search is in play.
Exam context: A legibility property, not a remedy for near-duplicates. Prefixing thirty-eight endpoint wrappers leaves thirty-eight selection decisions; consolidation is what removes them. It also settles clashes between MCP servers: as of September 2026 the specification scopes tool-name uniqueness to a single server, so a client aggregating several servers should prefix each tool with a server identifier, not with the self-reported serverInfo name, which is not guaranteed to be unique.
See also: 8.1 Tool Implementation
input_schema
The JSON Schema declaring a tool's expected parameters. Unlike the description it is enforced rather than suggested: closed sets belong in enum, mandatory fields in required, and units and formats in the per-property description.
Exam context: A schema that permits nonsense will receive nonsense, and the handler spends its life defending against inputs the schema could have refused. When the logs show four spellings of the same value, the enum is the direct fix.
See also: 8.1 Tool Implementation
input_examples
An optional array of example input objects attached to a tool definition. Each example is validated against the tool's own input_schema, so an invalid one returns a 400 rather than silently misleading the model. Roughly 20 to 50 tokens for a simple example, 100 to 200 for a complex nested object.
Exam context: It earns its place on tools with nested objects, optional parameters or format-sensitive fields, and nowhere else. It is unavailable on server tools and on the computer use and browser use toolsets, and it never substitutes for the description.
See also: 8.1 Tool Implementation
strict
A tool-definition property guaranteeing that the tool names and inputs Claude sends match your schema exactly, which removes the missing-parameter class of failure at source instead of catching it in the handler. Available on all tools except mcp_toolset and the two client toolsets.
Exam context: It constrains the shape of a call the model has already decided to make. It supplies no information about which tool to call, so it is a distractor on any selection item, and it does not validate what a tool returns.
See also: 8.1 Tool Implementation
defer_loading
A tool-definition property excluding the definition from the initial system prompt and expanding it inline when the tool search tool returns a tool_reference for it. Configurable per tool on an MCP toolset, and per member inside configs on a client toolset.
Exam context: The honest escape hatch for a genuinely large surface, not a substitute for consolidation when the surface is large because it is full of near-duplicates. Deferred definitions sit outside the cached prefix, so cache breakpoints belong on a tool that is not deferred. Each deferred tool costs a search step before Claude can call it, so the tool search docs advise keeping your three to five most frequently used tools non-deferred.
See also: 8.1 Tool Implementation
tool_result
The content block returned to the model for a client tool call, carrying the tool_use_id it answers and the content the loop continues from. Its optional is_error flag is what distinguishes a failure from a result. Its content can include search_result blocks with a source and title you supply, which Claude cites like web search results once citations are enabled (they are off by default).
Exam context: Server tools need none: the API executes them internally and their result arrives in the same assistant turn. Returning one for a server tool, or writing a handler for it, is a design error rather than a configuration one.
See also: 8.1 Tool Implementation
is_error
The flag on a tool_result marking the call as failed. Paired with a body saying what went wrong and what Claude should try next, it is what lets the model act on a failure instead of inventing around it.
Exam context: The most consequential item in the sub-skill. When a stem asks what stops the fabrication, the answer is what the result says on failure. Longer timeouts and bounded retries change how often the failure happens, never what the model receives when it does.
See also: 8.1 Tool Implementation
Silent Empty Return
Catching a timeout or an upstream failure in the handler and returning an empty string, an empty list or the last known good value so the loop keeps moving.
Exam context: It hands the model a well-formed result asserting that nothing went wrong and that there is nothing there, which makes a plausible invented answer the most probable continuation. Stale data is worse still: confidently wrong, current-looking, and leaving no trace that anything failed.
See also: 8.1 Tool Implementation
Instructive Error Message
The documented shape of an error body: what went wrong and what Claude should try next, for example "Rate limit exceeded. Retry after 60 seconds", instead of a generic failed.
Exam context: An unactionable result is the documented cause of repeated identical calls and stalls: the model has nothing to change between attempts. On genuinely invalid tool calls Claude retries two to three times with corrections before apologising, so the endless-identical-retry story is not a documented mechanism.
See also: 8.1 Tool Implementation
Client Tool
A tool your code executes. The model emits a tool_use block, your process runs the function under your credentials inside your network, and you return a tool_result. Anthropic's infrastructure never executes it.
Exam context: This is why a client tool can reach a database on a private subnet and a server tool cannot. Anthropic ships client tools of its own, whose schema it defines and whose execution is still yours.
See also: 8.1 Tool Implementation, 8.3 Agentic Customisation
Server Tool
A tool Anthropic executes. The call appears as a server_tool_use block whose id carries the srvtoolu_ prefix, the API runs it internally, and its result arrives in the same assistant turn paired by tool_use_id.
Exam context: You do not respond with a tool_result and you do not handle is_error for it. It also runs in the platform's environment, so it cannot reach an address that resolves only inside your network.
See also: 8.1 Tool Implementation, 8.3 Agentic Customisation
Anthropic-Provided
The claim that Anthropic defines a tool, which is not the claim that Anthropic runs it. The Tool reference splits Anthropic-provided tools into server tools executing on Anthropic's infrastructure and client tools whose schema Anthropic defines and whose execution is your application's.
Exam context: Reading "built-in" as "runs on Anthropic's servers" is a named trap. Answer from the capability boundary first. Where a tool runs only matters when the question says so. Don't assume a location it leaves out, and don't rely on today's list of built-in tools, because it changes between releases.
See also: 8.1 Tool Implementation, 8.3 Agentic Customisation
Tool Dispatch
The harness layer that receives a tool-use request, resolves the name to a handler, validates the input, applies the operation's policy, executes under a timeout, logs the call and formats the result the loop continues from.
Exam context: Putting validation, permissions, timeouts and logging at the dispatch point rather than inside every handler is what keeps a tool function a plain function you can unit-test with no model anywhere near it. One place enforces the policy for every tool. Execution order is decided here too: the API does not prescribe an order for one turn's tool_use blocks, so run independent read-only calls in parallel and calls with side effects one at a time, and return an is_error result for any call you skipped.
See also: 8.1 Tool Implementation
Approval Band
The classification deciding whether an operation runs automatically, asks for confirmation, or waits for a second party. Read-only and reversible operations run automatically; consequential ones warrant confirmation; the genuinely dangerous warrant a gate a second party has to pass. Unknown tools are never automatic.
Exam context: The classification is a design decision made once, when the tool set is designed, and expressed in the tool surface. An option relying on an operator noticing what the assistant proposes is not a control. Nor is a band taken from a server's own MCP annotations: as of September 2026 hints such as readOnlyHint are not guaranteed to describe the tool faithfully, and clients must treat them as untrusted unless the server is trusted. Enforcing the gate is Domain 7's material.
See also: 8.1 Tool Implementation
High-Signal Result
A tool response carrying only the fields the next decision needs, identified by semantic stable identifiers such as slugs or UUIDs rather than opaque internal references.
Exam context: Passing the whole upstream payload through spends context on fields no decision depends on and buries the two or three that do, which degrades every step after it in a long session. Truncating the match list and compressing the same payload are both distractors: neither removes the fields nobody needed. When the waste is many calls and bulky intermediate results, programmatic tool calling (generally available as of September 2026) lets Claude call the tool from code in the code execution container, via allowed_callers, so the intermediate results never enter its context.
See also: 8.1 Tool Implementation
Model Context Protocol
An open protocol for exposing a capability once and connecting to it from any compliant client, in place of a hand-written integration re-implemented inside every application that needs the same underlying system. Current specification revision 2026-07-28 as of September 2026: a stateless revision with no initialize handshake, a mandatory server/discover request, opt-in change notifications through subscriptions/listen, and Roots, Sampling and Logging deprecated.
Exam context: The consequence the exam keys is maintenance and reuse, not capability. A custom tool can do the same job for one application; that is not what a stem naming several applications and independent maintenance is asking.
See also: 8.2 MCP Server Development
MCP Host
In the specification's words, "The AI application that coordinates and manages one or multiple MCP clients". Your Claude application is the host.
Exam context: The host creates one client per server, so a host connected to four servers runs four clients, each holding its own dedicated connection. Role-swap distractors put the host on the wrapper side or delete it from the architecture entirely.
See also: 8.2 MCP Server Development
MCP Client
"A component that maintains a connection to an MCP server and obtains context from an MCP server for the MCP host to use." It lives inside the host, one per connected server.
Exam context: Your application sits on the client side of the connection and the thing wrapping your internal system is the server. Getting the direction backwards is the whole content of one recurring item shape.
See also: 8.2 MCP Server Development
MCP Server
"A program that provides context to MCP clients." It exposes tools, resources and prompts over the protocol.
Exam context: Local and remote describe where a server runs, not what it is: the same program is an MCP server whether it runs as a child process on one laptop or as a service several teams reach over the network. Options denying that are flat statements of fact that happen to be false.
See also: 8.2 MCP Server Development
MCP Tool
The model-controlled primitive: functions the LLM can actively call, deciding when to use them based on user requests. Protocol methods tools/list and tools/call.
Exam context: The tools an MCP server exposes are ordinary tools and answer to everything in 8.1. Being reachable over a protocol changes nothing about what a good description or a good error result looks like. Under the 2026-07-28 revision a tool can declare an outputSchema, with results in structuredContent that the client should validate, and state across calls travels as an explicit handle passed as an ordinary argument, because protocol-level sessions are gone.
See also: 8.2 MCP Server Development
MCP Resource
The application-controlled primitive: passive read-only data sources providing information for context, such as file contents, database schemas or API documentation. Each carries a URI, either fixed like records://schema/batch or a parameterised template like records://batch/{batch_id}. Methods resources/list, resources/templates/list and resources/read. Under the 2026-07-28 revision these results carry required caching hints: ttlMs for freshness, and cacheScope, where private keeps a per-user read inside one authorisation context.
Exam context: Where a schema or a reference dataset is exposed as a tool, the model fetches it at unpredictable moments and sometimes not at all, because the decision was handed to the wrong party. Passive reference data belongs on a resource the application reads by URI.
See also: 8.2 MCP Server Development
MCP Prompt
The user-controlled primitive: pre-built instruction templates telling the model to work with specific tools and resources, "user-controlled, requiring explicit invocation rather than automatic triggering". Applications typically surface them as slash commands. Methods prompts/list and prompts/get.
Exam context: When a stem contains a template people want to pull into a session deliberately, the tool-shaped option is the near-miss and the prompt is the answer. Making it a tool hands the decision to the model, which is the opposite of what the person starting the job wanted.
See also: 8.2 MCP Server Development
stdio Transport
The transport using standard input and output streams for direct process communication between local processes on the same machine, with no network overhead. Local servers on stdio typically serve a single client. The server must not write anything to stdout that is not a valid MCP message, so logging goes to stderr or a file; a stray print() corrupts the stream.
Exam context: One developer wrapping a local command line is single-user and local, which is the topology stdio fits. Proposing it for a capability three teams must share means one copy per machine, which is exactly the drift MCP was adopted to remove.
See also: 8.2 MCP Server Development
Streamable HTTP Transport
The transport using HTTP POST for client-to-server messages with optional Server-Sent Events for streaming. It enables remote server communication and supports standard HTTP authentication including bearer tokens, API keys and custom headers, with OAuth recommended for obtaining tokens. Remote servers on it typically serve many clients.
Exam context: Choosing it is a decision to run a service: a version, an owner, an availability expectation, an authentication story and a list of who may connect. Don't rely on a transport name; this part of the specification has already moved once, and the topology rule is what is stable.
See also: 8.2 MCP Server Development
MCP Connector
Anthropic's feature for connecting to remote MCP servers directly from the Messages API without a separate MCP client. The request carries an mcp_servers array plus an mcp_toolset entry in tools, and calls return as mcp_tool_use and mcp_tool_result blocks.
Exam context: Two documented limitations decide items. Only tool calls of the MCP feature set are currently supported, so prompts and resources need a client-side connection of your own, and the server must be publicly exposed over HTTP, so local stdio servers cannot be connected directly. As of September 2026 it is a beta, not available on Amazon Bedrock or Google Cloud, and the mcp-client-2026-09-15 beta header can pin a server's tool list for the length of a conversation.
See also: 8.2 MCP Server Development
Built-In Tool
A capability Anthropic provides, where the platform defines the schema and, for the server-executed ones, runs the tool for you. No code to write, no handler to maintain, no deployment. As of September 2026 the list includes the browser use tool, a client toolset your application runs against its own browser, chosen when a task stays inside webpages and means acting on them.
Exam context: The cheapest correct answer when it fits and the fastest wrong answer when it does not. The guide's own rationale states that built-in tools "do not automatically reach arbitrary internal APIs", which disposes of every option claiming a platform fetch or search capability can reach an internal service.
See also: 8.3 Agentic Customisation
Custom Tool
A function you define and your code executes. It can reach anything your code can reach, runs under your credentials inside your network, and you own it entirely, which is both the benefit and the cost.
Exam context: Right when one application needs the capability, one team owns it, and nothing else is in prospect: simpler, with no deployment story. Against an MCP server the deciding facts are reuse and ownership, never capability, because both can do the same job for one application.
See also: 8.3 Agentic Customisation
Agent Skill
Packaged procedural knowledge: a SKILL.md file with YAML frontmatter, optionally bundled with reference files and executable scripts, which Claude loads when relevant. The load-bearing point is what that does not mean: a Skill changes how Claude does something it can already do, and grants no new capability to call.
Exam context: Instructions are not access. On the Claude API a Skill runs in a sandboxed container with no network access and no runtime package installation, so a Skill genuinely cannot fetch your records however precisely it documents them.
See also: 8.3 Agentic Customisation
Progressive Disclosure
The three-level loading model that makes Skills cheap to install. Metadata, the name and description, is always loaded at roughly 100 tokens per Skill. The SKILL.md body loads only when the Skill is triggered, under 5k tokens. Bundled resources cost nothing until accessed, with scripts run through bash so only their output enters context.
Exam context: An installed but untriggered Skill costs about a hundred tokens, which reframes the comparison: not Skill against tool, but a Skill against carrying several pages of conventions on every request including the four jobs in five that never touch them.
See also: 8.3 Agentic Customisation
Skill Description
The description field in a Skill's YAML frontmatter, and the thing Claude matches a request against when deciding whether to trigger the Skill. It must say both what the Skill does and when to use it. Non-empty, at most 1024 characters, no XML tags.
Exam context: A description saying only what the Skill contains will sit there unused, which is the commonest reason a shipped Skill never fires. The companion name field is at most 64 characters, lowercase letters, numbers and hyphens only, with the reserved words "anthropic" and "claude" forbidden.
See also: 8.3 Agentic Customisation
Cross-Surface Availability
The rule that custom Skills do not sync between Claude's surfaces. A Skill uploaded to claude.ai must be uploaded separately to the API, an API Skill is not available on claude.ai, and Claude Code Skills are filesystem-based and separate from both.
Exam context: Sharing scope differs too: claude.ai Skills are individual to each user, API Skills are workspace-wide, and Claude Code Skills are personal or project-based. A Skill confirmed working on one surface and missing on another is this rule, not a propagation delay.
See also: 8.3 Agentic Customisation
Second Consumer
The single sharpest signal in a stem choosing between a custom tool and an MCP server: another application or surface, actual or imminent, needing the same capability. The other signals are a demand for maintenance independent of any one application, and a system whose owning team should own its integration.
Exam context: Moving a capability from a custom tool to an MCP server is a relocation of the same implementation behind a protocol, not a rewrite, so "we would have to rebuild it" is a false objection when a distractor raises it.
See also: 8.3 Agentic Customisation
Decision Sequence
The four questions this sub-skill is really testing, in order. Does the platform already provide this? Does the model need to do something in a system, or to know how to do something it can already do? If it is a tool, will more than one application need it and does another team own the underlying system? If it is knowledge, is it procedural and only occasionally relevant?
Exam context: The sharpest items list three or four requirements in one stem and ask for an assignment. A candidate who runs the sequence per requirement gets them all; an option assigning every requirement to the same mechanism is almost always wrong on that uniformity alone.
See also: 8.3 Agentic Customisation
Fine-Tuning
A genuine technique aimed at the wrong class of problem in this sub-skill. It changes how a model behaves across a distribution of inputs.
Exam context: It grants access to no system and keeps no procedure current when the procedure changes next quarter. When a stem is about where information lives or what the model can call, fine-tuning answers neither question, and it is expensive and slow besides.
See also: 8.3 Agentic Customisation