Repository navigation
Conversation
Emryswu
force-pushed
the
fix/1195-initialize-supported-versions
branch
from
October 21, 2026 08:31
0290d53 to
ba0cc74
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1195
Motivation and Context
The 2026-07-28 spec says a server that supports only modern versions SHOULD name the protocol versions it supports in any error it returns to an
initializerequest, on any transport (Versioning: Backward Compatibility). Today a legacy client never learns them:-32602"params._meta is required"400/-32020"Missing required header: Mcp-Method"This change recognizes
initializeinMcpServer#dispatchbefore the_metachecks, andHttpServletMcpTransport#validateHeaderslets it through so both transports share the same rejection path.The error keeps
-32602and reuses the existingUnsupportedProtocolVersionData:{ "code": -32602, "message": "Unsupported protocol version: 2025-11-25. Supported versions: 2026-07-28", "data": { "supported": ["2026-07-28"], "requested": "2025-11-25" } }This is the same shape earlier spec revisions used for a failed version negotiation, so legacy clients can read
data.supported, and the message still names the versions for clients that only surface the message.requestedis taken fromparams.protocolVersionand isnullwhen it is missing or not a string. The list comes from the builder'ssupportedVersions, nothing is hard-coded.How Has This Been Tested?
StdioMcpTransportTests#legacyInitializeErrorNamesSupportedVersions: legacyinitializewith custom supported versions; asserts code, message,data.supportedanddata.requested.StdioMcpTransportTests#legacyInitializeWithoutRequestedVersionStillNamesSupportedVersions(parameterized): noparams, emptyparams, non-stringprotocolVersion; assertsdata.requestedisnulland no exception.HttpServletMcpTransportIntegrationTests#legacyInitializeWithoutMethodHeaderErrorNamesSupportedVersions: end to end over Tomcat withoutMcp-Method; asserts400and the same error body.The new stdio and HTTP tests fail on
mainand pass with this change.mcp-core: 604 tests, 0 failures.HttpServletMcpTransportIntegrationTests: 24 tests, 0 failures on both Jackson 3 and Jackson 2.Breaking Changes
None. Only the error returned to a legacy
initializechanges; it was already rejected.Types of changes
Checklist
Additional context
The error code stays
-32602rather thanUNSUPPORTED_PROTOCOL_VERSION(-32022), since that is the code legacy clients expect for this case; the spec leaves the code implementation-defined. Happy to switch if you prefer-32022.