MCP Interview Questions and Answers: 32 Questions Checked Against the Spec (Nov 2026)

These are the MCP (Model Context Protocol) questions interviewers ask most, with short answers you can say out loud. Every answer is checked against the current spec, version 2026-07-28. That version changed a lot (no more initialize handshake, no sessions), so we flag where a 2025-era answer is now wrong.

Each answer is two to five sentences: enough to show you understand it, short enough to say in an interview. Follow the links when an interviewer digs deeper. The questions are numbered so you can track how far you've got.

MCP basics (questions 1-6)

1. What is MCP?

MCP is an open protocol that lets AI apps connect to outside tools and data in one standard way. The spec calls it "an open protocol that enables seamless integration between LLM applications and external data sources and tools." An MCP server offers tools, resources and prompts; an AI app such as Claude, Cursor or VS Code connects to it and lets the model use them. Longer version: what is an MCP server.

2. What problem does MCP solve?

Before MCP, every AI app needed its own connector for every service. With one protocol, a service writes one MCP server and every MCP-capable app can use it, and an app that speaks MCP can use any server. The spec compares it to the Language Server Protocol, which did the same for code editors and programming languages.

3. What are hosts, clients and servers?

• Host: the AI application the user runs (Claude Desktop, Claude Code, an IDE).
• Client: the connector inside the host. Each client talks to one server.
• Server: the program that offers tools, resources and prompts.

A good follow-up point: the host decides what the model sees and asks the user before a tool runs. See hosts, clients and servers.

4. Who created MCP, and who runs it now?

Anthropic open-sourced MCP on November 25, 2024. On December 9, 2025, Anthropic donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. It is no longer a single-vendor standard.

5. How is MCP different from a REST API or function calling?

An API is how one program calls a service. Function calling is how a model asks its own app to run a function. MCP sits between them: it is a standard way for any AI app to discover tools at runtime (tools/list) and call them (tools/call), so the tools don't have to be hard-coded into each app. Many MCP servers are thin wrappers around an existing API. Full comparison: MCP vs API.

6. Which version of the spec is current, and how are versions named?

Versions are named by date. The current one is 2026-07-28. The earlier ones are 2024-11-05, 2025-03-26, 2025-06-18 and 2025-11-25. Saying the version you are quoting is a good habit, because the answers to questions 8, 10 and 15 changed in 2026-07-28.

Messages and architecture (questions 7-11)

7. What message format does MCP use?

JSON-RPC 2.0, encoded as UTF-8. There are three kinds of message: requests (have an id and expect a reply), responses (carry the same id with a result or an error), and notifications (no id, no reply). Errors use JSON-RPC codes such as -32601 (method not found) and -32602 (invalid params). See MCP error codes.

8. How does a client connect to a server? Is there a handshake?

In the current spec, no. The spec now says MCP uses "stateless, self-contained requests." Each request carries its protocol version and client capabilities in _meta, and a server must implement server/discover so a client can ask up front which versions and features it supports.

The 2025-era answer was the initialize request, the server's reply, then a notifications/initialized notification. That handshake was removed in 2026-07-28. Current clients can still fall back to it when they meet an older server.

Here is what a current tools/call request looks like, from the spec's Streamable HTTP page:

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_weather",
    "arguments": { "location": "Seattle, WA" },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "ExampleClient", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

9. What can an MCP server offer?

Three things, sorted by who controls them:

Primitive	Who controls it	Example
Tools	The model decides when to call them	Run a query, create an issue
Resources	The app or user attaches them as context	A file, a database schema
Prompts	The user picks them	A slash command

More in MCP resources vs tools.

10. What can a client offer to a server?

In 2026-07-28 the spec lists one client feature: elicitation, where the server asks the user for more information (a form, or a link to open). Roots (which folders the server may use) and sampling (the server asking the client's model for a completion) still work but are deprecated, so new code shouldn't add them. The spec suggests passing folders as tool parameters or config instead of roots, and calling an LLM API directly instead of sampling.

11. If the server can't send requests, how does it ask the user something?

With multi round-trip requests. The server answers a tools/call with a result whose resultType is "input_required" and lists what it needs (for example an elicitation/create form). The client collects the answer and sends the original request again with inputResponses. In older versions the server sent its own request to the client instead.

Transports (questions 12-15)

12. What transports does MCP define?

Two standard ones:

• stdio: the client starts the server as a subprocess and they exchange newline-delimited JSON-RPC over stdin and stdout. Used for local servers.
• Streamable HTTP: each message is an HTTP POST to one endpoint (such as https://example.com/mcp). The reply is a single JSON object or an SSE stream for that request. Used for remote servers.

Custom transports are allowed if they keep the JSON-RPC format. See local vs remote MCP servers.

13. Why does a stdio server break when it prints a log line?

Because stdout is the message channel. The spec says the server "MUST NOT write anything to its stdout that is not a valid MCP message." A stray print() corrupts the stream and the client fails with a parse error or "connection closed". Logs go to stderr. This is the most common bug in first-time servers, so it is a favourite practical question.

14. What is the difference between Streamable HTTP and HTTP+SSE?

HTTP+SSE was the 2024-11-05 transport: one endpoint to POST messages and a separate long-lived SSE stream for replies. Streamable HTTP replaced it in 2025-03-26 with a single endpoint. HTTP+SSE is now formally deprecated, and new code should not use it.

15. Does Streamable HTTP have sessions?

Not any more. From 2025-03-26 to 2025-11-25 a server could assign a session with the Mcp-Session-Id header. 2026-07-28 removed protocol-level sessions, the GET stream and stream resumption. A server that needs state across calls returns an explicit handle (say, a basket_id) from one tool and accepts it as an argument on the next. Change notifications now come through one long-lived subscriptions/listen request.

Tools, resources and prompts (questions 16-20)

16. When would you expose data as a resource instead of a tool?

When it is something to read rather than something to do. A resource is attached by the app or user, so the model doesn't decide to fetch it. A tool is for actions, or for reads the model should choose to make. Rule of thumb: anything that writes, sends or deletes is a tool and needs user approval. More: MCP resources vs tools.

17. What is in a tool definition?

A name, an optional title, a description, an inputSchema (JSON Schema, 2020-12 by default), an optional outputSchema and optional annotations. If a tool has an outputSchema, the server MUST return structuredContent that matches it. The description is what the model reads to decide when to use the tool, so it matters as much as the code.

18. How should a tool report an error?

There are two kinds. Protocol errors (unknown tool, malformed request) are JSON-RPC errors. Tool execution errors (bad date, API failure) go back as a normal result with isError: true, because the spec says they contain "actionable feedback that language models can use to self-correct." Explaining why the second kind goes to the model is what interviewers listen for. See MCP tool errors.

19. Can a client trust tool annotations like readOnlyHint?

No. The spec says clients "MUST consider tool annotations to be untrusted unless they come from trusted servers." An annotation is the server describing itself. A malicious or buggy server can mark a delete tool as read-only. Details: MCP tool annotations.

20. Why is connecting too many tools a problem?

Every tool's name, description and schema is sent to the model, so 100 tools can use a large share of the context window before the user types anything. More tools also means more chances for the model to pick the wrong one, and a bigger attack surface. See MCP tools context cost.

Authentication and authorization (questions 21-24)

21. Is authorization required in MCP?

No, it is optional. When an HTTP server uses it, it SHOULD follow the spec's OAuth 2.1 profile, where the MCP server is the resource server. A stdio server SHOULD NOT use that flow and should "retrieve credentials from the environment" instead, which in practice means an API key in an environment variable.

22. Walk me through the MCP OAuth flow.

1. The client calls the server without a token and gets 401 with a WWW-Authenticate header pointing to the server's protected resource metadata (RFC 9728).
2. The client reads that metadata to find the authorization server, then reads the authorization server's own metadata.
3. The client gets a client ID (a Client ID Metadata Document, a pre-registered ID, or the deprecated dynamic registration).
4. The user signs in in a browser. The client uses PKCE and sends a resource parameter naming the MCP server (RFC 8707).
5. The client swaps the code for a token and sends it as Authorization: Bearer ... on every request.

Step by step with diagrams: MCP authentication.

23. What is token passthrough, and why is it banned?

Token passthrough is a server accepting a token meant for something else and forwarding it to another API. The spec says servers MUST check that a token was issued for them and "MUST NOT accept or transit any other tokens." Otherwise a stolen token works in places it was never meant for, and the server's logs and limits no longer show who really made the call.

24. Client ID Metadata Documents or Dynamic Client Registration?

Client ID Metadata Documents. The client uses an HTTPS URL as its client ID, and the authorization server fetches the client's details from it. Dynamic Client Registration is deprecated in 2026-07-28 and kept only for authorization servers that don't support metadata documents yet. What else changed: the 2026-07-28 auth changes.

Security (questions 25-28)

25. What are the main security risks of MCP servers?

• Prompt injection: text in a web page, issue or email that the model reads and obeys.
• Tool poisoning: hidden instructions in a tool's own description.
• Rug pulls: a server that changes its tools after you approved it.
• Over-broad access: a token or folder with far more rights than the job needs.
• Exposed local servers: an HTTP server on 0.0.0.0 with no auth.

The spec itself says "tools represent arbitrary code execution and must be treated with appropriate caution." Full list: why MCP servers are a security risk and the OWASP-style MCP top 10.

26. What is the lethal trifecta?

Simon Willison's test for data theft. An agent is at risk when one session has all three: access to private data, exposure to untrusted content, and a way to send data out. The fix is to break at least one leg per session, for example by not mixing a public-issue reader with a tool that can post to the web. See the lethal trifecta.

27. How do you secure an MCP server that runs on localhost over HTTP?

The spec's three rules for Streamable HTTP: validate the Origin header on every connection (to stop DNS rebinding), bind to 127.0.0.1 rather than 0.0.0.0 when running locally, and authenticate every connection. Mention DNS rebinding by name: it is how a website you visit can reach a server you think is private. See MCP DNS rebinding.

28. How would you check a third-party MCP server before installing it?

Check who publishes it, read its tool list and descriptions, look for known CVEs, give it the smallest token that works, keep "ask before running a tool" on, and pin the version so it can't change under you. Our 5-minute security checklist covers each step, and every server in our directory has a trust grade built from the same checks.

Building and debugging servers (questions 29-32)

29. How would you build and test a simple MCP server?

Use an official SDK (Python and TypeScript are the most common), register one tool with a clear description and an input schema, and run it over stdio. Then open it in the MCP Inspector to list the tools and call one by hand before connecting it to Claude or Cursor. Walkthrough: build a secure MCP server.

30. A server shows "0 tools" or "connection closed". How do you debug it?

Work outward: run the start command by hand and read stderr; check the server isn't writing logs to stdout; check tools/list in the Inspector; then check sign-in and timeouts. Error -32000 "Connection closed" usually means the server process exited. Full checklist: MCP server not working.

31. How do you keep state between tool calls without sessions?

Return a handle from a "create" tool and take it as an argument on later calls, as in question 15. The spec's guidance: treat the handle as a name, not a permission (check the caller's rights on every call), make it opaque (and hard to guess if the server has no sign-in), say how long it lives in the tool description, and return a clear tool error when it has expired so the model can start again.

32. Design question: how would you expose our internal API through MCP?

A strong answer covers five points:

1. Pick a few tasks, not every endpoint. A small set of well-described tools beats 80 generated ones.
2. Remote over Streamable HTTP with OAuth, so each user acts with their own rights and you never share one key.
3. Read-only by default. Put writes in separate tools that need approval.
4. Clear errors with isError: true so the model can recover.
5. Logs and a gateway if many teams will use it. See MCP gateway.

If you're hiring someone to build this, or want it built for you, tell us what it should connect to.

Frequently asked questions

Which MCP spec version should I quote in an interview?

Quote 2026-07-28, the current version, and say so. If the interviewer learned MCP in 2025, they may expect the initialize handshake and Mcp-Session-Id sessions. Explain both: what the old version did and what replaced it. That shows you follow the spec, not a year-old tutorial.

Do I need to know the MCP spec in detail for an AI engineer role?

Usually not line by line. Interviewers mostly check that you understand the pieces (host, client, server, tools, resources, transports), how auth works for remote servers, and the security risks. Building one small server and testing it in the MCP Inspector teaches most of what gets asked.

What MCP questions come up for security roles?

Expect prompt injection, tool poisoning, rug pulls, token passthrough, DNS rebinding on local servers, and how you would review a third-party server. Questions 23 and 25-28 cover these, and our MCP security best practices checklist goes further.

Where can I practise with real MCP servers?

Pick a well-known server from our directory, read its tool list and trust grade, and connect it to a client you already use. Reading why a server lost points on its grade is good practice for the "how would you vet this server" question.