Contributors: @kurtisvg (on behalf of the Transport Working Group)

Why Sessions are currently problematic

There are many questions on what role the session is supposed to play. Because sessions are not well defined, it’s unclear how to appropriately use them, introducing ambiguity in how servers and clients expect them to be handled. The latest MCP spec only defines the session as (emphasis mine):

An MCP “session” consists of logically related interactions between a client and a server, beginning with the initialization phase.

However, it’s very unclear on both what and how the session is supposed to be used to group related interactions together. The original intent seems to have been some kind of state management, but with the introduction of streamable HTTP, sessions became optional. This introduces a bit of a paradox – initializations are initiated by the client, but can only actually be created by the server, but then again deleted by the client:

Clients that no longer need a particular session (e.g., because the user is leaving the client application) SHOULD send an HTTP DELETE to the MCP endpoint with the Mcp-Session-Id header, to explicitly terminate the session.

When a session-id is provided, it’s totally unclear how the client should be reacting. Should the client reuse a session every time it starts a chat? How long should the server preserve the state of the session? What if the server creates a session but the client doesn’t subscribe to notifications? How long should the client maintain a session before attempting to renegotiate things?

As part of trying to address these concerns, the transport working group has broken the use of sessions into two major categories:

Use-case A: “Transport” or “Tracking” sessions

Transport sessions represent the state of communication with the MCP client. They are tied to the following information having been previously negotiated:

1. Negotiated protocol version
2. Client capabilities
3. Server Capabilities

If sessions are intended to be tracking sessions, it is reasonable to assume that they represent the state between the MCP Client and the MCP server, and might not be logically grouped by more than that. Multiple end-user requests may be sent over the same session without issue.

However if these things change it’s unclear what should happen. If a server changes its capabilities, should it terminate the session? Server notifications are optional – the client may choose NOT to establish a notification channel for these notifications. If a server changes its tools and a client isn’t listening for notifications, how should the client know the tool has changed? Should the state of the ToolLists, ResourcesLists, etc be tied to the duration of the session?

Use-case B: “Logical”, “Contextual”, or “User” sessions

Logical sessions represent the state of communication with some specific shared context. This context is decided by the application, and might be any of the following:

4. per LLM context window
5. per application
6. per account or user
7. Out of band Elicitation / Sampling requests (e.g. not associated with an existing request)

If sessions are intended to be _logical _ sessions, it is reasonable for servers to preserve some state between different requests in the same session. As a trivial example, a server might with to have a "count" tool that always returns one more than the last time it was called in that session:

begin_transaction()
read_contents()
write_contents()
end_transaction()

Request

The request from the transport working group is a request from the original contributors:

• What is the intended role of sessions? Are they supposed to be “transport” sessions or “logical” sessions? What use cases should be particularly covered?
• If the answer is “both”, are there any concerns with proposals to separate those use cases more clearly? E.g. if we provide non-stateful functionality to cover use-case A, and rework sessions to focus on use-case B?
• Should “out of band” (e.g. not associated with another request) client side requests be supported? If so, what’s the intended use case?

Related Issues

#192 - Allow MCP servers to “resume state”

#231 - API Defined and/or Client-Defined Session IDs

#282 - Streamable HTTP - session management inconsistency

#823 - Stateful stdio servers present a safety hazard for multi-conversation clients like Claude Desktop \