You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
I'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/discover RPC handler in the stateless server that returns ServerCapabilities, supported protocol versions, and server info without requiring initialization
Per-request protocol version validation via MCP-Protocol-Version header extraction in HttpServletStatelessServerTransport, returning appropriate errors on version mismatch
Per-request _meta extraction for clientInfo, clientCapabilities, and protocolVersion from request params, surfaced to handlers through McpTransportContext
Schema additions for MissingRequiredClientCapabilityError (-32003), discover request/response types, and the 2026-07-28 protocol version constant
This leaves the client-side stateless mode and subscriptions/listen as 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.
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.
Activity
BerkeAras commentedon Jun 16, 2026
+1
YousefHaggy commentedon Jul 4, 2026
Hello @Kehrlann , is this work in progress or are you looking for someone to take it on? Thanks
Kehrlann commentedon Jul 10, 2026
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.
elang2 commentedon Aug 2, 2026
I'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 initializationMCP-Protocol-Versionheader extraction inHttpServletStatelessServerTransport, returning appropriate errors on version mismatch_metaextraction forclientInfo,clientCapabilities, andprotocolVersionfrom request params, surfaced to handlers throughMcpTransportContextMissingRequiredClientCapabilityError(-32003), discover request/response types, and the2026-07-28protocol version constantThis 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.
Kehrlann commentedon Aug 3, 2026
@elang2 as stated in the comment above
We will not be accepting contributions at this time.
elang2 commentedon Aug 3, 2026
Understood, thanks for the clarity. Happy to provide input when the community review phase opens.
clojj commentedon Aug 6, 2026
Hi, did the protocol change get picked up by now?
Interested, because we have several pending features related to that update
Kehrlann commentedon Aug 6, 2026
Hey @clojj - not yet. Unfortunately it won't land before September.
Johngren commentedon Aug 26, 2026
Hey @Kehrlann,
Any news on this?
We have quite a lot of anticipation on MCP Gateway protocol mediation waiting for the SDK update.
Thank you
Kehrlann commentedon Aug 26, 2026
@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.
morad3741 commentedon Sep 23, 2026
Hi, Any Update on this?
Add a stateless server for MCP 2026-07-28