Tools and MCP Integration practice questions

Resources require a JSON schema for input arguments just like tools do.

Why it fails: Unlike tools, resources are identified by URIs and do not typically take complex input arguments via a JSON schema. They are meant to be fetched or read directly based on their location. This lack of complexity makes them faster to resolve than tools but less flexible for scenarios requiring dynamic querying.

Tools are automatically called by the MCP Host without model intervention.

Why it fails: Tools are never called automatically; the model must explicitly decide to use a tool based on its description and the user's request. The host only executes the tool after receiving a tool_use request from the model. This design ensures that the model remains the primary controller of the interaction logic.

Resources are always updated in real-time via a WebSocket push mechanism.

Why it fails: While some implementations might support notifications, MCP Resources are generally pulled by the client when needed. They do not rely on a mandatory WebSocket push mechanism. Relying on such a mechanism would complicate the server implementation and is not a requirement for standard MCP compliance in most integration scenarios.

Set tool_choice to 'auto' and include the instruction in the system prompt.

Why it fails: While system prompt instructions are helpful, 'auto' still leaves the final decision to the model. In high-stakes or specific workflow scenarios, the model might occasionally skip the tool call if it believes it has enough information. Explicitly forcing the tool choice is the only way to guarantee the behavior programmatically.

Set tool_choice to 'any' to allow Claude to pick any available tool.

Why it fails: The 'any' setting forces Claude to use at least one tool, but it does not guarantee which tool will be selected if multiple tools are provided. If the goal is to use one specific tool for documentation searches, 'any' is too broad and may result in the model choosing an irrelevant tool.

Omit the tool_choice parameter entirely as it defaults to 'required'.

Why it fails: The tool_choice parameter does not default to 'required'. It defaults to 'auto', meaning the model decides whether or not to use a tool based on the user's input. Omission would not guarantee the tool call, potentially leading to the model answering from its internal knowledge instead of the documentation.

They are automatically injected into the system prompt of every request.

Why it fails: Prompts are not automatically injected; the host application must explicitly request a prompt from the server and then include its content in the message history sent to the model. This manual step ensures that the host maintains control over the conversation context and does not exceed token limits unintentionally.

Prompts are executed as Python code on the server before being sent.

Why it fails: Prompts are templates, not executable code. While the server might use code to generate the prompt string or message list, the prompt itself is delivered as text or message objects to the model. They are instructions for the model to follow, rather than logic that runs on the server.

It automatically encrypts all local data before sending it to the Anthropic API.

Why it fails: MCP does not provide automatic encryption of data sent to the model; that is handled by the transport layer (e.g., HTTPS). MCP focuses on the structure and discovery of context and tools. Developers are still responsible for ensuring that sensitive data is handled according to their own security and privacy requirements.

It reduces the need for the model to reason about which tool to use for a task.

Why it fails: MCP does not change the model's reasoning process. The model still receives tool descriptions and must decide which tool is appropriate for the user's request. MCP simply standardizes how those tools are presented to the model and how the resulting data is fetched from the server.

It eliminates the latency associated with network-based API calls.

Why it fails: MCP is a communication protocol, and like any protocol, it introduces a small amount of overhead. While local Stdio transport is very fast, it does not eliminate the inherent latency of model processing or network requests if the MCP server itself is calling out to a remote database or API.

Repeat the entire JSON schema of every tool inside the system prompt.

Why it fails: Repeating the JSON schema in the system prompt is redundant and wastes tokens. The Anthropic API already sends the tool definitions to the model in a dedicated field. Redundant info can sometimes confuse the model or cause it to focus on the wrong details, leading to less reliable tool invocation.

Tell the model to ignore the tool descriptions and follow the prompt instead.

Why it fails: Instructing the model to ignore tool descriptions will likely break the integration. The tool descriptions contain the technical parameters necessary for the API call to function. If the model ignores them, it will likely generate malformed tool_use blocks that fail validation or lack the required arguments for the server.

Use the system prompt to provide the API keys needed to run the tools.

Why it fails: You should never put API keys or sensitive credentials in the system prompt. The model does not need these keys; the developer's local execution environment does. Exposing keys to the model increases the risk of 'prompt injection' where a user might trick the model into revealing the sensitive credentials.

Set the tool_choice type to 'auto' and include only one tool in the list.

Why it fails: The 'auto' setting allows the model to decide whether to use a tool or respond with text. Even if only one tool is provided, Claude may still choose to respond with a text message if it believes the tool is not relevant to the query, which fails the requirement of forcing usage.

Set the tool_choice type to 'any' to force the selection of at least one tool.

Why it fails: While the 'any' setting forces Claude to use at least one tool from the provided list, it does not guarantee that 'search_documentation' will be the one chosen if multiple tools are available. Since the requirement specifies a single specific tool, 'any' is less precise than using the 'tool' type.

Omit the 'description' field in the tool definition to prevent model confusion.

Why it fails: Omitting the description field is actually detrimental to tool use. Claude relies on the description to understand the purpose and parameters of the tool. Removing it would likely lead to poor argument generation or errors, as the model would lack the necessary context to populate the tool's input schema correctly.

The MCP Client is responsible for executing the Python code defined in the server.

Why it fails: The execution logic resides within the MCP Server itself. The client simply sends a request to the server to execute a tool with specific arguments. The server performs the work and returns the result. This separation allows the server to be written in any language and run in any environment.

MCP Servers must be hosted on public cloud infrastructure to be accessible.

Why it fails: MCP servers can run locally on a developer's machine using stdio for communication, or they can be hosted remotely. There is no requirement for public cloud hosting. This flexibility is a core design goal of MCP, enabling secure, local-first workflows where data never leaves the user's machine.

The MCP Client defines the JSON schema for all tools provided by the server.

Why it fails: The server defines the JSON schema for the tools it provides. When a client connects to a server, it 'discovers' these schemas. This ensures that the server remains the single source of truth for how its tools should be called, simplifying the development and maintenance of the client applications.

The stdio server must be started with the '--expose-tools' flag before Claude can invoke any tool it defines.

Why it fails: MCP stdio servers do not require an '--expose-tools' flag; tool exposure is governed by the server's declared capabilities and its tools/list response. Inventing a flag mischaracterizes the protocol. Even if the server exposes tools correctly, the client still has to relay those definitions to Claude in the API request. The absence of a required CLI flag is not a real MCP requirement and does not explain the observed behavior.

The 'tickets-mcp' server was configured with the 'resource' capability instead of the 'tools' capability, so 'get_ticket' is not advertised to Claude.

Why it fails: MCP capabilities are declared by the server during initialization, but a server that exposes a tool must declare the 'tools' capability and list 'get_ticket' in tools/list. Configuring 'resource' instead would hide it, yet the scenario says the schema is valid and the server starts; the more likely failure is that the tool is simply not passed to the model in the request. Capability mismatch would also typically produce a tools/list error rather than silent omission.

The 'get_ticket' tool description exceeds 1024 characters, causing Claude to silently ignore the tool during planning.

Why it fails: Tool descriptions have practical length guidance, but exceeding a soft limit does not cause silent omission of the tool from the model's context. Claude would still see the tool, though the description might be less effective. The scenario points to no tool_use at all, which is more consistent with the tool never being supplied in the request than with a verbose description. There is no documented silent-drop behavior tied to description length.

Append the tool results directly to the end of the previous assistant message.

Why it fails: Appending results to the assistant message violates the message structure of the Anthropic API. Assistant messages are reserved for the model's output only, and modifying them causes schema validation errors. The model expects the environment results to be provided in a subsequent message from the user role to maintain proper conversational flow.

Update the system prompt with the new weather data and restart the session.

Why it fails: Updating the system prompt and restarting the session is inefficient and loses the context of the current conversation. While system prompts provide instructions, they are not designed for the dynamic injection of tool outputs. This approach would force the model to re-process the entire interaction, significantly increasing latency and token costs.

Issue a second assistant message that includes the weather data as a JSON string.

Why it fails: The assistant role cannot be used to inject external data into the conversation history. Assistant messages are strictly for model-generated content. Providing external data as an assistant message would confuse the model's perception of what information it generated versus what information was provided by the external tool execution environment.

The MCP Host

Why it fails: The MCP Host is the application, such as Claude Desktop or an IDE, that initiates the connection and coordinates the interaction. While it consumes the resources, it does not provide them. Its primary job is to manage the user interface and the model's lifecycle while utilizing the protocol to talk to servers.

The MCP Client

Why it fails: The MCP Client is the implementation layer within the host application that handles the protocol communication logic. It establishes the 1:1 connection with a server but does not define the resources or tools itself. It acts as a bridge, translating the model's needs into protocol-compliant requests for the server to fulfill.

The MCP Gateway

Why it fails: An MCP Gateway is not a core architectural component of the Model Context Protocol. While network intermediaries might exist, the protocol specifically defines the interactions between Hosts, Clients, and Servers. Using non-standard terminology can lead to confusion when configuring production-grade MCP environments and troubleshooting connection issues between components.

Claude will trigger an API error because the state_code is missing from the required list.

Why it fails: The API will not error simply because a property is missing from the required list. If the user does not provide the info, Claude is technically allowed to call the tool with just the 'amount'. The error would only occur if the developer's underlying code cannot handle a null value for 'state_code'.

Claude will call the tool with a default state_code of 'CA'.

Why it fails: Claude does not invent default values unless they are explicitly defined in the JSON schema using the 'default' keyword. Without a default value, Claude will either omit the property or ask the user for the missing information to ensure the calculation is performed correctly for the specific context provided.

Claude will automatically extract the state from the user's IP address.

Why it fails: Claude does not have access to the user's IP address or other metadata unless it is explicitly provided in the conversation or system prompt. The model is isolated from the underlying network layer, meaning it cannot autonomously gather environmental data to fill in missing tool parameters without developer intervention.

The MCP Client sends a 'heartbeat' signal to automatically restart the server.

Why it fails: The MCP protocol itself does not define a mandatory heartbeat for Stdio-based transports. While a host might implement health checks, there is no built-in protocol-level mechanism that forces a restart. The connection is tied to the process lifecycle, and once the process ends, the transport layer is effectively dead.

The MCP Server uses a sidecar process to monitor its own health and restart.

Why it fails: While a developer could implement a sidecar, this is not a standard part of the MCP specification. MCP servers are designed to be lightweight. Managing their own lifecycle via a sidecar would add unnecessary complexity to the integration, especially since the host is already managing the server process.

The Model will identify the crash and suggest a fix to the developer.

Why it fails: The AI model (Claude) has no direct awareness of the underlying transport layer or the status of the server process. It only sees the messages passed to it by the Host. If a tool call fails because the server crashed, the model only knows that it didn't receive a result.

Return a 500 Internal Server Error to the Anthropic API request.

Why it fails: Returning a 500 error to the API request will terminate the entire session and prevent Claude from providing any feedback. This results in a poor user experience where the application simply breaks, rather than allowing the model to acknowledge the failure and suggest alternative actions or explain the problem.

Omit the 'tool_result' and send a new user message saying 'The tool failed'.

Why it fails: Omitting the 'tool_result' for a requested 'tool_use' block will cause a validation error from the Anthropic API. Every tool request generated by the model must have a corresponding result block in the subsequent message. Failing to provide this breaks the mandatory sequence of the tool use protocol.

Modify the assistant's previous tool_use block to remove the request.

Why it fails: Developers should never modify the model's previous output. The assistant's messages represent the model's actual thoughts and actions. Changing them retrospectively to hide a failure creates an inconsistent conversation history, which can confuse the model's future reasoning and lead to unpredictable behavior in the agent's logic.

The MCP Server is using an outdated version of the protocol.

Why it fails: While version mismatches can cause issues, they typically result in connection errors or schema validation failures rather than a specific 'Method not found' error. This error code specifically targets the absence of the requested function, suggesting the connection is active but the specific capability is missing from the server.

The path argument '/' is restricted by the server's security policy.

Why it fails: Security or permission errors usually return a different error code, such as -32000 or a custom error message indicating 'Permission Denied'. A 'Method not found' error occurs earlier in the request processing pipeline, before the server even attempts to validate the arguments or execute the underlying logic.

The model (Claude) generated a malformed JSON object for the arguments.

Why it fails: Malformed JSON would typically trigger a -32700 'Parse error' or -32602 'Invalid params' error. Since the log shows the request was successfully sent and the server responded with 'Method not found', it indicates the JSON structure was likely valid, but the tool name itself was the issue.

Execute the tool as soon as the 'name' property is received in the stream.

Why it fails: Executing a tool before receiving all arguments will lead to failures. The arguments are delivered incrementally in the stream, and a tool cannot function without its full input parameters. Developers must wait for the entire tool_use block to be finalized and the stream to signal completion before processing the call.

Wait for the 'message_stop' event before parsing any tool_use blocks.

Why it fails: While waiting for the end of the message is safe, it may introduce unnecessary delay. A message might contain both a tool call and text. A better approach is to watch for the completion of the specific tool_use block, which allows you to start execution while the rest of the message might still be streaming.

Streaming is not supported when using tools; use the synchronous API instead.

Why it fails: Streaming is fully supported for tool use and is often preferred for maintaining a responsive UI. The API sends 'tool_use' blocks as a specific type of content block within the stream. Developers just need to implement the logic to handle these non-text blocks alongside the standard text deltas.

Process each tool call sequentially to avoid race conditions in the model.

Why it fails: Sequential processing is unnecessarily slow. Since the model has already decided on all three tool calls, it is ready to receive all three results. Parallel execution takes advantage of modern asynchronous programming, significantly reducing the total 'wait time' for the user without negatively impacting the model's reasoning or logic.

Only execute the first tool call and ignore the others to prevent token bloat.

Why it fails: Ignoring tool calls that the model requested will lead to incomplete or incorrect answers. Claude expects a result for every tool it invokes. If results are missing, the model may become confused, repeat the request, or fail to provide the information the user originally asked for, ruining the integration's utility.

Ask the user to prioritize which of the three tools should be run first.

Why it fails: Asking the user for prioritization creates friction and defeats the purpose of an autonomous agent. The model has already determined that these three actions are necessary. The developer's role is to facilitate those actions as efficiently as possible, not to re-delegate the task of coordination back to the end user.

The server must use a unique API key for every tool call it receives.

Why it fails: While authentication is important, requiring a unique API key for every individual tool call is not a standard requirement of MCP and would add significant management overhead. Typically, authentication is handled at the transport or session level when the host first connects to the server.

The server must rotate its connection ID every sixty seconds for privacy.

Why it fails: Frequent rotation of connection IDs is not a feature or requirement of MCP and would likely cause instability in the host-server communication. The protocol relies on stable sessions to manage the state of resources and tools. Privacy is better handled through proper data masking and secure transport layers.

All MCP tool results must be manually approved by a human operator.

Why it fails: While 'human-in-the-loop' is a valid pattern for high-risk actions, it is not a mandatory security requirement for all MCP implementations. Forcing manual approval for every result would destroy the speed and utility of most AI agents. Security should instead be built into the server's logic and permissions.

Fine-tuning cannot be used to teach a model new factual information.

Why it fails: Fine-tuning can teach a model new information, but it is an inefficient way to do so for dynamic facts. The model's weights are updated, but the process is slow and the information can be hallucinated if not perfectly captured. Tool-calling is better because it retrieves the exact, current text from a source of truth.

Tool-calling is the only way to ensure Claude uses a professional tone.

Why it fails: Tone and persona are primarily controlled through the system prompt or fine-tuning, not through tool-calling. While a tool might provide professional content, the model's overall 'voice' is a result of its instructions. Tool-calling's main benefit is providing accurate data, not shaping the model's personality or conversational style.

Fine-tuned models are restricted from using tools for security reasons.

Why it fails: There is no inherent restriction preventing fine-tuned models from using tools. In fact, many advanced agents use fine-tuned models that are specifically optimized to call tools more accurately. The choice between fine-tuning and tool-calling is based on data volatility and cost, not on a technical incompatibility between the two.

MCP Client

Why it fails: The client acts as the orchestrator that initiates connections to various servers and manages the model's interaction loop. It does not define the internal logic of the tools or the direct connection to the database. Instead, it consumes the capabilities that are exposed by the server component during a session.

MCP Transport

Why it fails: Transport mechanisms, such as stdio or HTTP with Server-Sent Events, define how messages are moved between the client and the server. While essential for communication, the transport layer is agnostic to the actual content of the tools or the database queries being executed by the server-side implementation logic.

MCP Host

Why it fails: The host usually refers to the application, like Claude Desktop or a custom IDE, that integrates the MCP client functionality. While the host environment provides the user interface, it relies on the server to provide the actual tool definitions and the execution logic required to interact with the database.

It will fail with a validation error because 'unit' is missing.

Why it fails: Validation errors occur during the API request if the schema itself is malformed or if the model produces output that violates the schema. Since 'unit' is optional in this specific definition, the absence of the property is perfectly valid according to standard JSON Schema rules used by the Anthropic API.

It will prompt the user to choose between 'celsius' and 'fahrenheit' first.

Why it fails: While Claude might ask for clarification in a conversational context, if it decides to use a tool and the missing parameter is not required, it will proceed with the tool call using only the available required information. This maintains the flow of execution without unnecessary conversational interruptions for optional tool data.

It will default the 'unit' to 'celsius' automatically.

Why it fails: Claude does not automatically provide default values for optional parameters unless a default is explicitly defined in the JSON schema or instructed in the system prompt. Without an explicit 'default' keyword in the schema, the model will simply leave the optional field out of the generated tool use block.