In this article
Before you start
Why interviewers ask this
A candidate who can say "MCP connects LLMs to tools" but cannot say who runs the tool, where the schema comes from, or what happens on failure has read a headline. Questions about MCP fit agent and GenAI system design rounds, alongside the agentic AI interview questions: "what is MCP and how does it differ from function calling", "how do you design good tools for an agent", and "how does the model choose a tool". Each one leads naturally into tool errors and safety.
A weak answer describes a plug standard. A strong answer separates the model's choice from the protocol's plumbing, and puts a person in the loop for risky calls.
The Model Context Protocol from first principles
In plain words
- Model Context Protocol
- The Model Context Protocol is an open protocol that standardizes how AI applications discover and use external tools, data and prompt templates, using JSON-RPC 2.0 messages between a client and a server.
- Tool use
- Tool use, also called function calling, is a model capability in which the model replies with a structured request naming a function and its arguments, alone or beside text, which the application runs and answers.
- MCP server
- An MCP server is a program, local or remote, that exposes tools, resources or prompts to an AI application through MCP, and that runs the operation when a tool is called.
- Tool schema
- A tool schema is the description of one tool: its name, a plain-language description and a JSON Schema for its arguments, which together tell the model what the tool does and how to call it.
Think of one agreed standard for power sockets. Without it, a device needs a different plug for every kind of socket. With it, a device maker builds a single plug and a socket maker builds a single socket.
The analogy breaks at the electricity. A power plug carries identical current, while MCP carries meaning, so a tool's description matters as much as its wiring.
In one precise sentence, MCP is a shared language for listing and calling tools, so applications and tool servers can be built independently.
Step 1: A host runs one client per server
MCP separates three roles: the host, the clients and the servers. The specification's architecture page (revision 2026-07-28) describes the host as the application that creates client instances and enforces consent and security policy, a client as a connector that talks to exactly one server, and a server as a program that exposes resources, tools and prompts. The overview adds that messages use JSON-RPC 2.0, a plain-text request and response format.
The count shows why a standard helps, and it counts integrations to build, not connections at run time. Five applications and eight tool servers need 5 times 8, or 40, integrations when each pair is wired by hand, and 5 plus 8, or 13, with a shared protocol: each application implements the client side once and each tool provider implements the server side once1. At 10 applications and 20 servers it is 200 against 30. At run time each host still runs one client per server it uses; the saving is in code written, not connections.
MCP servers offer three primitives, and the server features overview says who controls each. Prompts are user-controlled templates, such as slash commands. Resources are application-controlled context, such as file contents. Tools are model-controlled functions that take actions. A client can also offer elicitation, a request for more information from the user, which a server asks for through an InputRequiredResult inside its reply; the older sampling and roots client features are deprecated in this revision.
Messages travel over one of two standard transports: stdio, newline-delimited messages to a subprocess the client launches, which suits local servers, and a web transport over the Hypertext Transfer Protocol (HTTP) called Streamable HTTP, where each message is its own request to one endpoint, which suits remote servers and uses the HTTP authorization framework. The rest of this page follows the tools primitive, because it is the one the model chooses.
The input is a set of applications and tool providers. The output is one client per host-and-server pair at run time, with the host in control.
Step 2: The model picks a tool from its description
The model chooses a tool by reading the tool schemas the client listed, so the description and argument names are the real interface. In MCP the client asks for the list with a tools/list request, and each entry has a name, a description and an inputSchema, per the tools page of the specification. Anthropic's tool use overview says the model decides when to call a tool from the user's request and the tool's description.
The cost of listing is context. A single small definition measured 223 characters as compact JSON, so 20 tools take 4,460 characters and 100 tools take 22,3001. At about four characters per token, an illustrative rule of thumb, that is roughly 1,115 and 5,575 tokens spent before the user says anything.
The real cost is a little different: the host converts MCP definitions into the model API's format, and Anthropic's overview lists a tool-use system prompt of 286 tokens (automatic tool choice) on top of the definitions, so treat 223 characters as an approximation. For large tool sets the same overview offers a tool search tool that loads definitions on demand. Vague descriptions cause wrong picks, and too many tools cause both cost and confusion; a description is a small prompt, so the habits in the prompting hub apply.
The input is a list of schemas and a user request. The output is the model's choice of one tool and its arguments.
Step 3: The client calls the tool and returns the result
When the model names a tool, the client sends a tools/call request to the right server, and the server runs the operation and returns a result. The specification marks tools as model-controlled but says there should always be a human in the loop with the ability to deny tool invocations, so applications are expected to show which tools are exposed and confirm risky calls.
The messages are small, but not tiny, because every request is self-contained. MCP revision 2026-07-28 is stateless: per the base protocol page, every request carries its protocol version and client capabilities in _meta, so there is no handshake or session, and a request missing a required field is malformed and rejected with error -32602. A minimal conforming tools/call for the weather in New York was 227 characters, or 308 with the recommended clientInfo, and a short result 1321.
Specification examples omit _meta for brevity. A result can carry text, images, resource links or a structured value matched to an optional output schema. The same pattern exists in the model vendor's own API, where the application runs the function and returns a tool_result, so MCP and function calling are layers of one stack: function calling is how a model asks, and MCP is how an application finds and reaches the tools.
The input is the chosen tool and arguments. The output is a result the model reads to continue.
Step 4: Errors come back as results the model can fix
MCP splits failures into two kinds, and the split is the design point. Per the tools page, error handling, protocol errors, such as an unknown tool, a malformed request or a server error, come back as standard JSON-RPC errors, which models are less likely to fix, and clients may pass them to the model. Tool execution errors, such as an invalid date or a failed upstream call, come back as an ordinary result with isError set to true and a readable message, and clients should pass them to the model, so it can correct its arguments and try again.
Retries help only up to a point. If each attempt fails independently with probability 0.3, which is an illustrative assumption, success is 0.7 on one attempt, 0.91 on two and 0.973 on three1. Real failures are correlated, since a wrong argument tends to stay wrong, so the message must say what to change. Retry automatically only calls that are safe to repeat, meaning read-only or idempotent ones: a side-effecting call that timed out may already have run, so it needs an idempotency key or a person's approval first.
Step-by-step description
- A host runs one client per server.
- The client lists tools and the model picks one from its description.
- The client calls it and returns the result.
- Execution errors return as results the model can fix.
- Five applications and eight tool servers need 40 integrations to build by hand, or 13 with a shared protocol; at run time each host still runs one client per server.
- A small tool definition measured 223 characters, so 20 tools take 4,460 characters.
- A minimal conforming tools/call was 227 characters (308 with clientInfo) because every request carries its protocol version and client capabilities in _meta; a short result was 132.
- Execution errors return a normal result with isError set to true.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
| Applications | Tool servers | Integrations to build, by hand | With a shared protocol |
|---|---|---|---|
| 3 | 4 | 12 | 7 |
| 5 | 8 | 40 | 13 |
| 10 | 20 | 200 | 30 |
The hand-wired column is applications times servers and the shared column is applications plus servers1.
Text description of the diagram
- Five applications and eight tool servers need 40 integrations to build by hand, or 13 with a shared protocol.
- At 10 applications and 20 servers it is 200 against 30.
- At run time each host still runs one client per server it uses; the saving is in code written, not connections.
| Fact | Value |
|---|---|
| Message format | JSON-RPC 2.0 |
| List tools | tools/list request |
| Call a tool | tools/call request |
| Tool definition fields | name, description, input schema (plus optional title, icons, output schema, annotations) |
| Execution error signal | isError: true in a normal result |
Required per-request _meta | protocolVersion, clientCapabilities |
Minimal conforming tools/call | 227 characters |
| One small tool definition | 223 characters |
| 20 such definitions | 4,460 characters |
A walk-through shows the whole loop. A user asks for the weather in New York. The client has already listed a get_weather tool with one required location argument. The model returns a call with location set to "New York". The client sends tools/call, carrying its version and capabilities in _meta, to the server, which returns the text result. If the model had sent a malformed date to a different tool, the result would carry isError: true and a message saying which field to fix.
Trade-offs and edge cases
MCP trades a little overhead for reuse, and it moves some risks rather than removing them. The overview states the principle: tools represent arbitrary code execution, so hosts must obtain explicit user consent before invoking one.
Text description of the diagram
- Protocol errors, such as an unknown tool, a malformed request or a server error, come back as standard JSON-RPC errors, which models are less likely to fix, and clients may pass them to the model.
- Tool execution errors come back as an ordinary result with isError set to true and a readable message, and clients should pass them to the model.
- Context cost. Every listed tool costs tokens on every request, as the sizes above show, so expose the few tools a task needs.
- Trust. A tool description is text the model reads, so a hostile server can try to steer it; the overview says descriptions of tool behavior such as annotations should be considered untrusted unless obtained from a trusted server.
- State. The revision is stateless, with no protocol-level session, so a server that must remember something, such as a basket, returns an explicit handle that the model carries into later calls.
- Spec drift. The revision read here is 2026-07-28, and the specification is versioned, so state the revision you mean when you answer. Articles written against another revision may describe a different connection flow.
For agent design more broadly, see the AI agents hub and the human-in-the-loop page on approval steps.
How to answer it in an interview
What is MCP, and how does a model decide which tool to call?
I describe MCP as an open protocol, built on JSON-RPC, that standardizes how AI applications discover and call tools, so a tool server is written once and works in any host. A host runs one client per server, over stdio for local servers or Streamable HTTP for remote ones. Servers offer prompts, resources and tools, and tools are the model-controlled kind. The client lists tools with names, descriptions and argument schemas, and the model picks one from those descriptions, so descriptions are the real interface. The client then calls it and returns the result. Execution errors come back as readable results so the model can fix its arguments, and a human approves risky calls.
The spoken structure is: define the protocol, name the three roles, say the model chooses from descriptions, then cover errors and safety.
Common mistakes
- "MCP is how the model decides which tool to use" (wrong). The model decides from the tool descriptions; MCP only lists and calls (right: separate the choice from the plumbing).
- "MCP replaces function calling" (wrong). Function calling is how the model asks for a call; MCP is how the application finds and reaches tools (right: they work together).
- "More tools make the agent more capable" (wrong). Every definition costs context and adds ways to pick wrongly (right: expose a small, well-described set).
- "Return an HTTP error when a tool fails" (wrong). A model-fixable failure belongs in a normal result with the error flag set (right: reserve protocol errors for bad requests).
- "Tool outputs are safe to trust" (wrong). They are text from another program (right: validate and sanitize before the model acts on them).
Follow-up questions
What transports does MCP use?
Two standard ones. Stdio runs a local server as a subprocess the client launches and exchanges newline-delimited messages over its standard streams. Streamable HTTP sends each message as its own HTTP request to one endpoint and suits remote servers, with the HTTP authorization framework for access control. Message meaning is identical on both.
When to use MCP vs RAG?
Use retrieval-augmented generation when the need is to fetch relevant text into the prompt, and MCP when the application must reach many external tools and data sources through one interface. They combine: a retriever can be exposed as an MCP tool, as the embeddings and vector search hub's retrieval pipeline could be.
How does an LLM decide which tool to use?
It reads the tool names, descriptions and argument schemas in its context together with the user request, and outputs a structured call for the best match. Anthropic's overview says the choice follows the request and the tool's description, which is why wording the description clearly is the first fix for wrong picks.
What is tool use in an LLM?
Tool use is the model replying with a structured request for a function, alone or beside text. Your application runs the function and sends back the result, and the model continues; the AI agents hub shows how repeated calls form an agent loop.
What is function calling in an LLM, and how is it different from MCP?
Function calling is the model-side feature of emitting a structured call. MCP is the application-side protocol for discovering and invoking tools, so one MCP server can serve any host whose model supports function calling.
How should an agent recover from tool errors?
Return a readable message that says what was wrong and what to change, let the model retry a small number of times, and stop with a clear failure after that. Retry automatically only read-only or idempotent calls; a side-effecting call needs an idempotency key or a person's approval. Log every call so the failure can be traced, as the LLM observability page describes.
- MCP is an open JSON-RPC protocol for listing and calling tools, so each tool server is written once.
- A host runs one client per server; a shared protocol cuts the integrations to build, not the run-time connections.
- Servers offer prompts (user-controlled), resources (application-controlled) and tools (model-controlled), over stdio or Streamable HTTP.
- The model picks a tool from its description, so descriptions and schemas are the real interface.
- Execution errors return as readable results with an error flag; protocol errors are for malformed requests.
- Keep a human in the loop for risky calls, treat tool text as untrusted and expose few tools.
Sources
- Model Context Protocol specification, revision 2026-07-28 (overview) — Model Context Protocol project (revision date; read 2026-10-24), 28 Jul 2026
- MCP specification 2026-07-28: Architecture — Model Context Protocol project (revision date; read 2026-10-24), 28 Jul 2026
- MCP specification 2026-07-28: Server features, Tools — Model Context Protocol project (revision date; read 2026-10-24), 28 Jul 2026
- MCP specification 2026-07-28: Base protocol (statelessness, _meta) — Model Context Protocol project (revision date; read 2026-10-24), 28 Jul 2026
- MCP specification 2026-07-28: Server features overview (primitives and who controls each) — Model Context Protocol project (revision date; read 2026-10-24), 28 Jul 2026
- MCP specification 2026-07-28: Transports (stdio and Streamable HTTP) — Model Context Protocol project (revision date; read 2026-10-24), 28 Jul 2026
- MCP specification 2026-07-28: Deprecated features — Model Context Protocol project (revision date; read 2026-10-24), 28 Jul 2026
- Tool use with Claude (overview) — Anthropic (page undated; read 2026-10-24), 24 Oct 2026
