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