Repository navigation
SEP-2575: Make MCP Stateless #1011
Description
Activity
+1
Reacted by Björn- addedP1Significant bug affecting many users, highly requested featureSignificant bug affecting many users, highly requested featureand removed
on Jun 24, 2026 Hello @Kehrlann , is this work in progress or are you looking for someone to take it on? Thanks
Hey @YousefHaggy - as I mentioned in #274 (comment) , the core maintainer team is on-and-off on PTO, so we won't start the work for a few more weeks.
It tightly linked to #1004. Since this is quite foundational and involves a lot of design decisions, we'd like the core team to drive this. We'll request input from the community.
EDIT: we are not accepting contributions for this at the moment.
Reacted by Yousef Haggy and haufe-mrclmrI'd like to contribute to this. Having reviewed SEP-2575 and the existing stateless server implementation (
McpStatelessAsyncServer,HttpServletStatelessServerTransport,DefaultMcpStatelessServerHandler), the SDK already has strong foundations for stateless operation on the server side.I'd propose tackling this incrementally, starting with the server-side protocol gaps:
server/discoverRPC handler in the stateless server that returnsServerCapabilities, supported protocol versions, and server info without requiring initialization- Per-request protocol version validation via
MCP-Protocol-Versionheader extraction inHttpServletStatelessServerTransport, returning appropriate errors on version mismatch - Per-request
_metaextraction forclientInfo,clientCapabilities, andprotocolVersionfrom request params, surfaced to handlers throughMcpTransportContext - Schema additions for
MissingRequiredClientCapabilityError(-32003), discover request/response types, and the2026-07-28protocol version constant
This leaves the client-side stateless mode and
subscriptions/listenas follow-up PRs. Would this scoping work for the maintainers? Happy to adjust based on feedback.I see PR #1034 adding repository contracts for the stateless server. My work would be complementary, focusing on the protocol-level stateless mechanics rather than primitive resolution.
@elang2 as stated in the comment above
Since this is quite foundational and involves a lot of design decisions, we'd like the core team to drive this. We'll request input from the community.
We will not be accepting contributions at this time.
Understood, thanks for the clarity. Happy to provide input when the community review phase opens.
Hey @YousefHaggy - as I mentioned in #274 (comment) , the core maintainer team is on-and-off on PTO, so we won't start the work for a few more weeks.
Hi, did the protocol change get picked up by now?
Interested, because we have several pending features related to that updateHey @clojj - not yet. Unfortunately it won't land before September.
Hey @Kehrlann,
Any news on this?We have quite a lot of anticipation on MCP Gateway protocol mediation waiting for the SDK update.
Thank youReacted by Wojciech Baszczyk@Johngren Still won't land before September.
We're in the early stages of the design process. We'll try to get the first milestones out in September.
Reacted by John githubLastname, Lawrence Chase and Sebastian MaHi, Any Update on this?
Reacted by Prashant Ronad, ouym, Harsh Mangalam Verma , XVP and Jelly Lee
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsTodo
Tracking implementation of SEP-2575 for the 2026-07-28 MCP spec release.