Clarify SEP-1699: SSE stream resumption and polling

Addresses implementation ambiguities discovered during SDK development (modelcontextprotocol#1847):

1. GET streams support polling: Clarify that GET-initiated streams follow the
   same retry/polling behavior as POST streams when server closes connection
   without terminating the stream.

2. Resumption always via GET: Explicitly state that resumption via
   Last-Event-ID applies regardless of how the original stream was initiated
   (POST or GET).

3. Event IDs should encode stream identity: Add guidance that event IDs
   SHOULD contain sufficient information to identify the originating stream,
   enabling servers to correlate Last-Event-ID to the correct stream.

4. Add SSE spec link for `retry` field: Link to the SSE standard for the
   retry field behavior.

5. Clarify disconnection scope: "Broken connection" includes server-initiated
   disconnection, not just network failures.

Author: felixweinberger

docs/specification/draft/basic/transports.mdx

@@ -111,7 +111,7 @@ MCP endpoint.
      at any time in order to avoid holding a long-lived connection. The client
      **SHOULD** then "poll" the SSE stream by attempting to reconnect.
    - If the server does close the _connection_ prior to terminating the _SSE stream_,
-     it **SHOULD** send an SSE event with a standard `retry` field before
+     it **SHOULD** send an SSE event with a standard [`retry`](https://html.spec.whatwg.org/multipage/server-sent-events.html#the-retry-value) field before
      closing the connection. The client **MUST** respect the `retry` field,
      waiting the given number of milliseconds before attempting to reconnect.
    - The SSE stream **SHOULD** eventually include a JSON-RPC _response_ for the
@@ -148,6 +148,9 @@ MCP endpoint.
      [resuming](#resumability-and-redelivery) a stream associated with a previous client
      request.
    - The server **MAY** close the SSE stream at any time.
+   - If the server closes the _connection_ without terminating the _stream_, it
+     **SHOULD** follow the same polling behavior as described for POST requests:
+     sending a `retry` field and allowing the client to reconnect.
    - The client **MAY** close the SSE stream at any time.
 
 ### Multiple Connections
@@ -168,15 +171,20 @@ lost:
    - If present, the ID **MUST** be globally unique across all streams within that
      [session](#session-management)—or all streams with that specific client, if session
      management is not in use.
-2. If the client wishes to resume after a broken connection, it **SHOULD** issue an HTTP
-   GET to the MCP endpoint, and include the
+   - Event IDs **SHOULD** encode sufficient information to identify the originating
+     stream, enabling the server to correlate a `Last-Event-ID` to the correct stream.
+2. If the client wishes to resume after a disconnection (whether due to network failure
+   or server-initiated closure), it **SHOULD** issue an HTTP GET to the MCP endpoint,
+   and include the
    [`Last-Event-ID`](https://html.spec.whatwg.org/multipage/server-sent-events.html#the-last-event-id-header)
    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.
+   - This mechanism applies regardless of how the original stream was initiated (via
+     POST or GET). Resumption is always via HTTP GET with `Last-Event-ID`.
 
 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.

docs/specification/draft/changelog.mdx

@@ -26,9 +26,10 @@ the previous revision, [2025-06-18](/specification/2025-06-18).
 3. Updated the [Security Best Practices guidance](https://modelcontextprotocol.io/specification/draft/basic/security_best_practices).
 4. Clarify that input validation errors should be returned as Tool Execution Errors rather than Protocol Errors to enable model self-correction ([SEP-1303](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1303)).
 5. Support polling SSE streams by allowing servers to disconnect at will ([SEP-1699](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1699)).
-6. Align OAuth 2.0 Protected Resource Metadata discovery with RFC 9728, making `WWW-Authenticate` header optional with fallback to `.well-known` endpoint ([SEP-985](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/985)).
-7. Add support for default values in all primitive types (string, number, enum) for elicitation schemas ([SEP-1034](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1034)).
-8. Establish JSON Schema 2020-12 as the default dialect for MCP schema definitions ([SEP-1613](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1613)).
+6. Clarify SEP-1699: GET streams support polling, resumption always via GET regardless of stream origin, event IDs should encode stream identity, disconnection includes server-initiated closure (Issue [#1847](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1847)).
+7. Align OAuth 2.0 Protected Resource Metadata discovery with RFC 9728, making `WWW-Authenticate` header optional with fallback to `.well-known` endpoint ([SEP-985](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/985)).
+8. Add support for default values in all primitive types (string, number, enum) for elicitation schemas ([SEP-1034](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1034)).
+9. Establish JSON Schema 2020-12 as the default dialect for MCP schema definitions ([SEP-1613](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1613)).
 
 ## Other schema changes