After iterating on SEP-1699 in the TypeScript SDK (modelcontextprotocol/typescript-sdk#1129), I think a couple of areas would benefit from clarification on the SEP. Anecdotally C# SDKs and @mattzcarey working on this at Cloudflare ran into similar questions.

Discord discussion: https://discord.com/channels/1358869848138059966/1440314180245782681

cc: @jonathanhefner @mikekistler @mattzcarey @pja-ant @paoloricciuti @cliffhall @simonrussell

Spec clarifications I think would help SDK maintainers implement the SEP consistently:

1. Stream Model: Per-Request vs Standalone

• Should each POST request have its own resumable stream in addition to a stream ID?
• Or does everything go over the single standalone notification stream?
• Our interpretation: One stream per request, plus the standalone stream for notifications
• Of note: spec says "client MAY remain connected to multiple SSE streams simultaneously" but should likely clarify: multiple different streams allowed, not multiple connections to the same stream?
• Recommendation: specify that there should be one stream per request, but not multiple connections to the same stream.

2. POST vs GET for Resuming Interrupted Streams

• Spec resumability section suggests GET only for resumption
• However, existing taskResumability.test.ts uses POST with last-event-id in TypeScript (likely wrong)
• Recommendation: Clarify that ALL resumption requests should be GET, regardless of whether stream was initiated by POST

3. Event ID Format for Stream Correlation

• When multiple streams exist, how does the server know which stream a last-event-id belongs to?
• IDs can't be simple incrementing numbers (1, 2, 3...) across streams
• Recommendation: Suggest a format like streamId::sequence or note that IDs must encode stream identity for correlation

4. GET Stream Cancellation Scope

• Spec change focuses on POST requests specifically
• Should servers also be able to cancel the standalone GET notification stream?
• Recommendation: Clarify that SEP-1699 behavior applies to both POST and GET streams

5. SSE Spec References

• Where we rely on SSE standard behavior (e.g., retry field), explicitly link to the SSE spec
• Helps implementers understand which behaviors are inherited vs MCP-specific

6. Resumability vs Disconnection Unification

• Existing spec language around "disconnection" resumability may or may not apply to server-initiated closes
• Recommendation: Clarify these use the same mechanisms, or link sections together