Summary

Draft SEP proposing tasks/stream and notifications/tasks/event for resumable, sequenced task event delivery.

• Defines a client-initiated tasks/stream request that starts or resumes streaming events for a task
• Delivers events as notifications/tasks/event with task-scoped sequence numbers and vendor-prefixed event types
• Clients resume after disconnect with an after cursor; servers replay retained events or return events_gone
• Positions as the resumable delivery channel complementary to subscriptions/listen (SEP-2575), which explicitly defers durable delivery
  to the tasks primitive

Two requirements distinguish this from prior streaming work

1. Resumability: clients can resume after a specific task event sequence number
2. Extensibility: servers can emit vendor-prefixed event types with arbitrary JSON payloads

Relationship to other proposals

• SEP-2663 (Tasks Extension): foundation — this SEP builds on top
• SEP-2679 (partial results): complementary — partial content can be carried as a prefixed event type
• SEP-2669 (steer/pause/resume): complementary — this SEP provides the observability channel for interaction methods
• SEP-2575 (subscriptions/listen): complementary reliability tiers — subscriptions/listen is fire-and-forget; tasks/stream is resumable

Motivation and Context

Tasks (SEP-1686 / SEP-2663) support long-running work but provide no standard way to observe intermediate execution — tool calls,
assistant deltas, subagent lifecycle, artifacts. Clients are limited to polling tasks/get for coarse status or receiving fire-and-forget
notifications/tasks/status that can't be replayed after disconnect. SEP-2575 explicitly removed resumable SSE streams, stating that
durable delivery should use the tasks primitive — but no such mechanism exists yet. This SEP fills that gap.

How Has This Been Tested?

We have a private implementation of this. No public reference implementation yet.

##Breaking Changes

None. This SEP is additive. Servers that don't support tasks/stream return -32601. Existing task clients and servers are unchanged.

Types of changes

• New feature (non-breaking change which adds functionality)

Additional context

Open questions

1. Should the events_gone error code be standardized across MCP?
2. How should multiple clients streaming the same task interact with retention policies?
3. Should notifications/tasks/partial (SEP-2679) remain separate alongside prefixed task events?
4. Should task event streaming remain a separate tasks/stream request, or be folded into subscriptions/listen with task-scoped resume
   extensions?