Update the MCP Go SDK to v1.7.0 and serve the 2026-07-28 protocol revision - #871
Open
yuzi-co wants to merge 2 commits into
Open
Update the MCP Go SDK to v1.7.0 and serve the 2026-07-28 protocol revision#871yuzi-co wants to merge 2 commits into
yuzi-co wants to merge 2 commits into
Conversation
yuzi-co
force-pushed
the
feat/mcp-protocol-2026-07-28
branch
from
August 10, 2026 10:53
af946f2 to
461f4f2
Compare
The release brings the 2026-07-28 protocol revision, and it changes two behaviours that the existing tests pinned. Both come from the spec, and both apply to this handler because it is stateless. A stateless server no longer issues or reads Mcp-Session-Id, and it answers DELETE with 405 rather than 204. Existing clients keep working: they negotiate the revision they know, and the session header they send is ignored instead of rejected. MCPGODEBUG=allowsessionsinstateless=1 restores the old handling for a client that cannot do without it. An oversized body now returns 413 with "request body exceeds N bytes". The handler already capped the body at 1MiB with http.MaxBytesHandler. The SDK turns that cap into the status the case deserves instead of a generic read error, so the test asserts the status and the limit that produced it.
The streamable HTTP transport offers the 2026-07-28 revision only to a stateless handler. A stateful one negotiates down to 2025-11-25, and the revision becomes unreachable without any build or test failing. The handler sets Stateless, so the revision is live today, and nothing recorded that. TestMCPHandlerServesLatestProtocol probes the server the way a 2026-07-28 client does: server/discover in place of the initialize handshake, per-request _meta that carries the client identity, and the Mcp-Method and Mcp-Name headers that the revision makes mandatory. It then calls a tool and reads the recorded HID write, which shows that the tools work under the revision rather than only being listed by it. The test asserts that 2026-07-28 is the first entry of supportedVersions, which the SDK orders newest first. A later SDK that adds a revision therefore fails this test on purpose: the new revision needs the same deliberate check before the server starts speaking it. A second request proves the older revisions still reach the same endpoint and still have no server/discover.
yuzi-co
force-pushed
the
feat/mcp-protocol-2026-07-28
branch
from
August 13, 2026 17:48
461f4f2 to
98e7515
Compare
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 this does
Updates
github.com/modelcontextprotocol/go-sdkfrom v1.6.1 to v1.7.0, whichadds the
2026-07-28protocol revision. The MCP handler needs no change toserve it: the streamable HTTP transport offers that revision to a stateless
handler, and
NewMCPHandleralready setsStateless: true. Older clients keepworking — the SDK negotiates the highest revision both sides support.
Behaviour changes that come with the SDK
Both follow the spec, and both apply because the handler is stateless.
Mcp-Session-Id,and it answers
DELETEwith405rather than204. A client that stillsends the header is answered without it rather than rejected.
MCPGODEBUG=allowsessionsinstateless=1restores the old handling.413with
request body exceeds N bytes, instead of a generic read error. The capitself is unchanged; the SDK just reports it with the right status.
Tests
TestMCPInitializeAndToolsListis adapted to the two changes above.TestMCPHandlerServesLatestProtocolis new. It drives the endpoint the way a2026-07-28client does —server/discoverinstead of the initializehandshake, per-request
_metafor the client identity, and theMcp-Methodand
Mcp-Nameheaders the revision requires — then calls a tool and checks therecorded HID write, so the tools are exercised under the revision rather than
merely listed by it. A second request confirms the older revisions still reach
the same endpoint and still have no
server/discover.The test asserts that
2026-07-28is the first entry ofsupportedVersions, which the SDK orders newest first. A future SDK that addsa revision therefore fails this test on purpose, so the new revision gets a
deliberate review before the server starts offering it.
Verification
The
novisiontag is a downstream build tag, so on this branch it only coversservice/mcp/...; those packages pass. The remaining packages were verifiedwith the tag available.
Not touched:
service/picoclawkeeps its own hand-rolled JSON-RPC endpoint atprotocol version
2024-11-05. It does not use this SDK.