Problem
The spec states:
"If the server receives a request with an invalid or unsupported MCP-Protocol-Version,
it MUST respond with 400 Bad Request."
The terms "invalid" and "unsupported" are conflated, but they should have different meanings:
- Invalid: Malformed version string (e.g., "foobar", "2025/11/25", empty string)
- Unsupported: A valid version format but not known to this server (e.g., a future version)
The Forward-Compatibility Problem
Some servers built with older SDKs or custom transports mistakenly have a hardcoded SUPPORTED_PROTOCOL_VERSIONS list.
When a new protocol version is released (e.g., 2025-11-25), old servers don't recognize it as valid and return 400
Proposed Clarification
-
For initialization: Version negotiation already handles unknown versions gracefully (server responds with its supported version) falling back to 2025-03-26 if the header is missing. This is correct.
-
For subsequent requests:
- Malformed versions (doesn't match
YYYY-MM-DD format) should return 400
- For valid-format versions, the server SHOULD either:
a. Accept if it matches what was negotiated during init
b. Accept if still in supported list for that server but not the same as negotiated during init (TODO: maybe we can warn here?)
c. Return 400 if unsupported
- When the
MCP-Protocol-Version header is missing, the server should Accept and default to the version negotiated at init
Related
Problem
The spec states:
The terms "invalid" and "unsupported" are conflated, but they should have different meanings:
The Forward-Compatibility Problem
Some servers built with older SDKs or custom transports mistakenly have a hardcoded
SUPPORTED_PROTOCOL_VERSIONSlist.When a new protocol version is released (e.g.,
2025-11-25), old servers don't recognize it as valid and return 400Proposed Clarification
For initialization: Version negotiation already handles unknown versions gracefully (server responds with its supported version) falling back to 2025-03-26 if the header is missing. This is correct.
For subsequent requests:
YYYY-MM-DDformat) should return 400a. Accept if it matches what was negotiated during init
b. Accept if still in supported list for that server but not the same as negotiated during init (TODO: maybe we can warn here?)
c. Return 400 if unsupported
MCP-Protocol-Versionheader is missing, the server should Accept and default to the version negotiated at initRelated
Unsupported protocol versioninspector#959