A client sends `initialize` proposing `protocolVersion: "2025-11-05"`. The server replies with `protocolVersion: "2024-11-01"`, a version the client does not recognize. The client continues the session and sends `tools/list`.
The client must abort: when the server returns a protocolVersion the client does not support, the spec says close the transport and report incompatibility. Sending tools/list anyway is the bug.
Imagine two people agreeing on a language before a meeting. You say, 'Let's use English-2025.' The other person replies, 'I only speak English-2024,' a dialect you have never learned. The safe move is to stop and say 'we are not compatible,' then hang up. The dangerous move is to keep talking anyway, guessing at words, hoping the meaning carries. You might get lucky on simple sentences and then completely misunderstand an important one. MCP version negotiation works the same way. The client proposes a version, the server answers with the version it will actually use, and if the client does not recognize that answer it should disconnect rather than push forward and risk silent misunderstandings later in the conversation.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
This is a predict the behavior question about the MCP connection lifecycle, specifically the version-negotiation step inside initialize. The scenario hands you a client that proposes 2025-11-05, a server that answers with the unfamiliar 2024-11-01, and then a client that blithely sends tools/list anyway. Your job is to predict what a correct client should do, and to recognize that the behavior shown is the bug.
The short answer is that the client must abort: close the transport and report a version incompatibility. The interesting part is why this is a hard rule rather than a soft preference, and what specifically goes wrong if you let the session limp forward. Interviewers reach for this scenario because it separates people who have only read the marketing description of MCP from people who have actually implemented or debugged a client. The marketing view treats MCP as a friendly plug and play layer; the implementer's view knows that plug and play only holds once both sides agree on a contract.
This deep dive walks the lifecycle, explains why the server's returned version is authoritative, defines capability decay precisely, and then shows the runtime and security failure modes that the abort rule is designed to prevent. By the end you should be able to defend the abort answer from first principles rather than by quoting a spec line.
The initialize handshake and what gets negotiated
Every MCP session opens with an initialize request from the client. That request carries the client's proposed protocolVersion, its capabilities, and clientInfo. The server replies with an initialize result containing the protocolVersion it will actually use, its own capabilities, and serverInfo. After the client accepts, it sends an initialized notification and normal operation begins.
The version field is a date string like 2025-11-05, not a semantic-version triple. Each value names a complete, frozen revision of the spec: which methods exist, what their parameters look like, and which capability flags are defined. So a version is really a pointer to an entire contract, not a feature toggle.
The critical property: the version exchange is one round. The client proposes, the server decides, and the client then either accepts the decision or disconnects. There is no back and forth where the two sides whittle down to a common version over several messages. That single-round design is exactly why the abort rule has to be strict; there is no second chance to renegotiate inside the same connection.
It also helps to separate two things that share the same handshake. Version negotiation settles which revision of the spec governs the wire. Capability negotiation, carried in the capabilities objects, settles which optional features each side will use within that revision. They are distinct gates. You can only meaningfully read the capabilities once you trust the version, because the shape and meaning of those capability flags is itself defined by the version. That ordering is why a version failure is fatal and cannot be salvaged by inspecting capabilities.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Behavior | Abort on unrecognized version (correct) | Continue and send tools/list (the bug) |
|---|---|---|
| When the mismatch surfaces | Immediately at the initialize handshake | Later, at some runtime call |
| Failure shape | One loud, clear incompatibility error | Scattered errors or silent semantic drift |
| Security posture | No assumptions made on an unverified contract | May assume guarantees the old version never gave |
| Debuggability | Single obvious failure point | Hard to trace, looks like a tool bug |
Real products, models, and research that use this idea.
- The official MCP TypeScript and Python SDKs reject an initialize response whose protocolVersion is not in the client's supported set, closing the transport.
- Claude Code and Cursor pin the protocol versions their MCP clients accept, so a server advertising an unknown date fails fast at connection rather than mid-session.
What an interviewer would ask next. Try answering before peeking at the approach.
QIf the server returns a version the client DOES support but the client proposed a newer one, what happens?
The server's returned version wins. The client downgrades to that version for the session, provided it is in the client's supported set; no renegotiation occurs.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Assuming the session continues on a best-effort basis. An unrecognized version is a hard stop, not a soft fallback the client can paper over with optimistic calls.
60 second bullets to scan on the way to the call.
What the initialize request proposes and what the server response decides
Who is authoritative on the final protocol version
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.