Conversation
| **Core Principle: Adapted Cookie Semantics** | ||
|
|
||
| * **RFC 6265 as a Foundation:** We will use **RFC 6265 (HTTP Cookies)** as a functional starting point to determine necessary adaptations for MCP. | ||
| * **Payload Integration:** Session data will primarily be included as a dedicated field within the JSON-RPC payload. We will look to **SEP-1655** and **SEP-1685** for inspiration on structuring this metadata. |
There was a problem hiding this comment.
The payload integration is how we'll support this on stdio, right? I believe that was the plan, but wanted to verify that, as most of the discussion is (rightly) focused on HTTP servers.
There was a problem hiding this comment.
One of my interest is WebSocket transport which has the same problem as stdio in that it doesn't have headers. I too want to see everything necessary to maintain session in the JSON-RPC payload. I also use HTTP POST transport but not SSE HTTP GET. I believe that spec is still quite difficult to implement and while I hope this work fixes that, I see WebSockets as a much better alternative to streaming with SSE HTTP.
There was a problem hiding this comment.
Principle has been agreed that payload content can be duplicated to headers if wanted. STDIO would need "cookie" data in JSON-RPC
There was a problem hiding this comment.
Content is required in JSON-RPC package for transports that don't have header-like side-channels (WebSockets, gRPC etc).
|
|
||
| **Key Requirements** | ||
|
|
||
| * **Routing Compatibility & Size Constraints:** To allow load balancers to route requests based on session affinity, we may need to copy the session identifier/token into an HTTP header. This introduces strict **size constraints**; the session token must remain small enough to fit within standard header limits (typically \~4KB), prohibiting large state blobs from being stored directly in the token. |
There was a problem hiding this comment.
Should we impose a size limit here? This is dependent on the network infra and is typically configurable - it looks like only Nginx has a 4KB limit by default. It would likely be inadvisable to have even a 4KB header, but I believe that server operators will generally be able to determine what reasonable limits look like for their particular setups.
There was a problem hiding this comment.
Absolute minimum is SessionID/Version. Resumption/Last-Known-Id. <-- next layer of design.
- Limit to SessionId Only (minimum for supporting routing)
- Keep the session envelope open with an arbitrary size limit.
- Keep it open with no size limit
Constrained by common infrastructure limitations. Question to infra specialists -> what are the hard constraints.
There was a problem hiding this comment.
What is the SDK experience from a Client/Server perspective.
| **Key Design Decision: Lifecycle Management** | ||
|
|
||
| * **Implicit vs. Explicit:** We must decide between allowing lazy initialization (Implicit) versus requiring a formal setup handshake (Explicit). | ||
| * *Consideration:* The need to **copy or fork** session data (e.g., branching an agent's state) strongly suggests preferring an **Explicit** mechanism (e.g., `session/create`, `session/fork`) to ensure these operations are predictable and race-free. |
There was a problem hiding this comment.
I don't believe forking sessions needs its own explicit RPC method, but that depends on our contract for cookie formats. I would expect that if I (as a client) save the current cookie at each point in the conversation, I can simply roll back to an old conversation state and do something different, and if that implies a different change to the session state, I'll just wind up receiving a new cookie instead. In other words, all cookies are always valid and immutable state objects by default.
I'm not strongly opinionated on this, however - I just don't see any obvious use cases where this would both (1) not hold true and (2) simultaneously allow forking a session. For example, if I have a single-use cookie and make a request with it, that cookie value is invalidated and I probably can't fork off it, either.
I do think explicit session creation is a good idea, however.
There was a problem hiding this comment.
Yes to session/create and session/destroy. I too don't see a use case for session/fork
| **Key Requirements** | ||
|
|
||
| * **Routing Compatibility & Size Constraints:** To allow load balancers to route requests based on session affinity, we may need to copy the session identifier/token into an HTTP header. This introduces strict **size constraints**; the session token must remain small enough to fit within standard header limits (typically \~4KB), prohibiting large state blobs from being stored directly in the token. | ||
| * **Security & Integrity:** Servers utilizing cookies must encrypt or sign the data to prevent client-side tampering. We will evaluate including a standard mechanism for signing/encryption directly in the spec. |
There was a problem hiding this comment.
I agree with this, but I believe we need to explicitly justify why we want to go beyond RFC 6265 and require this when most applications use unsigned cookies all the time without problems. Some good reasons I can think of:
- Unlike a website, MCP host applications are server-agnostic, and an agent or host application has little reason to directly alter a server-provided cookie in the first place.
- This is (at least in isolation) privacy-preserving; it's not possible for to add fingerprinting to a signed cookie - of course, tools themselves don't have this property, so it's a bit moot, but at least it doesn't make things worse.
There was a problem hiding this comment.
I'll take a stronger position against this requirement. It's added complexity. At the very least, I believe this should be no more than "MAY" with guidance on how to do it if they include it but I believe this does more harm than good. As Luca said, headers are sent unencrypted all the time, but I'll also add that the information we're talking about adding there is not particularly sensitive.
There was a problem hiding this comment.
On the other hand, requiring cookies to have these options: Secure, HttpOnly, SameSite=Strict|Lax makes sense. Also having a narrow path/domain restrictions is good practice.
There was a problem hiding this comment.
Do we need security beyond the current specification level (e.g. signing and encryption of content). This is not an application layer concern.
|
|
||
| Sessions are created by the Client (Host) and resumable, with the option of the Agent replaying messages to rehydrate Client state. There is no "close" operation. | ||
|
|
||
| Sessions are well specified with a unique session identifier, multiplexing and sequences of Prompt Turns between Client and Agent. Sessions in ACP are a user level abstraction. ACP is currently STDIO only with an HTTP transport "in progress". |
There was a problem hiding this comment.
ss-> interesting design, not sure how related this specifically is to MCP. It is a high level application protocol.
|
|
||
| ##### MCP/ACP transport (MCP over ACP) | ||
|
|
||
| https://agentclientprotocol.com/rfds/mcp-over-acp |
There was a problem hiding this comment.
Is reusing or incorporating an ACP Session Id worthwhile.
|
|
||
| This pattern is potentially unreliable due to LLM generation being potentially unreliable but works in practice. | ||
|
|
||
| Promoting this technique to a determenistic side-channel is a possibility. |
There was a problem hiding this comment.
| Promoting this technique to a determenistic side-channel is a possibility. | |
| Promoting this technique to a deterministic side-channel is a possibility. |
|
|
||
| **Key Design Decision: Lifecycle Management** | ||
|
|
||
| > (Gabriel Z) Another key decision is around parallel tool calling. I think the decision was that parallel tool calling would just overwrite the session data nondeterministically if multiple tools decided to add session data. It could be good to at least add a warning to that effect. |
There was a problem hiding this comment.
I think that there are two distinct use-cases here: per-session state, and per-tool-call state.
I think per-session state is in scope for the session track, and I think HTTP cookies can work pretty well for this. The idea behind using cookies for session data is that the client can basically use a different cookie jar for each session, and it's totally up to the server as to how and when to update the cookies within that session. So, for example, the session/create RPC would wind up creating a cookie indicating the session ID, which the client would then store in its cookie jar and therefore send with every subsequent RPC in that session. The server can decide in its response to any of those RPCs that it wants to set an additional cookie, and that's fine -- there's a fair amount of flexibility there for server implementations. (Clients that don't support sessions would just use a single cookie jar for all RPCs.)
I don't think per-tool-call state is in scope for the session track; instead, I think that should be addressed as part of the multi round-trip requests track, and there's already some discussion about this in the multi round-trip request track's brief doc. To summarize, I don't think the HTTP cookie approach will work very well for per-tool-call state, specifically because there can be multiple tool calls in flight in parallel (either within a session or not). The server implementation would need some way to know what cookie name to use for the state for each in-flight tool call, or else the cookie data would simply conflict, so we'd need to provide some way to do that. And it also doesn't seem to scale very well to have every tool call include cookies for state for every other tool call that is in flight at the same time. I think that instead, we'll wind up wanting something more like SEP-1685 here.
4 participants
Add the Session Track briefing document to the repository.
Motivation and Context
To generate a PR to collect first round of reviews and comments.
How Has This Been Tested?
Breaking Changes
Types of changes
Checklist
Additional context