Skip to content

SEP-2575: Make MCP Stateless #1011

Description

@localden

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

Activity

  1. BerkeAras commented on Jun 16, 2026

    @BerkeAras

    +1

  2. added this to the 3.x Planning milestone on Jun 24, 2026
  3. added
    P1Significant bug affecting many users, highly requested feature
    and removed on Jun 24, 2026
  4. YousefHaggy commented on Jul 4, 2026

    @YousefHaggy
    Contributor

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

  5. Kehrlann commented on Jul 10, 2026

    @Kehrlann
    Contributor

    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.

  6. elang2 commented on Aug 2, 2026

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

  7. Kehrlann commented on Aug 3, 2026

    @Kehrlann
    Contributor

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

  8. elang2 commented on Aug 3, 2026

    @elang2

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

  9. clojj commented on Aug 6, 2026

    @clojj

    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 update

  10. Kehrlann commented on Aug 6, 2026

    @Kehrlann
    Contributor

    Hey @clojj - not yet. Unfortunately it won't land before September.

  11. Johngren commented on Aug 26, 2026

    @Johngren

    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

  12. Kehrlann commented on Aug 26, 2026

    @Kehrlann
    Contributor

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

  13. morad3741 commented on Sep 23, 2026

    @morad3741

    Hi, Any Update on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1Significant bug affecting many users, highly requested featurearea/transportenhancementNew feature or request

    Projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions