What’s actually changing
The specification changelog states it directly:
“Eliminated
Last-Event-IDheader and SSE event IDs; broken streams require re-issuing as new requests”
This is a real reliability-handling change, not a cosmetic one. Client code with retry logic built around SSE resumption, catch the disconnect, reconnect with the last known event ID, keep receiving from that point, has no equivalent behavior to fall back to. The correct behavior now is treating a broken stream the same as a failed request: discard whatever partial state existed and start over.
Structural Comparison Matrix
| Operational Aspect | Before (SSE resumability) | After (2026-07-28+) |
|---|---|---|
| Stream drops mid-request | Reconnect with Last-Event-ID, resume in place | No resumption; re-issue the whole request |
| Client-side state to track | Last received event ID | None needed for this purpose |
| Retry logic shape | Reconnect-and-resume | Full request retry |
Fix it: replace resume logic with a full retry
Idempotency matters more now
If re-issuing a broken request as brand new could cause a duplicate side effect (creating a resource twice, for example, rather than resuming a read), that’s a real correctness risk this change surfaces. Confirm which of a client’s streamed operations are safe to retry outright versus needing an idempotency key or similar guard before relying on blind re-issue as the recovery strategy.
on stream error:
reconnect with header Last-Event-ID: <last received id>
continue receiving from that pointon stream error:
discard partial state from the broken stream
re-issue the original request as a new callAny client library or hand-rolled retry wrapper that specifically implements SSE reconnect-with-Last-Event-ID needs that code path removed and replaced with a plain retry of the original request, plus whatever idempotency handling the specific operation actually needs.
Confirmed version
Sourced from the official Model Context Protocol specification changelog, 2026-07-28 revision, published 2026-07-28. Browse more posts like this in the AI Productivity archive.
