feat(mcp)!: migrate to the stateless MCP 2026-07-28 protocol - #297
Open
antfubot wants to merge 2 commits into
Open
feat(mcp)!: migrate to the stateless MCP 2026-07-28 protocol#297antfubot wants to merge 2 commits into
antfubot wants to merge 2 commits into
Conversation
Serve the MCP surface through the SDK's stateless 2026-07-28 entry points, retiring devframe's custom Mcp-Session-Id lifecycle: - HTTP moves to `createMcpHandler`, building a fresh server per request (no session registry, no session-local routing, GET/DELETE -> 405). 2025-era clients are still served through the SDK's stateless legacy path. - stdio moves to `serveStdio`, pinning one server per connection. - `devframe connect` negotiates the modern era via `server/discover`, falling back to the 2025 handshake for a 2025-only instance. - `list_changed` events bridge onto modern `subscriptions/listen` streams (HTTP via the handler's notify bus; stdio via the pinned server's send*ListChanged calls). The devframe API surface (createMcpServer, createMcpFetchHandler, mountMcpHttp, cli.mcp) and the origin gate are unchanged. Closes #293
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
antfu
changed the title
The hub aggregate-MCP and Next handler tests still exercised the 2025 initialize/Mcp-Session-Id handshake. Serve them statelessly: the hub test lists tools with a single per-request POST, and both assert no session id is issued.
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 & why
Migrates devframe's MCP surface to the stateless MCP 2026-07-28 protocol, as tracked in #293, as a clean break for v0.10.0. It retires devframe's hand-rolled
Mcp-Session-Idlifecycle in favor of the SDK's stateless serving entry points, so requests reach any server instance without session affinity and modern MCP clients are first-class.Per the agreed posture, the endpoints keep serving 2025-era clients through the SDK's default stateless legacy path — the custom session registry is gone either way, but today's clients keep working.
Changes
createMcpFetchHandler) moves to the SDK'screateMcpHandler, building a fresh server per request. No session registry, no session-local routing; aGET/DELETE(2025 session ops) is answered405. The loopback origin gate is unchanged.createMcpServer) moves toserveStdio, pinning one server per connection.devframe connectnegotiates the modern era viaserver/discover, falling back to the 2025 handshake for a 2025-only instance.list_changedevents bridge onto modernsubscriptions/listenstreams — over HTTP through the handler's notify bus, on stdio through the pinned server'ssend*ListChangedcalls.buildMcpServerFromContext) is split from the notification bridge (bridgeListChanged) so it's safe to call per request / per connection.transports.ts(the oldstartStdioTransportwrapper) is removed.The authored devframe API —
createMcpServer,createMcpFetchHandler,mountMcpHttp,cli.mcp, the agent host — is unchanged, so the Vite/Next bridges and custom hosts need no code changes.Docs
Notes
Closes #293
This PR was created with the help of an agent.