Description
The MCP Streamable HTTP transport spec has a section on "Resumability and Redelivery" that "MAY" be supported by the server and "SHOULD" be supported by the client. We currently support it in neither case, although client support seems the easier of the two since we wouldn't have to worry about how to store messages and for how long.
Resumability and Redelivery
To support resuming broken connections, and redelivering messages that might otherwise be
lost:
- Servers MAY attach an
idfield to their SSE events, as described in the
SSE standard.
- If present, the ID MUST be globally unique across all streams within that
session—or all streams with that specific client, if session
management is not in use.- If the client wishes to resume after a broken connection, it SHOULD issue an HTTP
GET to the MCP endpoint, and include the
Last-Event-ID
header to indicate the last event ID it received.
- The server MAY use this header to replay messages that would have been sent
after the last event ID, on the stream that was disconnected, and to resume the
stream from that point.- The server MUST NOT replay messages that would have been delivered on a
different stream.In other words, these event IDs should be assigned by servers on a per-stream basis, to
act as a cursor within that particular stream.
As part of this work, we should reevaluate whether we are cancelling things like tool call operations when the underlying Streamable HTTP POST request is aborted in cases where resumability/redelivery has not been enabled.