SEP-2575: Make MCP Stateless#2575
SEP-2575: Make MCP Stateless#2575kurtisvg wants to merge 69 commits intomodelcontextprotocol:mainfrom
Conversation
| server **MUST** return a `Method not found` JSON-RPC error (`-32601`). For HTTP, | ||
| the response status code MUST be `404 Not Found`. | ||
|
|
||
| #### `server/discover` RPC |
There was a problem hiding this comment.
Should we add the ttl to this that @CaitieM20 is proposing in the other SEP?
One thought on my mind is that for older server/newer client compatibility, realistically the client will actually need to remember the server's older protocol version if it wants to avoid an error on every request trying to figure out the compatible version, so we need a way to cache that.
There was a problem hiding this comment.
Agree it should be added somewhere. I wasn't sure which would get merged first.
There was a problem hiding this comment.
FWIW, I was going to suggest the exact same thing. I'd prefer to err on the side of putting it in both places, to make sure it doesn't get missed. :)
43950d9 to
0cc1245
Compare
| export interface RequestMetaObject extends MetaObject { | ||
| progressToken?: ProgressToken; | ||
| + /** | ||
| + * The MCP Protocol Version being used for this request. | ||
| + */ | ||
| + "io.modelcontextprotocol/protocolVersion": string; | ||
| } |
There was a problem hiding this comment.
I wonder if we are overloading _meta here over time. Would we ever add any top level field anymore or shove everything into meta? For me the distinction might be more along the lines of what is a required field by the protocol vs what is an optional field or something provided by an extension. I can't fully point my finger at it, but it feels more right to me, to have a top protocolVersion field instead.
There was a problem hiding this comment.
I think we started with a top-level field, and there was some feedback that we should use _meta instead because of this line in the spec:
Additionally, definitions in the schema may reserve particular names for purpose-specific metadata, as declared in those definitions.
Is protocolVersion the only field you think makes sense at the top level? Or should the others be as well?
- Update Lifecycle Management description to reflect per-request model - Add per-request protocol fields table to _meta section
- Remove initialize cancellation restriction (initialize no longer exists) - Add Transport-Specific Cancellation section: HTTP uses stream close, stdio uses notifications/cancelled
…-2575) - New basic/utilities/subscriptions.mdx: full subscriptions/listen mechanics - resources.mdx: trim subscriptions section to cross-link subscriptions page - logging.mdx: remove logging/setLevel; document per-request logLevel and subscriptions/listen - docs.json: add subscriptions to draft nav
- versioning.mdx: per-request version negotiation via _meta, not initialization - server-concepts.mdx: resources/subscribe → subscriptions/listen in protocol table - authorization.mdx: remove Mcp-Session-Id hardening bullet; reframe as per-request token-based auth
- client/roots, sampling, elicitation: capability declared in clientCapabilities per-request, not during initialization - server/prompts: capability declared in DiscoverResult, not during initialization - server/tools: remove broken #initialization link from server name note - architecture/index: rewrite Capability Negotiation section for per-request model - basic/utilities/tasks: update capability declaration and negotiation prose
| | `promptsListChanged` | `boolean` | Receive `notifications/prompts/list_changed` when prompts change | | ||
| | `resourcesListChanged` | `boolean` | Receive `notifications/resources/list_changed` when list changes | | ||
| | `resourceSubscriptions` | `string[]` | Receive `notifications/resources/updated` for these resource URIs | | ||
| | `logLevel` | `LoggingLevel` | Receive `notifications/message` at or above this severity level | |
There was a problem hiding this comment.
Is this meant to be here? Don't we have that in metadata?
There was a problem hiding this comment.
In the SEP, I have it listed as both. I think I was thinking of _meta as the "per-request" stream while this is more of the "notifications events" stream and might have notifications more general for the server. But agree it's confusing.
I'll reduce to _meta -- this is going to be marked as deprecated soon anyway, so probably not worth overthinking.
…eta section (SEP-2575)
…stdio unexpected termination
Summary
This PR introduces a SEP for making MCP stateless-by-default, migrated from the original issue discussion at #1442 into the PR-based SEP format per SEP-1850.
Motivation
The current MCP specification requires a mandatory initialization handshake that establishes persistent session state. This creates significant challenges for scalability (load balancing requires sticky sessions), resilience (server failure loses session state), and implementation complexity (both client and server must manage session lifecycles).
What This SEP Proposes
This SEP removes the initialization handshake and replaces it with discrete, stateless alternatives following a "pay as you go" model:
MCP-Protocol-VersionHTTP header and_metafield, with version negotiation throughUnsupportedVersionErrorresponsesserver/discoverRPC — optional discovery endpoint for server capabilities, supported versions, and metadata, replacing the capability exchange from initialization_metaper-request instead of negotiating once at connection timemessages/listenRPC — dedicated endpoint for client-initiated streaming, replacing the existing GET endpoint behavior for Streamable HTTPRelationship to Other SEPs
This SEP focuses on removing the initialization handshake and providing stateless alternatives. Session-related concerns are handled separately:
The content of this SEP will be updated in subsequent commits to reflect these decisions and remove session-related material that is now covered by those SEPs.
Fixes #1442