Use case
We run an MCP gateway (Arcade) on v1.7.0-pre.2 where the go-sdk server handles the 2026-07-28 dialect and a separate legacy stack handles 2025-11-25/2025-06-18. The SDK's server/discover advertises all five protocol versions — including 2025-03-26 and 2024-11-05, which our deployment does not serve on this endpoint. Clients that pick an advertised-but-unserved version get an inconsistent experience across our two stacks. We'd like to narrow both what the server advertises and what it will negotiate.
Current behavior (pre.2)
- The version list is the package-level unexported
supportedProtocolVersions (shared.go): ["2026-07-28","2025-11-25","2025-06-18","2025-03-26","2024-11-05"].
- Discover advertises the session's
supportedVersions, set at connect via filterSupportedVersions, whose only filter is the transport-internal ProtocolVersionSupporter interface. The built-in StreamableServerTransport.SupportsProtocolVersion hardcodes its policy (gates >= 2026-07-28 behind Stateless) and is not host-configurable — and the transport is constructed inside StreamableHTTPHandler, so a host cannot supply its own implementation.
- The
-32022 error's data.supported carries the same full list.
Why middleware isn't a workaround
Middleware can rewrite DiscoverResult.SupportedVersions post-hoc, but that only changes what discover advertises — the server still accepts an initialize/request at a "hidden" version, so the advertised and negotiated sets diverge, which is worse than the status quo.
Proposal
type ServerOptions struct {
// SupportedProtocolVersions, if non-empty, restricts (intersects with the
// SDK's supported set) the versions this server advertises in
// server/discover and will negotiate.
SupportedProtocolVersions []string
}Intersection semantics keep it impossible to widen support. Related: #1025 reports the stateful transport dropping 2026-07-28 from the advertised list — the inverse concern; both would be resolved by making the version policy host-visible.
🐕 Written by Kyoto, an AI agent, on Pascal's behalf —
Use case
We run an MCP gateway (Arcade) on
v1.7.0-pre.2where the go-sdk server handles the2026-07-28dialect and a separate legacy stack handles2025-11-25/2025-06-18. The SDK'sserver/discoveradvertises all five protocol versions — including2025-03-26and2024-11-05, which our deployment does not serve on this endpoint. Clients that pick an advertised-but-unserved version get an inconsistent experience across our two stacks. We'd like to narrow both what the server advertises and what it will negotiate.Current behavior (pre.2)
supportedProtocolVersions(shared.go):["2026-07-28","2025-11-25","2025-06-18","2025-03-26","2024-11-05"].supportedVersions, set at connect viafilterSupportedVersions, whose only filter is the transport-internalProtocolVersionSupporterinterface. The built-inStreamableServerTransport.SupportsProtocolVersionhardcodes its policy (gates>= 2026-07-28behindStateless) and is not host-configurable — and the transport is constructed insideStreamableHTTPHandler, so a host cannot supply its own implementation.-32022error'sdata.supportedcarries the same full list.Why middleware isn't a workaround
Middleware can rewrite
DiscoverResult.SupportedVersionspost-hoc, but that only changes what discover advertises — the server still accepts aninitialize/request at a "hidden" version, so the advertised and negotiated sets diverge, which is worse than the status quo.Proposal
Intersection semantics keep it impossible to widen support. Related: #1025 reports the stateful transport dropping
2026-07-28from the advertised list — the inverse concern; both would be resolved by making the version policy host-visible.🐕 Written by Kyoto, an AI agent, on Pascal's behalf —