Implement MCP server/discover and UnsupportedProtocolVersionError (-32022) - #1340
Open
psp65 wants to merge 4 commits into
Open
Implement MCP server/discover and UnsupportedProtocolVersionError (-32022)#1340psp65 wants to merge 4 commits into
psp65 wants to merge 4 commits into
Conversation
added 4 commits
August 27, 2026 23:06
Per JSON-RPC 2.0, a request carrying an id must receive a response; the server previously returned null for unknown methods, which surfaced as an HTTP 200 with an empty body through HTTP transports. Notifications (requests without an id) are still silently dropped. This also makes MCP 2026-07-28 clients' auto mode fall back to the legacy handshake via a clean, deterministic -32601 on the server/discover probe instead of relying on a synthesized parse error from the empty body. https://issues.amazon.com/issues/APPDEV-2256
… versions Per the MCP spec, a server that does not support the requested protocol version must respond with the latest version it supports. Previously handleInitialize left protocolVersion unset for unknown versions, so the Smithy model default (2024-11-05, the oldest version) leaked into InitializeResult. Add ProtocolVersion.latestVersion(), derived from the supported-version registry so it cannot drift as versions are added. The registry moves into an initialization-on-demand holder: computing the latest during class init of the sealed base class NPEs when a subclass INSTANCE is the first member of the hierarchy touched (base clinit reads a still-null INSTANCE; caught by McpServerIntegrationTest). Known versions are still echoed as-is; a missing protocolVersion param keeps its existing behavior. https://issues.amazon.com/issues/APPDEV-2257
…rsionError MCP 2026-07-28 requires servers to implement server/discover, which advertises supported protocol versions, capabilities, and identity, and to reject requests naming an unsupported protocol version (via the io.modelcontextprotocol/protocolVersion key of params._meta) with UnsupportedProtocolVersionError (-32022) listing the versions the server does support. server/discover answers a wire-complete DiscoverResult advertising the handshake-era versions from the ProtocolVersion registry, newest first. Advertising no modern version is an explicit legacy advertisement that dual-era clients (Python/TypeScript/Go SDKs) answer by falling back to the initialize handshake deterministically, instead of inferring legacy-ness from an error. As the negotiation bootstrap, discover is answered regardless of the protocol version the request carries; initialize likewise stays exempt from the version guard. Requests without a _meta protocol version are served unchanged, so existing handshake-era traffic is unaffected. New Smithy shapes DiscoverResult and UnsupportedProtocolVersionErrorData model the 2026-07-28 wire contract; supported version identifiers come from a single registry-derived list so future versions update discover, the error data, and version lookup together. https://issues.amazon.com/issues/APPDEV-2258
psp65
marked this pull request as ready for review
August 29, 2026 00:25
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
1 participant
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.
What behavior changes?
Two additions from MCP protocol revision 2026-07-28, implemented so that a handshake-era server negotiates deterministically with modern clients:
server/discoveris implemented (spec: servers MUST implement it), answering a wire-completeDiscoverResult:{"result":{"resultType":"complete", "supportedVersions":["2025-11-25","2025-06-18","2025-03-26","2024-11-05"], "capabilities":{...},"ttlMs":0,"cacheScope":"private", "_meta":{"io.modelcontextprotocol/serverInfo":{"name":"...","version":"..."}}}}params._meta["io.modelcontextprotocol/protocolVersion"]getUnsupportedProtocolVersionError:{"error":{"code":-32022,"message":"Unsupported protocol version", "data":{"supported":["2025-11-25",...],"requested":"2026-07-28"}}}initializeandserver/discoverthemselves are exempt (they are the negotiation bootstraps), requests without a_metaversion are served exactly as before — zero change for existing handshake traffic — and unsupported-version notifications are dropped (JSON-RPC forbids responding to notifications).Why is this change needed?
Step 3 of #1337. Advertising only handshake-era versions from
server/discoveris the documented "explicit legacy advertisement": the Python, TypeScript, and Go dual-era clients all respond to a no-modern-versionsupportedVersionslist by falling back to theinitializehandshake cleanly — so this is safe and useful before full 2026-07-28 result support lands (at which point the registry-derived list simply grows). And clients that pin a modern version now fail fast with one actionable error instead of cryptic model-validation failures on mis-shaped results.How was this validated?
McpServerTestcases: discover result fields (including_metaserverInfo and registry-derived newest-first version order), discover answered with and without the_metaenvelope,-32022withdata.supported/data.requestedfor version-tagged requests (version rung before method rung, matching the reference SDK server's ladder), supported-version requests served normally, unsupported-version notifications dropped;ProtocolVersionTest.supportedIdentifiersAreNewestFirst. Moduletest/checkgreen including the integration suite.mode=autoon the wire showsserver/discover→DiscoverResult→ cleaninitializefallback (the explicit-legacy branch, no error-based inference); pinnedmode="2026-07-28"aborts with the actionable-32022; SDK 1.28.1 andmode=legacybyte-identical to before.What should reviewers focus on?
DiscoverResultandUnsupportedProtocolVersionErrorDatainmcp-schemas(the JSON-RPC error shape's existingdata: Documentmember carries the payload;_metauses@jsonName)._metaversion (for a handshake-only server, version-gating the bootstrap would make it unimplementable — the reference server gates it, but it is modern), and a non-string_metaversion value is ignored rather than rejected with-32602.Additional Links
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.