SEP-2575: Make MCP Stateless

[localden]

Tracking implementation of SEP-2575 for the 2026-07-28 MCP spec release.

[BerkeAras]

+1

[YousefHaggy]

Hello @Kehrlann , is this work in progress or are you looking for someone to take it on? Thanks

[Kehrlann]

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]

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:

1. server/discover RPC handler in the stateless server that returns ServerCapabilities, supported protocol versions, and server info without requiring initialization
2. Per-request protocol version validation via MCP-Protocol-Version header extraction in HttpServletStatelessServerTransport, returning appropriate errors on version mismatch
3. Per-request _meta extraction for clientInfo, clientCapabilities, and protocolVersion from request params, surfaced to handlers through McpTransportContext
4. 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.

[Kehrlann]

@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.

[elang2]

Understood, thanks for the clarity. Happy to provide input when the community review phase opens.