Authors: Jonathan Hefner (@jonathanhefner)
Status: Draft
Type: Standards Track
Created: 2025-08-12

Abstract

This SEP proposes changes to the Streamable HTTP transport in order to mitigate issues regarding resumability and long-running connections.

Motivation

The Streamable HTTP transport currently exhibits the following issues:

• Unable to resume without an initial SSE event

  If a server starts an SSE stream but a disconnection occurs before an event is sent, there is no way for the client to resume the stream, because resuming requires a Last-Event-ID.

  This is especially problematic because the spec says that disconnection should not be interpreted as the client cancelling its request.

• Servers must maintain potentially long-running connections

  The spec does not allow servers to close a connection while computing a result. In other words, barring client-side disconnection, servers must maintain potentially long-running connections.

• Clients may reconnect excessively

  There is no indication of how long clients should wait before attempting reconnection. If servers were allowed to disconnect at will, there is no established scheme to prevent clients from reconnecting immediately.

• TODO: elaborate on challenges for load-balanced servers concerning server-to-client requests

Proposed Changes

rel="stream" URL

When a server starts an SSE stream, it MAY send an HTTP Link header that includes a rel="stream" URL. The server MAY embed whatever values it chooses in the URL, such as a unique request ID; however, the URL MUST be same-origin (same scheme, hostname, and port) as the server URL.

In the event of a disconnection, the client SHOULD resume the SSE stream. To resume the stream the client MUST send a GET request to the rel="stream" URL instead of the typical /mcp endpoint.

When sending a GET request to the rel="stream" URL, the client SHOULD include an appropriate Last-Event-ID header (if possible), and the server MUST respect the Last-Event-ID header.

Rationale

The rel="stream" URL acts as a unique endpoint for clients to resume the stream, regardless of having received an initial event. It can also provide benefits with respect to routing.

An alternative would be to (automatically, transparently) send an empty initial SSE event with an event ID to prime the client to reconnect. However, the client will likely receive an HTTP header before it receives the first SSE event, reducing the window in which a network failure could prevent the client from receiving resumption information.

Note that neither approach fully eliminates that window of failure. To fully eliminate the window of failure, we should introduce a mechanism like idempotency tokens. However, that may impose a slightly higher burden on the server, may be relevant to other transports, and is outside the scope of this SEP.

Backward Compatibility

• New Client + Old Server: Server will not send header. No backward incompatibility as long as client supports the old way of resuming (GET /mcp).
• Old Client + New Server: Client will ignore header. No backward incompatibility as long as server supports the old way of resuming (GET /mcp).

Allow server to disconnect at will

Change this part of the spec:

The server SHOULD NOT close the SSE stream before sending the JSON-RPC response for the received JSON-RPC request

To say:

The server MAY close the connection before sending the JSON-RPC response if it has sent a Link header with a rel="stream" URL.

Furthermore, if the server does close the connection before sending the JSON-RPC response, at some point before closing the connection, the server SHOULD send the retry field in the stream.

The client SHOULD respect the retry field when resuming the stream.

Rationale

Servers may disconnect at will, avoiding long-running connections. Sending a retry field should prevent the client from hammering the server with inappropriate reconnection attempts.

Backward Compatibility

• New Client + Old Server: No backward incompatibility.
• Old Client + New Server: Client should interpret an at-will disconnect the same as a network failure. retry field is part of the SSE standard. No backward incompatibility if client already implements proper SSE resuming logic.

Multi-turn requests for server-to-client requests

When the server requires additional input from the client, it should send server-to-client requests (e.g., sampling requests) on the SSE stream. When the server wants to wait for input from the client, it MUST disconnect. The next time the client attempts to reconnect via the rel="stream" URL, the server MUST respond with HTTP status code 204 No Content (which is the standard mechanism to signal the end of an SSE stream).

When the client receives a request from the server over the SSE stream, it should process the request, but it MUST store its response in a buffer instead of sending it to the server. Once the SSE processing loop has been terminated due to the 204 No Content response, the client MUST POST its buffered responses (as a JSON array) to the rel="stream" URL.

Then, the server MUST respond with a new SSE stream, including a Link header with a rel="stream" URL.

This multi-turn interaction should repeat until the client has received the response to its original request.

Server algorithm:

1. Server sends messages, including server-to-client requests, until it wants to wait for input from the client.
2. Server disconnects.
3. When client GETs rel="stream" URL, server responds with 204 No Content.
4. When client POSTs input to rel="stream" URL, server returns new SSE stream, including new rel="stream" URL.
5. Go to step 1.

Client algorithm:

1. Client processes SSE stream events. If an event is a server-to-client request, client stores its response in a buffer.
2. When server disconnects, client attempts to reconnect but receives 204 No Content, signaling end of the SSE stream.
3. If there are buffered responses to server-to-client requests, client POSTs responses to rel="stream" URL.
4. Client receives new SSE stream from the POST.
5. Go to step 1.

Rationale

This feature allows the server to stop execution when input is required from the client. When the server receives a POST to the rel="stream" URL, it can use values embedded in the URL to look up state and resume execution, processing the POSTed input. Thus load-balanced server instances are able to resume execution and send the result directly to the client without sticky (pinned) sessions.

Backward Compatibility

• New Client + Old Server: Server will not send a rel="stream" URL. No backward incompatibility as long as client supports the old way of responding to a server-to-client request (POST /mcp).
• Old Client + New Server: Client will resume stream with GET /mcp and send input with POST /mcp. No backward incompatibility as long as server supports the old way of resuming and sending input.