Proposes an optional, capability-gated notifications/tools/partial_result
mechanism so servers can stream ordered, structured chunks during an
in-flight tools/call, with the final CallToolResult remaining the sole
authoritative response. Enables MCP Apps to stream progressive-UI formats
such as A2UI into their iframe within a single long-running tool call,
composes with Tasks (SEP-2663) and progress notifications, and stays
consistent with the 2026-07-28 baseline (per-request capability
declaration, no initialize handshake).

Cites and builds on prior art: #383, #651, #776 (closed), #982, SEP-1391,
SEP-2133, SEP-2322, SEP-2632, SEP-2663.

Motivation and Context

tools/call is strictly request → single final response today. This blocks
several concrete cases: LLM-backed tools that produce token streams but must
buffer everything before returning (#117); MCP Apps iframes, which get
partial input (ui/notifications/tool-input-partial) but no partial
output, so a long-running tool can only show a generic spinner and
progressive-UI formats like A2UI can't stream into the app; and
log/monitor-style tools that resort to polling workarounds. Full motivation,
prior-art comparison, and open questions are in the SEP itself.

How Has This Been Tested?

Not yet, this is a Draft SEP at the proposal stage, no reference
implementation exists yet (tracked in the SEP's Reference Implementation
section). Per the SEP process, a prototype is required before the SEP can
reach Accepted, not before opening this PR.

Breaking Changes

None. Fully additive: gated behind a new partialResults client capability,
and the final CallToolResult is always complete and self-contained even if
a client never declares support or drops every partial.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines (matches seps/TEMPLATE.md; npm run check passes)
• New and existing tests pass locally (npm run check: schema, docs, and SEP validation all pass)
• I have added appropriate error handling (N/A, this is a specification proposal, not an implementation)
• I have added or updated documentation as needed (this PR is the SEP document itself)

Additional context

This PR was drafted and researched with Claude Code. All cited issues, PRs,
and SEPs, and all schema/capability claims (ClientCapabilities shape, the
removal of initialize in favor of per-request _meta capabilities,
server/discover, the Tasks/SEP-2663 and MRTR/SEP-2322 interactions), were
independently verified against the GitHub API and this repo's own
schema/draft/schema.ts rather than taken from memory. I'm seeking a
sponsor per the SEP guidelines; no working group currently covers this area,
so I'll be posting in Discord #general as well.