René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Clarifications on the intent/use-case for sessions","articleBody":"**Contributors:** @kurtisvg (on behalf of the Transport Working Group) \n\n## Why Sessions are currently problematic \n\nThere 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](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#session-management) only defines the session as (emphasis mine):\n\n\u003e An MCP “session” consists of **logically related interactions between a client and a server**, beginning with the initialization phase.\n\nHowever, 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: \n\n\u003e 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. \n\nWhen 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?\n\nAs part of trying to address these concerns, the transport working group has broken the use of sessions into two major categories:\n\n\n## Use-case A: “Transport” or “Tracking” sessions\n\nTransport sessions represent the state of communication with the _MCP client_. They are tied to the following information having been previously negotiated:\n\n1. Negotiated protocol version\n2. Client capabilities \n3. Server Capabilities \n\nIf 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.  \n\nHowever 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? \n\n\n## Use-case B: “Logical”, “Contextual”, or “User” sessions\n\nLogical 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: \n\n4. per LLM context window\n5. per application \n6. per account or user\n7. Out of band Elicitation / Sampling requests (e.g. not associated with an existing request)\n\nIf 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:\n\n```\nbegin_transaction()\nread_contents()\nwrite_contents()\nend_transaction()\n```\n\n\n## Request\n\nThe request from the transport working group is a request from the original contributors: \n\n\n\n*   What is the intended role of sessions? Are they supposed to be “transport” sessions or “logical” sessions? What use cases should be particularly covered? \n*    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? \n*   Should “out of band” (e.g. not associated with another request) client side requests be supported? If so, what’s the intended use case? \n\n\n## Related Issues\n\n[#192 - Allow MCP servers to “resume state”](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/192)\n\n[#231 - API Defined and/or Client-Defined Session IDs](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/231)\n\n[#282 - Streamable HTTP - session management inconsistency](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/282)\n\n[#823 - Stateful stdio servers present a safety hazard for multi-conversation clients like Claude Desktop](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/823) \\\n\n","author":{"url":"https://github.com/kurtisvg","@type":"Person","name":"kurtisvg"},"datePublished":"2025-07-16T21:12:02.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":7},"url":"https://github.com/984/modelcontextprotocol/issues/984"}