Does an MCP server check the protocol-version header?

Sample taken 2026-09-27, from the anonymous probe tools/survey-mcp-protocol-version-header.mjs 40.

The 2025-06-18 revision of MCP says a client MUST put MCP-Protocol-Version on every HTTP request after initialize, and that a server SHOULD reject a request whose header names a revision it did not agree to. Two questions follow, and they have different answers:

1. Do public servers enforce it? In this sample: no, none of them.
2. Did our own gateway send it? No — and that second one was a defect regardless of the first.

What the sample says

Of 40 streamable-http endpoints taken from the official MCP registry in its default order:

• auth_required: 22
• accepts_anything_we_tried: 16
• init_failed_400: 1
• init_failed_502: 1

16 servers completed the handshake. For each, the same tools/list request was sent twice, differing by exactly one header — once naming the revision the server had answered with, once with the header absent entirely:

• served with the header: 16/16
• served without the header: 16/16

So enforcement is not a thing that is happening today. The honest reading is narrower than that, though: 16 answering servers is a small slice of a registry whose majority (22) sit behind OAuth, and the sample is one window of one ordering. It is evidence about September 2026, not a statement about the protocol.

The one disagreement that mattered

1 of the 16 servers that answered named a different revision than the one requested. For that server, asking tools/list while the header claimed the requested revision still worked. A permissive upstream, not a proof of safety: a conforming one is allowed to reject exactly that request.

The rows

What we found in ourselves

The gateway's own upstream client (apps/ai-gateway-service/src/mcpGateway/mcpUpstreamClient.ts) stores the session id the upstream issues and replays it on every later request. It did not do the same for the negotiated revision: it captured that value, reported it through GET /mcp/tools, and then never put it back on the wire. One server-issued value was treated as part of the contract and the other as decoration.

That asymmetry had a concrete failure shape, which the new tests pin. Before the fix, an operator-supplied mcp-protocol-version header was forwarded verbatim — so against an upstream that answers 2024-11-05 to a 2025-06-18 request, our client sent 2025-06-18 in the header: a revision the upstream had explicitly not agreed to, which is the request a conforming server is allowed to reject.

Now the post-handshake requests carry the revision the upstream named, never the one we asked for, and the initialize request itself carries none (the revision it proposes is in the body; a header asserting an agreement that has not happened yet is the wrong shape). An operator pin cannot outvote the server's answer.

Three arms prove the change rather than describe it: removing the one-line fix turns them red, and the operator-pin arm reports the exact wrong value (2025-06-18) on the wire. Two further arms — an upstream that answers no revision, and one that answers an empty string — stay green in both states by design: they are there to catch a future fallback, not to prove this one.

What our own server does, observed rather than read out of source

tools/probe-own-mcp-header-behavior.mjs boots packages/mcp-server/src/http.js in-process on the credential-free local runtime, asks it to initialize, then sends the same tools/list under three header shapes:

• answered revision: 2025-06-18, asked: 2025-06-18, session id issued: no, tools served: 15
• header present: http 200, 15 tools
• header absent: http 200, 15 tools
• header naming a revision this server never agreed to: http 200, 15 tools

So we are one of the permissive ones, and that is now an observation instead of a code reading. The probe refuses to publish any of it if its own baseline leg fails to reach a tool list: --tamper-blind sends the request to a path one character off, and that run exits 3 with INSTRUMENT_BLIND and the sentence this run says nothing about header handling - because a misconfigured probe otherwise looks exactly like a server that accepted everything.

Deliberately not claimed

• That this fixed an interoperability failure. Nothing in the sample rejects a headerless request today.
• That the header is unimportant. The sample says who enforces it now; the spec says what a client owes.
• That our HTTP server enforces inbound revisions. It advertises the header over CORS and does not read its

value — measured behaviour, and a documented choice: the gateway negotiates and records revisions (#178) rather than dropping connections that name a different one.

• The claude-code-patterns demo client was left alone: it has no session handling either, and nothing in the

product path imports it outside tests. Recorded, not silently doubled.

Reproduce

node tools/survey-mcp-protocol-version-header.mjs 40   # anonymous, read-only, one window
node tools/probe-own-mcp-header-behavior.mjs              # our own server, local runtime, no credentials
node tools/probe-own-mcp-header-behavior.mjs --tamper-blind   # must exit 3: the probe can refuse
npx vitest run apps/ai-gateway-service/src/mcpGateway/mcpGateway.test.ts   # the five client arms