(possible) 2026-07-28 spec violation: server/discover response without 2026-07-28 support

[howardjohn]

Describe the bug
When I run a Go server with Stateless=false (the default)

Client: server/discover with 2026-07-28 metadata
Server: DiscoverResult { supportedVersions: ["2025-11-25", ...] }
Client: no mutually supported modern version, so fall back to initialize

This is a bit odd that we are using 2026-07-28 methods but then claiming we don't support 2026-07-28. I would expect an UnsupportedProtocolVersionError to be returned instead?

[nikolauspschuetz]

The behavior reproduces on main. A stateful streamable-HTTP server accepts a server/discover probe carrying MCP-Protocol-Version: 2026-07-28 and returns a DiscoverResult whose supportedVersions omits 2026-07-28 — because the version gate in ServerSession.handle (mcp/server.go:1815) checks only the global supported-versions list, while discover (mcp/server.go:867) reports the transport-filtered list via StreamableServerTransport.SupportsProtocolVersion (mcp/streamable.go:828). So the probe is answered with a success that excludes the probed version rather than rejected. This is currently intentional and pinned by TestStreamableStateful_AcceptsDiscover (mcp/streamable_test.go:3596, from #987).

The spec reads ambiguously here, which I think is the crux of the "(possible)" in the title:

• The Versioning page says that if the server doesn't support the requested version (including a known version it has chosen not to support), it MUST return UnsupportedProtocolVersionError.
• The server/discover page frames discover as the mechanism for reporting supported versions before any other request ("the client should choose one of these"), which argues that returning a list omitting the probed version is the intended behavior.

Which reading should govern server/discover on a stateful HTTP transport? If you'd prefer UnsupportedProtocolVersionError, I'm happy to send a focused, test-first PR wiring handle/discover to consult the transport's SupportsProtocolVersion (and updating TestStreamableStateful_AcceptsDiscover accordingly).

_{Investigated with AI assistance (Claude Code); findings and the diagnosis above were reviewed and verified against main.}

[guglielmo-san]

Hi @howardjohn, this behavior was intended not to break existing users. Updating the sdk version without setting the stateless flag to true, would still allow the client<->server connection to be opened without returning any error.

[howardjohn]

@guglielmo-san the specification says that if the server cannot support the protocol it should return an error: https://modelcontextprotocol.io/specification/draft/basic/versioning#protocol-version-negotiation.

In a mode where Stateless=false, the server does not support 2026-07-28 (as declared in the response, which has supportedVersions: [not-2026-07-28]) and thus should return UnsupportedProtocolVersionError IMO

[howardjohn]

Also it shouldn't break users - the spec of the 2026-07-28 clients is that a UnsupportedProtocolVersionError will downgrade to the older protocol anyways

[guglielmo-san]

You are right, the specification is clear about this, the current implementation might be a violation, I will reopen this issue