[jmrplens]

initialize is deprecated in 2026-07-28, so negotiatedVersion caps that handshake below it on purpose: a client asking for 2026-07-28 there is answered 2025-11-25. InitializeParams.ProtocolVersion keeps whatever the client asked for, and four places that decide how to talk to a session read that value instead of the version the handshake settled on.

The result is that such a session gets none of the interaction the protocol offers it. clientSupportsMultiRoundTrip marks the result input_required and attaches an inputRequests map, which 2025-11-25 does not define, while assertServerInitiatedRequestAllowed refuses elicitation/create, sampling/createMessage and roots/list, which are the mechanism that session does have, with an error naming a version it never got. The second function's own doc comment already describes it as a check on a session "negotiated at protocol version >= 2026-07-28".

Server.notifySessions and Server.ResourceUpdated lose the same session a second way: it is not counted a legacy subscriber, so it is not notified on the shared session channel, and it never opened the subscriptions/listen stream the other branch delivers on, because that method does not exist in the version it negotiated. ResourceUpdated goes further and stamps the per-session subscription id into the notification's _meta, which that version does not define either.

This change adds ServerSession.protocolVersion, which answers with ServerSessionState.NegotiatedProtocolVersion and falls back to the declared value when the state recorded none, and ServerSession.negotiatedLegacyProtocol on top of it. All four places now read the version through protocolVersion, three of them through negotiatedLegacyProtocol, so the version that chooses an interaction pattern is read in one place rather than in four copies of a condition.

Why all four and not only the first

They are one decision and they have to agree. I tried fixing clientSupportsMultiRoundTrip alone, and the failure gets worse rather than better: the server-side shim then calls ServerSession.Elicit, the second check refuses it, and a tool call that used to return a quietly ignored result returns

multi-round-trip: fulfilling input request "confirm": "elicitation/create" cannot be sent while serving a request on protocol version 2026-07-28: return an InputRequests map instead (multi round-trip requests, SEP-2322)

The two notification paths are the same decision again. I first sent this without them and offered to take them separately; they are folded in here at review's request.

Why the fallback

Since #1274, every path in the SDK that records a version records the negotiated one too: initialize, server/discover, the first call of a SEP-2575 session and the state the stateless handler synthesizes for a request carrying MCP-Protocol-Version. The fallback stays for state the SDK did not write itself: ServerSessionOptions.State is exported, so a caller may supply InitializeParams with no negotiated version, and NegotiatedProtocolVersion was added in #1199, so state persisted before that carries only the declared version.

What a session with no recorded version is

The four places disagreed about this. clientSupportsMultiRoundTrip defaults to latestProtocolVersion and reads the absence as the new protocol; the two notification loops read InitializeParams().isNil() and read it as legacy, as assertServerInitiatedRequestAllowed does. For the three places that read it, negotiatedLegacyProtocol settles it the second way, at review's request.

ServerSession.handle records the declared version on the first call a new-protocol client makes, before the call is dispatched, and server/discover records it in its own handler, while since #1273 a legacy call before initialize is refused, so no call reaches clientSupportsMultiRoundTrip on such a session. What the reading still covers is a session that has issued no call: one that has connected and not yet sent anything, which notifySessions iterates because it walks every session in s.sessions, and which keeps receiving the notification on the session channel, as on main. Subscribing before the handshake does not put such a session in front of ResourceUpdated: since #1273, a resources/subscribe sent before initialize is refused and leaves no subscriber.

Tests

TestMultiRoundTrip_NegotiatedDownFromNewProtocol is the test that pins this. It drives a raw JSON-RPC client that sends initialize declaring 2026-07-28, asserts the server answers 2025-11-25, calls a tool whose handler returns an InputRequests map, and asserts that what comes back is an elicitation/create request the client can answer, followed by the completed tool result. Before the change the next message is the tool result itself, carrying resultType: "input_required", and the test fails there.

TestNotifySessions_NegotiatedDownFromNewProtocol drives the same handshake, adds a tool, and asserts the list-changed notification arrives on the session channel. Before the change it blocks until the deadline.

TestResourceUpdated_NegotiatedDownFromNewProtocol subscribes on that session and asserts both halves: the notification arrives, and it does not carry io.modelcontextprotocol/subscriptionId. Before the change it fails on the second.

TestClientSupportsMultiRoundTrip is a table over session states: no handshake, a server/discover session, an initialize session at a legacy version, an initialize session negotiated down, and the synthesized state of a stateless legacy request. The first and fourth rows fail before the change; the others document that nothing else moves. TestNegotiatedLegacyProtocol_NoHandshakeIsLegacy is the same table read from the notification side.

What an existing user sees change

A session that ran initialize asking for 2026-07-28 and was answered an older version is now served the legacy interaction. A handler returning InputRequests no longer produces an input_required result for it: the server fulfils the requests itself and re-invokes the handler once, which is what the SDK already does for every other client below 2026-07-28. ServerSession.Elicit, CreateMessage, CreateMessageWithTools and ListRoots stop returning an error on such a session and send the request. It is also counted a legacy subscriber, so list-changed and resource-updated notifications reach it on the session channel, without a subscription id in _meta.

A session that has recorded no protocol version at all is still counted legacy in the two notification loops, as on main, and clientSupportsMultiRoundTrip now reads it as legacy too instead of as the latest version, which no call can observe, as above.

No other session changes. A client that reaches 2026-07-28 through server/discover, which is what this SDK's own client does, has had that version recorded as negotiated since #1274, and is read exactly as before.

What I left out

There is one read of the declared version I deliberately did not touch: the exported ServerRequest.ProtocolVersion falls back to InitializeParams.ProtocolVersion, which its doc comment states, and its only caller in the SDK is Server.discover, on the new-protocol path where the two values agree.

Fixes #1258.

[jmrplens]

A data point from current main (f286395) that I think makes this pull request more pressing than when I opened it.

Since #1226 (e40f35d), a session negotiated down from 2026-07-28 gets a worse answer than it did on v1.8.0. A client asks for 2026-07-28 in initialize, is answered 2025-11-25, and calls a tool whose handler returns InputRequests, with no _meta on the call. On main the result is:

{"content":null,"requestState":"state-1","inputRequests":{"title":{"method":"elicitation/create","params":{"mode":"form","message":"Enter the title"}}}}

On v1.8.0, and on 5bc078a just before #1226, the same call carried "resultType":"input_required" beside those fields. The dispatcher still chooses the multi round-trip flow from the declared version (clientSupportsMultiRoundTrip in mcp/mrtr.go), while the label is now written only when the request carries the new protocol in its _meta (validatedMeta.usesNewProtocol in ServerSession.handle). So the result goes out shaped for 2026-07-28 with neither the label nor any content, a 2025-11-25 client reads it as a complete result with content: null, and the input request is lost.

With this branch merged into main, the same call sends elicitation/create to the client instead, which is what a 2025-11-25 session expects.

The branch now conflicts with main only in the imports of mcp/mrtr_test.go. Merged locally with main, it passes go vet ./... and go test ./.... I can push that merge whenever it suits you, and I can paste the reproduction too (one test over NewInMemoryTransports that writes the two requests by hand).

[jmrplens]

I merged main into the branch (one import conflict in mcp/mrtr_test.go), and go vet ./... and go test ./... pass.

Could this go into 1.9.0? A session negotiated down from 2026-07-28 still gets a tool's input requests back as a result instead of an elicitation/create, and since #1226 that result no longer carries resultType: input_required, so on eafb671 it reads as complete with content: null and the question is lost.

[guglielmo-san]

@jmrplens thank you for the contribution!