What happens during the MCP initialize handshake, and why does it matter?

Flashcard·Easy·4.0 · 0·~30s·Relevant atAnthropic

Attempt it

The client sends an initialize request with its protocol version and a capabilities object listing features it supports. The server responds with its own protocol version and capabilities object. The client then sends notifications/initialized to confirm. From that point, each side only calls features the other advertised. This mutual opt-in lets MCP evolve without breaking older peers.

Your answer

**Capability negotiation** is the feature exchange that happens at the very start of every MCP session, inside the `initialize` handshake. The flow has three messages. First, the client sends an `initialize` request containing its protocol version, client info (name and version), and a `capabilities` object listing the optional features it supports. Second, the server responds with the agreed protocol version, its own server info, and its own `capabilities` object. Third, the client sends a `notifications/initialized` notification to signal it has read the response and the session is open. The server's capabilities might include keys like `tools`, `resources`, `prompts`, `logging`, and `completions`. The client's capabilities might include `roots`, `sampling`, and `elicitation`. Each key is opt-in: if a server does not implement resources, it omits that key entirely. Once the exchange finishes, both sides know the intersection of supported features. The client will not call `resources/list` against a server that did not advertise resources. The server will not issue a `sampling/createMessage` request to a client that did not advertise sampling. This mutual agreement is what makes MCP forward compatible: new features are invisible to peers that never advertised them, so nothing breaks.

**Capability negotiation** is the feature detection step inside MCP's `initialize` handshake. Both sides declare what they support, and from that point on each side calls only features the other advertised. The sequence is three messages. The client sends `initialize` with its protocol version (a date string like `"2026-03-26"`), client info, and a `capabilities` object. The server replies with the agreed protocol version, server info, and its own capabilities. The client then fires a `notifications/initialized` notification, and the session is open. Server capabilities in the 2026 spec commonly include `tools` (callable functions, with an optional `listChanged` sub-flag), `resources` (readable data identified by URI, with optional `subscribe` and `listChanged`), `prompts` (user-invoked templates), `logging` (structured log emissions), and `completions` (argument autocompletion). Client capabilities commonly include `roots` (workspace directory hints), `sampling` (the client can run LLM completions on the server's behalf), and `elicitation` (the client can prompt the user for input mid-call). This matters because MCP is a living spec. Features ship every few months. Without negotiation, every addition would break older peers. With negotiation, a 2026 server talking to a 2024 client degrades gracefully to the shared feature set. The intersection of advertised capabilities is always a valid working subset. The practical debugging note: when a feature is not working, the first check is always the initialize trace. If either side did not advertise the capability, no downstream fix will help.

Quick reference

TL;DR

During initialize, client and server each declare supported features via a capabilities object; both sides then stick to the intersection, enabling forward compatibility.

Memory aid

Easy to grasp

Imagine two kids meeting at a playground for the first time. Before they start playing, each one says which games they know: 'I know tag, hide and seek, and kickball.' The other says 'I know tag and freeze dance.' They agree to play tag because both listed it. Neither suggests a game the other never learned. MCP works the same way. When a client and server first connect, each sends a short list of features it supports. From then on, both stick to only the features they share. If the server later learns a new trick, older clients that never listed it simply ignore it. Nobody breaks. Nobody gets confused.

Key concepts

Capability Negotiation Initialize Handshake Feature Detection Forward Compatibility

Detailed answer & concept explanation

~4 min read

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.

Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.

Quick scan · 2–4 min

Everything important, quickly.

4 min: walk the three-message initialize sequence, list common server and client capabilities with sub-flags, explain forward compatibility via mutual opt-in, and close with the debugging heuristic of checking the initialize trace first.

Real-world examples

Real products, models, and research that use this idea.

Claude Desktop announces `roots` and `sampling` client capabilities; servers configured in the desktop config can rely on Claude to surface roots and accept sampling requests.
A simple search MCP server advertises only `tools`; the client never attempts `resources/list` against it because the resources capability is absent.
When a new spec revision adds a capability (e.g., a hypothetical `samplingV2`), older clients that never advertise it keep working because the server sees no flag and never calls it.
MCP Inspector prominently displays the initialize exchange so developers can verify which capabilities each side advertised before debugging downstream calls.

Interviewer follow-ups

What an interviewer would ask next. Try answering before peeking at the approach.

QWhat should a client do if it attempts to call a feature the server did not advertise?

QHow does capability negotiation interact with protocol version?

QWhat happens when a server's tool list changes mid-session?

Don't say this

Red flags and common mistakes that signal junior thinking. Click to expand.

Most common mistake

Assuming every MCP server supports every feature. Servers advertise only what they implement, and the client must check before calling anything beyond initialize.

60-second cheat sheet

The night-before-the-interview bullets. Scan these on the way to the call.

References

Primary sources. Skim if you want the original framing.