SEP-2567: Sessionless MCP via Explicit State Handles#2567
Conversation
Should this be "prior request call state"? I don't think we want other requests to effect the outcome as well right? |
|
|
||
| **Clients.** Clients become simpler: they no longer track or resend session identifiers, or need to determine whether a given server is stateful. List-endpoint caching becomes safe. | ||
|
|
||
| Rollout is a clean break: sessions are removed in the next spec version, with no deprecation window. Servers that currently rely on session-scoped state stay on the current protocol version until they have migrated to explicit handles. Protocol version negotiation already handles mixed-version deployments — a client that supports both versions speaks the old protocol to an unmigrated server and the new one to everyone else. This avoids shipping a version where clients support both modes simultaneously, which would prevent the caching benefit (a client cannot cache list endpoints if any connected server might be session-scoped). |
There was a problem hiding this comment.
Rollout is a clean break: sessions are removed in the next spec version, with no deprecation window. Servers that currently rely on session-scoped state stay on the current protocol version until they have migrated to explicit handles.
Somewhere in this SEP we should provide an example of how SDKs should handle this. I think we are essentially saying that the session functionality become a no-op.
|
This looks good to me. Supportive of this! |
|
This was reviewed by Core Maintainers: 6 Accepted, 2 Accept with Changes. |
|
New commits were pushed — removed the |
d95feda to
dada908
Compare
This means that MCP Servers cannot filter tools, resources, or prompts based on authorization. Seems like a step backwards. Why list an entity the client / user can't use? Actually, I guess you could do an auth to entity permission look-up on every call. It just means greater burden on the server |
|
Continuing from #2575 (comment)
Even if all transport calls are authenticated/authorized, there is a danger that the user with lower permissions could potentially hijack the session of a super user by using their handle id. |
You can still filter based on auth. I should clarify that sentence as I can see why it looks like it implies the opposite. "Per-connection state" means relying on information sent in previous messages on the connection. The auth headers are on every request, so it is stateless. |
… example, Future Work) - Replace enable_admin_tools with connect_database/connection_id as the list-mutation example (non-auth scenario), and broaden the prohibition from "tool calls" to "other requests" - Drop the "rarely used" claim; the constraint follows from removing sessions regardless of current usage - Add SHOULD NOT for stdio process-lifetime state, citing undefined scope and lack of HTTP parity - Add Future Work section noting protocol-level handle marking ($defs/$ref, annotations) as a follow-up - Wording: "not fully precise" -> "imprecise"
Removes sessions and Mcp-Session-Id from the draft spec (transports, architecture, lifecycle, etc.), rescopes request-ID/SSE-event-ID/list clauses, and adds a non-normative Stateful Tools section to tools.mdx. Expands the SEP's Consequential spec edits to match.
"MUST NOT vary per-connection" was being read as forbidding auth-based filtering. Make explicit that credentials are per-request input, not connection state, so servers may return different sets to different principals.
dada908 to
8cb5b8b
Compare
CaitieM20
left a comment
There was a problem hiding this comment.
Mostly LGTM a few minor issues around merge conflicts, and the SEP should be marked as Accepted not Draft
Addresses review feedback: updates SEP status from Draft to Accepted and resets docs.json against main to restore nav entries (client-best-practices, mrtr, working-group charters) that were dropped during a prior merge.
|
Update SEP status to final as reference implementation and conformance tests are not needed here: servers that don't return session IDs are already part of the spec and something that all SDKs already support. |
Summary
Draft SEP proposing the removal of protocol-level sessions from MCP, replacing implicit session-scoped state with explicit, server-minted state handles. Builds on SEP-1442 (stateless-by-default) but argues the opt-in stateful path should not exist at all.
Core claims:
tools/listforcesO(subagents × servers)re-fetches on everyone, even when ~zero servers actually use it(deployment, auth)granularityWhat changes:
session/create,session/destroy, orMcp-Session-Idheadertools/list/resources/list/prompts/listMUST NOT depend on per-connection or prior-tool-call statecreate_*() -> handle+ threaded parameters (guidance, not a protocol construct)Imported from modelcontextprotocol/transports-wg#25.