Skip to content

CCDV-F : Tools & MCPs (Domain 8)

Domain 8 : Tools and MCPs

25 questionsmedium

This study guide provides an exhaustive technical analysis of Domain 8 for the Claude Certified Developer – Foundations (CCDV-F) certification. Domain 8, titled “Tools and MCPs,” accounts for 10.6% of the exam weighting and is divided into three critical subdomains: Tool Implementation (4.4%), MCP Server Development (2.1%), and Agentic Customization (4.1%). This guide synthesizes technical specifications from the Anthropic API, the Model Context Protocol (MCP), and the Claude Agent SDK to prepare candidates for the architectural and implementation challenges found in production-grade AI applications.

1. Subdomain 8.1: Advanced Claude Tool Implementation Mechanics

Tool implementation represents the bridge between Claude’s reasoning and the execution of external logic. In the CCDV-F framework, this is not merely about providing a function but about engineering a contract that the model can reliably navigate.

Claude Tool Technical Schema Specifications and JSON Schema

At the core of tool use is the tool definition, which must be provided as a JSON schema. This schema defines the structure of the input arguments Claude must generate. A valid tool definition includes:

  • Name: A unique identifier that follows specific naming conventions (typically alphanumeric with underscores).
  • Description: A detailed, natural language explanation of what the tool does and when to use it.
  • Input Schema: A standard JSON Schema object defining the properties, types, and required fields for the tool’s arguments.

Developers must ensure that types are strictly defined (e.g., string, number, boolean, array, object) and that the required array correctly identifies parameters the model cannot omit.

Descriptive Tool Writing for Model Performance

The efficacy of a tool is highly dependent on the quality of its description. Since Claude uses these descriptions to determine tool selection, the guide emphasizes “descriptive tool writing.” Effective descriptions should:

  • Explain the tool’s primary purpose and its limitations.
  • Provide context for the expected values of specific parameters (e.g., “The ISO 4217 currency code”).
  • Use clear, unambiguous language that distinguishes similar tools (e.g., differentiating between a search_products tool and a get_product_details tool).

Tool Error Handling and Structured Actionable Error Envelopes

A critical requirement for production systems is the implementation of structured, actionable error envelopes. When a tool execution fails on the client side, the developer should not simply return a generic error message to the model. Instead, the error should be returned in a format that allows the model to understand the failure and potentially retry with corrected parameters.

Actionable error envelopes include:

  1. The Error Type: Categorizing the failure (e.g., invalid_parameter, rate_limit_reached, upstream_service_down).
  2. The Detailed Message: Explaining exactly what went wrong (e.g., “The ‘start_date’ must be in the past”).
  3. Correction Hints: Providing the model with enough information to fix its own mistake (e.g., “Current date is 2026-07-20; provided date was 2026-08-01”).

By returning these “envelopes,” developers enable the agent to correct itself without human intervention, maintaining the autonomy of the agentic loop.

Client-Side vs. Server-Side Tools

The CCDV-F exam distinguishes between where the logic of a tool resides:

  • Client-Side Tools: These are defined and executed by the application that is calling the Claude API. The application receives a tool_use block from Claude, executes the local code, and sends a tool_result back to the API. This provides the developer with maximum control over the environment and security.
  • Server-Side Tools: Often associated with the Model Context Protocol (MCP) or hosted agent environments, these tools reside on a remote server. The application acts as a host that routes requests to the server, which then returns the result.

Approval Patterns and Human-in-the-Loop

For consequential or “destructive” actions (e.g., processing a refund, deleting a repository, or making a financial transaction), developers must implement approval patterns. This involves a state where the agent pauses and requests confirmation from a human before the tool logic is actually executed. This is often implemented via “hooks” or dedicated approval states in the Claude Agent SDK.

The tool_choice Parameter: Auto, Any, and Forced

The Anthropic API provides a tool_choice parameter to control how the model interacts with the tools provided in a request:

  • auto (default): Claude decides whether to use a tool or provide a text response based on the context of the conversation.
  • any: Claude is forced to use at least one of the provided tools, but it can choose which one. This is useful for ensuring structured data extraction.
  • tool (Forced): Claude is forced to use a specific, named tool. This is often used in multi-step workflows where the next action must be a specific function call.

2. Subdomain 8.2: Model Context Protocol (MCP) Server Development Guide

The Model Context Protocol (MCP) is an open standard that enables developers to expose data and functionality from their own systems to AI models in a consistent way. Understanding the MCP architecture is a major component of the CCDV-F Domain 8.

The Client-Host-Server Architecture

The MCP ecosystem is built on a three-tier architecture:

  1. The Server: This is the service that exposes specific resources, tools, and prompts. It contains the business logic for accessing databases, APIs, or local files.
  2. The Host: The application that the user interacts with (e.g., Claude Desktop, Claude Code, or a custom application built with the Claude Agent SDK). The host manages the connection to the MCP server.
  3. The Client: A component within the host that establishes the actual protocol-level connection to the server.

MCP Primitives: Resources, Tools, and Prompts

MCP servers provide three primary primitives that allow the model to interact with external data:

  • Resources: These are read-only data sources. They function similarly to files or database entries. A model can “read” a resource to gain context. Resources are identified by URIs (e.g., postgres://db/table/row).
  • Tools: These are executable functions that the model can call to perform actions or retrieve dynamic data. Tools in MCP follow the same function-calling logic as standard Claude API tools, including name, description, and input schema.
  • Prompts: These are reusable templates provided by the server. They help the user or the host construct complex requests that utilize the server’s specific capabilities.

Transport Mechanisms: Stdio vs. SSE

MCP supports different “transports” for communication between the client and the server:

  • Stdio (Standard Input/Output): This is the primary transport for local MCP servers. The host launches the server as a child process and communicates with it via standard input and output streams. This is common for local development tools and filesystem access.
  • SSE (Server-Sent Events): This transport is used for remote MCP servers. It allows a host to connect to a server over HTTP. This is essential for enterprise-scale deployments where data resides on remote infrastructure.

MCP Deployment and Configuration

Developing an MCP server requires defining the methods the server supports (e.g., list_tools, call_tool, list_resources). Configuration often happens via a config.json or through the host’s settings (such as the Claude Desktop configuration file). Developers must ensure that the server correctly handles authentication, authorization, and audit logs to prevent unauthorized access to sensitive backend systems.

3. Subdomain 8.3: Claude Agentic Customization and Tool Tradeoffs

Subdomain 8.3 focuses on the high-level decision-making required to select the right tool-use pattern for a specific use case. A developer must be able to weigh the pros and cons of built-in tools, custom tools, Skills, and MCP servers.

Comparative Analysis of Tool Types

Tool TypeDefinitionBest Use CaseKey Tradeoff
Built-in ToolsTools provided directly by Anthropic (e.g., Web Search, Code Execution).Common, general-purpose tasks like searching the live web or running math.Limited customization; controlled entirely by Anthropic.
Custom ToolsBespoke functions defined in the developer’s application code.Specific business logic or private API integrations within a single app.High maintenance; not easily reusable across different applications.
SkillsSpecific extensions used primarily within Claude Code.Modernizing codebases, automating repo-level engineering tasks.Restricted to the Claude Code environment.
MCP ServersReusable servers that implement the Model Context Protocol.Exposing enterprise data (SQL, Slack, GitHub) to multiple AI clients.Higher initial setup complexity; requires maintaining a separate server.

Decision Criteria for Tool Selection

When architecting an agentic system, the CCDV-F candidate must evaluate the following criteria:

  1. Reusability: If the functionality needs to be shared across multiple applications or teams, an MCP server is the preferred choice.
  2. Environment: If the developer is working within the Claude Code CLI, authoring a “Skill” provides the most integrated experience.
  3. Security/Control: Custom tools provide the tightest integration with the local application’s security context, whereas MCP servers require explicit authentication/authorization layers.
  4. Complexity: Built-in tools are the simplest to implement as they require no infrastructure management from the developer.

Managing State and Context in Agentic Customization

As agents grow more complex, managing the context window becomes critical. Customization involves not just adding tools, but also:

  • Tool Output Pruning: Removing or summarizing large tool results to prevent context drift and bloat.
  • Subagent Delegation: Using the Claude Agent SDK to spin up a specialized subagent for a tool-heavy task, thereby isolating the main agent’s context window from noisy tool executions.

4. Security and Safety in Claude Tool Operations

Security is a pervasive theme in Domain 8. When an agent is granted the ability to use tools, it becomes an “autonomous actor” with access to external systems.

Prompt Injection and Jailbreak Defense

A primary risk in tool use is prompt injection, where untrusted user input is passed into a tool call, causing the agent to execute unauthorized actions. The CCDV-F framework advocates for:

  • Input Sanitization: Validating and cleaning all user-provided data before it reaches the tool-use logic.
  • Isolating Untrusted Input: Using system prompts and Claude Agent SDK “hooks” to ensure that user content cannot override the “system” instructions that define the tool’s boundaries.
  • Defensive Parsing: Treating all model-generated tool arguments with skepticism and validating them against strict schemas before execution.

Least Privilege and Identity Management

Developers must apply “secure-by-design” principles:

  • Least Privilege: Tools should only have the permissions absolutely necessary for their function (e.g., a tool meant to read logs should not have delete permissions).
  • Identity and Access Management (IAM): Every tool execution should be traceable to a specific user and authenticated via secure secrets management (not hard-coded keys).

5. Deep Dive: Structured Actionable Error Envelopes in Claude

To pass CCDV-F Domain 8, one must understand the anatomy of a “well-behaved” tool error. If Claude attempts to call a tool get_user_by_id with an ID that doesn’t exist, the application’s response determines if the agent can recover.

Example of an Unstructured Error (Bad)

Error: 404 Not Found

Why this fails: Claude doesn’t know if the ID was formatted wrong, if the database is down, or if it should try a different ID.

Example of a Structured Actionable Envelope (Good)

{
  "status": "error",
  "error_code": "RESOURCE_NOT_FOUND",
  "message": "User with ID 'usr_123' does not exist in the North America region database.",
  "actionable_fix": "Please check the user ID prefix. Valid prefixes are 'US_' or 'EU_'. If searching for a new user, ensure the sync process has completed (usually takes 5 minutes).",
  "retryable": true
}

Why this succeeds: Claude can now reason: “Ah, I used a ‘usr_’ prefix instead of ‘US_’. I will try again with ‘US_123’.” This pattern is foundational to reducing “agentic stuckness” and is a key focus of the CCDV-F exam questions regarding reliability.

6. Mastering Claude Code CLI and Tooling Ecosystem

Claude Code is a significant part of the Architect and Developer certifications. Its integration with Domain 8 involves understanding how it uses tools in a “headless” and “auto” mode environment.

The CLAUDE.md Hierarchy

Claude Code uses a special file, CLAUDE.md, to manage project-level instructions and tool configurations. This file acts as a permanent context for the agent, defining:

  • Build and test commands.
  • Style guides for code generation.
  • Contextual clues for navigating the repository.

In the context of Domain 8, CLAUDE.md helps the agent determine which local scripts or commands can be used as tools to solve a task.

Claude Skills and Plugins

Skills are specialized tools designed specifically for the Claude Code interface. They allow developers to extend the CLI’s capabilities by adding custom commands. These are particularly useful for automating CI/CD tasks or repository modernization, where the agent needs to perform multi-file edits and run test suites autonomously.

7. Claude 3 Model Selection Tradeoffs for Tool Performance

Different Claude models perform differently when handling complex tool schemas and high-volume tool calls.

  • Claude 3.5 Sonnet: Generally considered the “gold standard” for tool use due to its balance of high reasoning capability and low latency. It is highly reliable at following complex JSON schemas.
  • Claude 3 Opus: Used for the most complex reasoning tasks where tool selection requires navigating very large numbers of possible tools or extremely nuanced descriptions.
  • Claude 3 Haiku: Optimized for speed and cost. It is best suited for simple, high-frequency tool calls where the logic is straightforward and the schema is small.

The exam requires understanding these tradeoffs, especially when managing token budgets and costs associated with large tool descriptions and output.

8. Integrating Tools with the Claude Agent SDK

The Claude Agent SDK provides the programmatic framework for managing the agentic loop, orchestration, and delegation.

Orchestration and Subagents

In complex scenarios, a single agent may become overwhelmed by too many tools or too much context. The Architect and Developer foundations emphasize the use of “Subagent Delegation.”

  • The Manager Agent: Owns the primary task and high-level planning.
  • The Subagent: A specialized agent created by the Manager to handle a specific sub-task (e.g., “Research the latest news on X”). The subagent is given only the tools necessary for its task, effectively pruning the context window and improving the reliability of tool selection.

Hooks and Lifecycle Management

The SDK allows developers to inject logic at various points in the agentic loop through “Hooks.” This is where security checks, logging, and human-in-the-loop approvals are typically implemented. For example, a pre-tool-call hook can be used to validate that the model is not attempting to access a resource it shouldn’t.

9. Configuration Management for Claude AI Tools

Managing the configuration of tools, model versions, and prompts is essential for maintaining production stability.

Version Pinning and Prompt Versioning

As models are updated (e.g., from Sonnet 3.5 to a newer release), their behavior with specific tool descriptions may change. CCDV-F emphasizes:

  • Model Version Pinning: Ensuring the application uses a specific model version to prevent unexpected changes in tool-calling behavior.
  • Prompt/Tool Versioning: Treating tool descriptions and system prompts as code, subject to version control and regression testing.

Settings.json and Repository Initialization

For tools like Claude Code, configuration is often centralized in settings.json. This file governs the agent’s behavior, including tool permissions, auto-mode settings, and plugin dependencies. Understanding how to initialize a repository for Claude Code use—including the creation of these configuration files—is a practical skill tested in the Domain 8 blueprint.

10. Evaluation and Testing of Claude Tool Systems

The final piece of the Domain 8 puzzle is evaluating whether the implemented tools and MCP servers actually work as intended.

Trace Analysis and Debugging

When an agent fails to complete a task, the developer must perform “trace analysis.” This involves looking at the sequence of messages and tool_use/tool_result blocks to identify where the failure occurred:

  1. Selection Failure: Did the model pick the wrong tool? (Likely a description issue).
  2. Argument Failure: Did the model provide invalid arguments? (Likely a schema or prompt issue).
  3. Execution Failure: Did the tool logic crash? (Likely a code bug).
  4. Parsing Failure: Did the model fail to understand the tool’s result? (Likely an output formatting issue).

Designing Evals for Tool Use

Robust evaluations (Evals) should include “Golden Sets” of tool-use scenarios. These tests verify that the model correctly selects and calls the necessary tools across a variety of user prompts, including edge cases and adversarial inputs meant to trigger prompt injection.


Glossary of Key Claude AI & MCP Terms

  1. Agentic Loop: The iterative process where an AI model plans, executes a tool, observes the result, and plans the next step until a goal is reached.
  2. Claude Agent SDK: A software development kit designed to help developers build and manage multi-agent systems and complex workflows.
  3. Claude Code: A command-line interface (CLI) tool for software engineering tasks, capable of autonomous repository editing and tool use.
  4. Client-Host-Server: The three-tier architecture of the Model Context Protocol (MCP) defining the relationships between the data provider and the AI consumer.
  5. Context Drift: A phenomenon where an agent loses track of its original goal due to an accumulation of irrelevant information in its context window.
  6. Custom Tool: A user-defined function provided to the Claude API to extend its capabilities with bespoke logic.
  7. Descriptive Tool Writing: The practice of creating detailed, clear natural language descriptions to help models identify the correct tool for a given task.
  8. Golden Set: A curated list of prompt-response-tool pairs used as a benchmark for evaluating model performance and reliability.
  9. Human-in-the-Loop (HITL): A design pattern where an agent pauses for human approval before executing sensitive or destructive tool actions.
  10. MCP Primitive: The basic building blocks of the Model Context Protocol: Resources, Tools, and Prompts.
  11. Model Context Protocol (MCP): An open standard for connecting AI models to data sources and executable functions.
  12. Prompt Injection: A security vulnerability where malicious user input manipulates an AI’s instructions to perform unauthorized actions.
  13. Resource (MCP): A read-only data source exposed by an MCP server, often identified by a URI.
  14. SSE (Server-Sent Events): A transport mechanism for remote MCP servers using HTTP to stream events to a client.
  15. Stdio (Standard I/O): The primary transport mechanism for local MCP servers, communicating via system input/output streams.
  16. Structured Actionable Error Envelope: A method of returning tool errors that includes detailed metadata and hints to help the model self-correct.
  17. Subagent Delegation: An orchestration pattern where a primary agent creates a specialized subagent to handle a specific, tool-heavy sub-task.
  18. Tool_choice: An API parameter that allows a developer to force the model to use a specific tool, any tool, or let it decide automatically.
  19. Tool Output Pruning: The process of removing unnecessary data from a tool’s result to minimize context window consumption.
  20. URI (Uniform Resource Identifier): A string of characters used to identify a specific resource in the MCP ecosystem.

Domain 8 Tools & MCPs: Short Answer Review Questions

1. What is the primary difference between a Resource and a Tool in the Model Context Protocol?

  • Answer: A Resource is a read-only data source used for context, while a Tool is an executable function that can perform actions or retrieve dynamic data. Resources are typically static or state-based information, whereas Tools involve logic and side effects.

2. Why is the “description” field in a JSON tool schema considered a critical engineering component?

  • Answer: Claude uses the description to understand the tool’s purpose and decide when to call it. A poor description leads to tool selection errors, while a precise description improves the model’s reasoning about which function fits the user’s intent.

3. What are the three possible values for the tool_choice parameter, and what does each do?

  • Answer: auto allows the model to choose between text or tool use; any forces the model to use at least one tool from the list; and tool (or forced) compels the model to use a specific, named tool.

4. Describe a “Structured Actionable Error Envelope” and why it is superior to a standard error message.

  • Answer: It is a response containing the error code, a detailed message, and hints for correction. It is superior because it provides the model with enough context to understand the failure and fix the parameters in a subsequent retry attempt.

5. In MCP architecture, what is the role of the “Host”?

  • Answer: The Host is the application (e.g., Claude Desktop) that the user interacts with; it initiates the connection to the MCP server and manages the lifecycle of the AI session.

6. When should a developer choose an MCP server over a Custom Tool?

  • Answer: A developer should choose an MCP server when the tool functionality needs to be reused across multiple different applications or shared with a wider team, as MCP is a standardized, interoperable protocol.

7. How does “Subagent Delegation” help manage context window limits?

  • Answer: It spins off a specialized subagent for a specific task, meaning the verbose tool calls and intermediate results for that task stay in the subagent’s context window, keeping the manager agent’s window clean and focused on high-level goals.

8. What is the purpose of the CLAUDE.md file in the Claude Code ecosystem?

  • Answer: It provides persistent project-level instructions, build commands, and coding standards that guide the agent’s behavior and tool use across the entire repository.

9. Which transport mechanism is typically used for local MCP servers, and how does it function?

  • Answer: The stdio transport is used for local servers; it functions by launching the server as a child process and communicating via the standard input and output streams of the operating system.

10. What security principle dictates that a tool should only have the minimum permissions necessary for its task?

  • Answer: The Principle of Least Privilege. It ensures that if an agent is compromised or misdirected, the potential damage is limited to the specific scope of that tool’s authorized actions.

Domain 8 Tools & MCPs: Open-Ended Design Questions

  1. Scenario: You are designing a Claude-powered agent for a financial services firm that needs to interact with a legacy SQL database, a real-time stock ticker API, and a secure document storage system. Explain how you would structure this using the Model Context Protocol. Which transports would you use for each component, and how would you handle the “approval patterns” for a tool that executes a stock trade?
  2. Scenario: An agent you built is repeatedly failing to call a specific tool correctly, often providing the wrong date format despite the JSON schema specifying a string. Detail your process for trace analysis and describe three distinct changes you could make to the system instructions, the tool description, or the error handling logic to remediate this.
  3. Scenario: You have a choice between implementing a set of “Skills” for Claude Code or a standalone MCP server for your team’s internal API documentation. Analyze the tradeoffs regarding reusability, maintenance, and the “developer experience” for a team that uses both the Claude web interface and the Claude Code CLI.
  4. Scenario: Describe the design of an “Actionable Error Envelope” for a web search tool that has hit a rate limit. How should the envelope be structured to encourage the agent to either switch to a different search tool or wait and retry later, rather than giving up on the task?
  5. Scenario: Evaluate the security risks of allowing an autonomous Claude agent to use a “Code Execution” built-in tool versus a “Custom Tool” that only executes pre-defined SQL queries. What guardrails would you implement in each case to prevent destructive actions or data leakage?

Leaderboard

No scores saved yet. Be the first!

25 Questions — Domain 8 : Tools and MCPs

Expand any question to reveal the correct answer and explanation.

  1. 1 A developer needs to ensure that Claude prioritizes a specific data-scrubbing tool before performing any other actions in a sensitive workflow. Which configuration of the $tool\_choice$ parameter should be implemented?

    Consider which option moves the decision-making from the model's discretion to a strict requirement for a single identified function.

    tool_choice = {"type": "tool", "name": "scrub_data"}

    This configuration forces the model to invoke a specific named tool, ensuring deterministic behavior for a critical step in the application logic.

    • tool_choice = {"type": "auto"}

      This setting is the default and allows the model to choose between using any tool or simply responding with a text turn, which does not guarantee tool invocation.

    • tool_choice = {"type": "any"}

      While this forces the model to use a tool, it does not specify which one, allowing the model to select any tool from the provided definitions.

    • tool_choice = {"type": "forced"}

      'forced' is not a valid type value for the tool_choice parameter in the Claude API; the correct keywords are 'auto', 'any', or 'tool'.

  2. 2 In the context of the Model Context Protocol (MCP), where should the management of API credentials and user approval policies reside to maintain the intended security trust boundary?

    Think about which component in the client-host-server architecture serves as the gateway to external systems and user-defined rules.

    In the MCP Client layer

    The client acts as the trusted orchestrator responsible for security policies, credential management, and mediating user permissions before requests reach the server.

    • In the MCP Server layer

      The server should remain isolated and only execute logic, as exposing credentials there would violate the decoupling of tool execution from context management.

    • Within the Claude Model runtime

      Large language models do not have native facilities for securely storing environment-specific credentials or enforcing programmatic access control lists.

    • In the stdio transport channel

      Transport channels like stdio or SSE are only communication conduits and should not hold persistent state or security logic.

  3. 3 A production tool returns a '429 Too Many Requests' error from a downstream service. According to the recommended structured error envelope, which category and retry state should be returned to Claude?

    Reflect on how to classify an error that is caused by external resource exhaustion rather than a flaw in the request itself.

    category: "transient", isRetryable: true

    Transient errors designate temporary failures that may resolve themselves, allowing the system to attempt the operation again after a backoff.

    • category: "validation", isRetryable: false

      Validation errors imply a problem with the input schema which retries cannot fix, whereas rate limits are infrastructure issues.

    • category: "business", isRetryable: true

      Business errors typically relate to logical constraints like insufficient funds, rather than temporary network or service availability.

    • category: "permission", isRetryable: false

      Permission errors indicate a lack of authorization, which a simple retry will not resolve without manual intervention or credential updates.

  4. 4 When defining a JSON schema for a complex tool, why is the 'description' field considered a critical architectural component rather than just documentation?

    Consider how the model knows which function to use when it encounters a user's request that doesn't explicitly name a tool.

    It provides the semantic context that Claude uses to decide when and how to call the tool.

    Claude relies on the text description to understand the tool's purpose and the meaning of its parameters, directly influencing invocation accuracy.

    • It is used by the application's parser to map JSON keys to internal functions.

      The mapping of keys to functions is handled by programmatic dispatch logic, not by the string descriptions within the schema.

    • It serves as a required field for client-side regex validation of the model's output.

      Descriptions are for the model's benefit; the application layer uses the 'properties' and 'type' definitions for actual output validation.

    • It is used to generate the system prompt automatically by the Claude SDK.

      While descriptions are passed to the model, they do not replace the developer's responsibility for crafting an effective system prompt.

  5. 5 An agent needs to query a database but receives an error stating 'Access Denied: IP address not whitelisted'. Which 'errorCategory' should the structured error envelope utilize?

    Focus on the root cause being a failure of authentication or authorization rules.

    permission

    Permission errors are appropriate when the identity or the environment lacks the necessary rights to access a resource.

    • transient

      IP whitelisting is a static configuration issue that will not resolve with time or retries, unlike network congestion.

    • validation

      This is an authorization failure rather than a malformed request or schema mismatch.

    • business

      Business logic errors refer to constraints within the application domain, such as a user having a balance too low for a transaction.

  6. 6 A developer is choosing between implementing a 'Skill' in Claude Code versus an 'MCP Server'. What is a primary reason to choose the MCP Server approach for a production environment?

    Think about reusability and the ability to maintain tool logic independently of a single codebase.

    MCP Servers allow for easier sharing of tools across multiple disparate Claude applications.

    The MCP standardizes connections, allowing one server to expose resources and tools to various hosts and clients independently of specific project files.

    • Skills support more complex logical loops and state management than MCP tools.

      MCP tools can call full backend systems and handle complex state, whereas Skills are generally repository-specific markdown/instructions.

    • MCP Servers do not require an active internet connection to communicate with Claude.

      While MCP uses local transports like stdio, it still functions within a stack that typically requires API connectivity for the model itself.

    • Skills are the only way to enforce programmatic guardrails in the application layer.

      Programmatic guardrails are implemented in the application code (the Host/Client), which is common to both MCP and standard tool use.

  7. 7 If the Claude API returns $stop\_reason: "tool\_use"$, what is the next mandatory step for the application developer to maintain the interaction loop?

    Recall the alternating sequence required by the Messages API when a function call is initiated.

    Parse the 'tool_use' block, execute the local function, and return the result in a new 'tool_result' block.

    The developer must act on the model's request by running the specified tool and feeding the output back into the conversation for the next model turn.

    • Terminate the session and display the model's reasoning to the user.

      The 'tool_use' reason indicates the model is waiting for data from the application to continue its reasoning, not that it is finished.

    • Send a new user message asking the model to retry without using tools.

      Asking the model to retry ignores the model's specific request for information and will likely lead to a logic error or refusal.

    • Increase the 'max_tokens' parameter and resend the original request.

      A 'tool_use' stop reason is not caused by token limits; it is a planned pause in generation to gather external data.

  8. 8 In the structured error envelope, which field is specifically designed to help Claude recover from a failure by suggesting a different course of action?

    Look for the property that offers constructive paths forward rather than just describing the current failure.

    alternativeApproaches

    This array provides specific suggestions (e.g., 'try get_user_by_email instead') that help the model pivot its logic when a tool fails.

    • isRetryable

      This boolean only tells the model whether repeating the exact same call might work, not how to change the strategy.

    • errorCategory

      Categories help with classification but do not offer specific functional alternatives to the failed operation.

    • attemptedOperation

      This field merely logs what went wrong for debugging purposes and does not guide the model toward a resolution.

  9. 9 When building an MCP server using stdio as the transport, how is the communication between the host and the server typically structured?

    Focus on the specific protocol and stream types used for local process communication in MCP.

    Through bidirectional JSON-RPC messages over standard input and output streams.

    MCP leverages JSON-RPC for structured requests and notifications, using stdio as a simple and effective local transport mechanism.

    • Using a RESTful API over a local Unix socket.

      While sockets are a valid transport, stdio communication is distinct from REST/HTTP patterns and uses standard input/output directly.

    • By sharing a specific memory buffer defined in settings.json.

      MCP uses message-passing protocols rather than shared memory buffers for security and modularity.

    • Via periodic file system polls in the .claude/ directory.

      Polling is inefficient; stdio provides a continuous, real-time stream for message exchange.

  10. 10 A developer wants to ensure Claude always attempts to use a weather tool but lets it choose which specific weather-related function to call. Which $tool\_choice$ is most efficient?

    Identify the option that forces action but allows flexibility in the selection of the specific tool.

    {"type": "any"}

    The 'any' type forces the model to select at least one tool from the available list, ensuring a tool call while leaving the specific choice to the model.

    • {"type": "auto"}

      Auto allows the model to bypass tools entirely and answer with text, which doesn't meet the requirement of 'always attempting to use' a tool.

    • {"type": "tool", "name": "get_current_weather"}

      This forces a single specific function, which removes the model's ability to choose among multiple weather-related functions.

    • {"type": "multiple"}

      'multiple' is not a valid type in the Claude tool_choice parameter schema.

  11. 11 What is a major advantage of utilizing 'Resources' in an MCP server compared to 'Tools'?

    Consider the difference between a static data lookup and an active functional call.

    Resources provide a way to expose read-only data (like logs or docs) that Claude can fetch as needed.

    Resources act like URIs that Claude can 'read', whereas Tools are designed for active functions that perform operations or state changes.

    • Resources are the only way to perform write operations to a database.

      Tools are the correct mechanism for write operations or any action that has side effects.

    • Resources automatically bypass the user approval layer in the MCP Client.

      While permissions vary, resources do not inherently bypass security; they are simply a different category of data access.

    • Resources are handled entirely in the model's weight space, reducing token usage.

      Resources are external data fetched via the API, which still consumes tokens when included in the model's context.

  12. 12 In a secure MCP implementation, why is it recommended to run the MCP Server in a 'sandbox' or isolated execution environment?

    Focus on the principle of 'least privilege' and preventing the escalation of a prompt injection attack.

    To ensure that compromised model instructions cannot gain unauthorized access to the host file system or network.

    Sandboxing restricts the server's reach, ensuring that even if a model is manipulated into making dangerous calls, the impact is contained.

    • To prevent the model from seeing the server's source code.

      The model only interacts with the tool's interface (schema) and results; it never has direct access to the server's source code by default.

    • To reduce the latency of stdio communication between the client and server.

      Sandboxing typically adds a small amount of overhead and does not improve communication speed.

    • To allow the server to automatically rotate its own API keys without host intervention.

      Credential management should be handled by the trusted Client, not by an isolated Server.

  13. 13 A tool fails because the provided 'start_date' is later than the 'end_date'. Which 'errorCategory' is most appropriate for the response?

    Consider that the model has provided parameters that are logically inconsistent with the function's requirements.

    validation

    Validation errors are used when the inputs provided by the model do not meet the semantic or logical requirements of the tool.

    • transient

      The logic error in the date range is permanent for that specific set of inputs and will not change with a retry.

    • permission

      The failure is due to invalid data, not a lack of authorization.

    • business

      While it relates to logic, 'validation' is the more specific standard for malformed or illogical input parameters.

  14. 14 A developer notices that Claude often confuses two tools with similar names. What is the most effective first step for remediation according to architectural best practices?

    Think about the primary source of information the model uses to understand the 'contract' of a tool.

    Improve the 'description' fields for both tools to clearly state their unique use cases and differences.

    Clear, disambiguated descriptions provide the model with the necessary semantic signals to choose the correct tool for a given context.

    • Switch from Claude Sonnet to Claude Opus to improve reasoning capacity.

      Upgrading the model tier is an expensive and often unnecessary fix for a problem that can be solved with better metadata.

    • Merge the two tools into one single tool with an optional parameter.

      Merging tools can increase complexity and lead to more frequent parameter errors; it is better to maintain distinct tools if the functions are different.

    • Implement a hard-coded classifier in Python to route requests before they reach Claude.

      Hard-coding routing defeats the purpose of an agentic system; the model should be empowered to route correctly via clear instructions.

  15. 15 Which field in the structured error envelope would you use to indicate that a database connection timed out, but the model should try again immediately?

    Combine a category that describes a temporary glitch with a flag that allows the model to repeat the request.

    category: "transient", isRetryable: true

    Transient errors reflect temporary infrastructure issues, and 'isRetryable: true' explicitly signals to the model that a second attempt is valid.

    • category: "permission", isRetryable: true

      Permission errors are not transient and typically do not become valid through a simple retry.

    • category: "validation", isRetryable: false

      A timeout is not a validation failure, and setting retry to false would prevent the model from recovering.

    • category: "business", isRetryable: false

      Timeouts are infrastructure failures, not business logic constraints.

  16. 16 In an MCP architecture, what is the role of the 'Host' application (e.g., Claude Desktop or a custom IDE extension)?

    Think about where the user 'lives' in this three-part system (Host-Client-Server).

    It provides the user interface and initiates connections to MCP Clients and Servers.

    The Host is the environment where the user interacts with Claude and where the integration of MCP capabilities is managed.

    • It executes the tool logic and returns data to the model.

      The tool logic is executed by the Server; the Host merely facilitates the connection.

    • It generates the JSON-RPC messages and performs the model reasoning.

      The Client generates messages, and the model (on Anthropic's servers) performs the reasoning.

    • It acts as a secure firewall that redacts PII before it leaves the local machine.

      While a Host may have security features, its primary architectural role is as the environment that hosts the Client and connects to Servers.

  17. 17 When configuring a tool in the Claude API, what is the purpose of the 'required' array within the 'parameters' object?

    Consider how you ensure the model doesn't 'forget' to provide a piece of data like a customer ID.

    It defines which parameters must be provided by Claude for the tool call to be considered valid.

    The 'required' array enforces that the model cannot omit essential information, enabling the application to validate the request effectively.

    • It lists the API keys needed to access the tool.

      API keys are managed in the application layer and are not part of the tool's JSON schema definition.

    • It specifies the minimum token count required to invoke the tool.

      Token counts are a result of the model's output length and do not serve as a constraint for tool invocation.

    • It lists the alternate tools that should be called if this one fails.

      Error recovery is handled by the structured error response, not by the initial tool definition.

  18. 18 A developer wants to implement a 'Human-in-the-loop' pattern for a tool that deletes user data. Where is the most appropriate place to implement the approval prompt?

    Think about which part of the system has the authority to 'gate' a sensitive action and talk to the user.

    In the Application (Client/Host) layer before dispatching the tool call

    The application layer is responsible for safety and user interaction, making it the correct place to intercept a 'tool_use' request and ask for confirmation.

    • Inside the MCP Server code

      The server should be an isolated execution layer; it shouldn't have direct access to the user interface for prompts.

    • In the system prompt instructions

      Prompt-based instructions for approval are not enforceable guardrails and can be bypassed by the model's stochastic nature.

    • As an 'alternativeApproach' in a structured error envelope

      Approval is a prerequisite for execution, not a fallback after a failure has already occurred.

  19. 19 Why would a developer use 'Server-Sent Events' (SSE) instead of 'stdio' for an MCP Server?

    Consider the limitations of standard input/output when components are not running on the same local computer.

    To allow the MCP Server to run on a remote machine rather than as a local subprocess.

    SSE provides a network-based transport mechanism, enabling distributed architectures where the server is not on the same physical machine as the host.

    • Because SSE is faster for transferring large binary files like images.

      SSE is a text-based protocol and is not specifically optimized for binary data compared to other network protocols.

    • To bypass the need for JSON-RPC formatting.

      MCP still uses JSON-RPC regardless of the transport layer (stdio or SSE).

    • To ensure that Claude can call the tool even when the application is offline.

      Tool calls require an active connection between the Client and the Server; SSE does not enable offline functionality.

  20. 20 If a tool call returns an error with category 'business', how should the model typically interpret this result?

    Focus on errors that represent 'valid request, but the answer is no' according to the rules of the project.

    As an indication that the request was valid but blocked by an application rule (e.g., 'Account Frozen').

    Business errors convey that a rule in the logic domain (not the code or transport) prevented the action, and the model should inform the user.

    • As a sign that the tool is broken and should not be used again.

      A business error means the tool worked correctly but could not fulfill the request due to domain rules.

    • As a prompt to automatically retry the operation with more tokens.

      Business rules are deterministic; retrying with more tokens will not change a logical constraint like a frozen account.

    • As a permission failure that requires new API keys.

      Permissions are about access rights; business rules are about the state of the data or the user's eligibility.

  21. 21 Which $tool\_choice$ parameter value is used by default if the developer does not explicitly provide one in the API request?

    Think of the most flexible option that allows the model to lead the conversation.

    auto

    'auto' is the standard behavior where Claude determines if a tool call is helpful based on the user's input.

    • any

      'any' is a specialized setting that forces a tool call and is not the default behavior.

    • none

      'none' would disable tools entirely, which is not the default if tools are defined in the request.

    • tool

      Forcing a specific tool requires explicit naming and cannot be a generic default.

  22. 22 An MCP server provides a 'Prompt' resource. How does this differ from a standard 'Tool'?

    Consider the role of templates in guiding user behavior versus the role of functions in executing code.

    Prompts are reusable templates that help users (and Claude) structure their interactions with specific tools.

    MCP Prompts are pre-defined instruction sets or templates that can be used to standardize how a user or model performs a task.

    • Prompts are used to store API keys for the server.

      Credentials should never be stored in prompts; they belong in the Client's secure environment.

    • Prompts allow the server to directly modify the model's weights during a session.

      Model weights are fixed; prompts only provide context for the current generation.

    • Prompts are required for SSE transports but not for stdio.

      Prompts are a functional category in MCP, independent of the transport layer used.

  23. 23 In the structured error envelope, what is the purpose of the 'partialResults' field?

    Think about how to prevent a 'total loss' when a complex, multi-stage task only partially fails.

    To provide any data that was successfully retrieved before the error occurred, allowing for a more graceful failure.

    If a tool performs several actions and only the last one fails, 'partialResults' prevents the loss of useful information already gathered.

    • To show the model exactly where the syntax error occurred in the JSON.

      Syntax errors are handled by the 'validation' category; partialResults is for successful parts of a multi-step operation.

    • To list the partial tokens consumed by the failed tool call.

      Token tracking is handled by the API's usage block, not by the tool's error envelope.

    • To store the encrypted version of the error message for audit logs.

      The error envelope is for model context and shouldn't contain encrypted data the model cannot read.

  24. 24 A developer wants Claude to only use one specific tool and never respond with just text. Which $tool\_choice$ is most restrictive and safe for this use case?

    Identify the option that combines a forced action with a named destination.

    tool_choice = {"type": "tool", "name": "target_tool"}

    This forces the model to use the specified tool and prevents it from responding with text, ensuring a deterministic functional output.

    • tool_choice = {"type": "any"}

      This forces a tool call but could allow the model to pick a different tool if multiple are defined.

    • tool_choice = {"type": "auto"}

      Auto allows for text-only responses and is the least restrictive option.

    • tool_choice = {"type": "required"}

      'required' is not a valid key for the tool_choice parameter; the correct keyword is 'any' or 'tool'.

  25. 25 When building a production-grade MCP Server, why might you implement 'sampling' in the Client?

    Think about the Server needing to 'ask a follow-up question' to the AI before it finishes its job.

    To allow the server to ask the model for additional reasoning or information while it is executing a tool.

    Sampling allows the MCP Server to 'call back' to the model via the Client to handle ambiguous situations during tool execution.

    • To reduce the number of tokens sent to the MCP Server.

      Sampling actually involves an additional model turn, which increases token usage but provides higher quality outcomes.

    • To ensure that the Server stays within its memory limits.

      Memory limits are an infrastructure concern and are not managed through model sampling requests.

    • To provide random data to the server for testing purposes.

      Sampling refers to model generation, not to random data generation for unit tests.