Streamable HTTP server accepts mismatched `MCP-Protocol-Version` header and body `protocolVersion` on `initialize`

[cclabadmin]

Describe the bug

When the initial initialize request carries an MCP-Protocol-Version HTTP header that disagrees with initialize.params.protocolVersion in the JSON-RPC body, the server accepts the request without error. The negotiated protocol version follows the JSON-RPC body rather than the MCP-Protocol-Version request header.

The current MCP 2025-11-25 specification does not explicitly require the server to check body/header consistency on initialize, so this is filed as an implementation observation rather than a strict spec-violation claim.

• Environment
  • Reproduced with stable release v0.16.0 (e35841af)
  • Also reproduced with a main snapshot from 2026-05-15: d6b53928
  • Transport: Streamable HTTP server (stateful profile)

To reproduce

1. Start a Ruby SDK Streamable HTTP server.
2. Send an initialize request where the body protocolVersion is 2025-11-25 but the MCP-Protocol-Version header is 2025-03-26 (or vice versa).
3. Observe that the server returns HTTP 200 with a normal initialize result.
4. Check the negotiated protocol version in the response.

Expected behavior

Option A: the server rejects the mismatch before negotiation, for example with HTTP 400 or a JSON-RPC Invalid Request error.

Option B: the spec clarifies which field is authoritative, and the SDK documents that behavior and covers it with a regression test.

Logs

Both mismatch directions were accepted:

body=2025-11-25 header=2025-03-26 -> HTTP 200, negotiated version follows body (2025-11-25)
body=2025-03-26 header=2025-11-25 -> HTTP 200, negotiated version follows body (2025-03-26)

After initialization, subsequent responses used the body-negotiated version in the MCP-Protocol-Version header, not the original mismatched header value.

Minimal reproducible request

With a Streamable HTTP server running, set ENDPOINT to the server endpoint and send an initial initialize request whose HTTP header and JSON-RPC body disagree:

ENDPOINT=http://127.0.0.1:8080/mcp

curl -i -sS --http1.1 -X POST "$ENDPOINT" \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/json, text/event-stream' \
  -H 'MCP-Protocol-Version: 2025-03-26' \
  --data '{"jsonrpc":"2.0","id":"init-conflict-1","method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"version-conflict-repro","version":"0.1.0"}}}'

Repeat with the values reversed: body 2025-03-26, header 2025-11-25.

Additional context

• Related: SEP-2575 introduces a related future-state requirement that, for HTTP requests, the MCP-Protocol-Version header match _meta["io.modelcontextprotocol/protocolVersion"].

[koic]

Thanks for the detailed report. After reviewing the MCP spec and the other official SDKs, this PR does not reject the mismatch; instead it documents the current behavior (the JSON-RPC body params.protocolVersion is authoritative) with a code comment and adds regression tests.

The 2025-06-18 / 2025-11-25 specifications require MCP-Protocol-Version only on requests subsequent to initialize and do not mandate header/body consistency on the initial initialize. All other official SDKs (TypeScript, Python, Rust, Java, Go, PHP) accept the mismatch and treat the JSON-RPC body as authoritative; rejecting it in Ruby SDK alone would make it the only outlier on the strict side.

This PR adds a code comment above the existing initialize exemption explaining the rationale, and two regression tests covering both mismatch directions from your reproduction (header older / body newer, and the reverse).

SEP-2575 introduces a related consistency requirement for the future; this can be revisited alongside the corresponding _meta plumbing once that proposal is ratified.

I've opened #352.