Add SEP-2998: Partial Tool Results (streaming tool call output)#2998
Add SEP-2998: Partial Tool Results (streaming tool call output)#2998kuwatly wants to merge 2 commits into
Conversation
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: modelcontextprotocol#383, modelcontextprotocol#651, modelcontextprotocol#776 (closed), modelcontextprotocol#982, SEP-1391, SEP-2133, SEP-2322, SEP-2632, SEP-2663.
PR modelcontextprotocol#2998 opened against modelcontextprotocol/modelcontextprotocol. Renamed the SEP file to its assigned number, updated the header and PR field, and regenerated docs/seps/ and docs/docs.json accordingly.
|
@CaitieM20, you're my first ask, given your work on Tasks (SEP-2663) and MRTR (SEP-2322): this composes directly with Tasks and is built on the stateless per-request capabilities model, staying consistent with the MRTR direction by using one-way notifications on the in-flight request's stream rather than server-initiated requests. Would you consider sponsoring? @jonathanhefner @mikekistler, this is the SEP-formatted resubmission of #776 that Jonathan invited when closing it (#776 (comment)). It formalizes the resultToken/separate-notification design Mike proposed (#776 (comment)), and is intended to resolve the one-response-per-request objection Darrel raised (#776 (comment)). Would appreciate your eyes on whether it lands that cleanly, happy to adjust if it doesn't. |
Proposes an optional, capability-gated
notifications/tools/partial_resultmechanism so servers can stream ordered, structured chunks during an
in-flight
tools/call, with the finalCallToolResultremaining the soleauthoritative 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
initializehandshake).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/callis strictly request → single final response today. This blocksseveral 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 partialoutput, 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
partialResultsclient capability,and the final
CallToolResultis always complete and self-contained even ifa client never declares support or drops every partial.
Types of changes
Checklist
seps/TEMPLATE.md;npm run checkpasses)npm run check: schema, docs, and SEP validation all pass)Additional context
This PR was drafted and researched with Claude Code. All cited issues, PRs,
and SEPs, and all schema/capability claims (
ClientCapabilitiesshape, theremoval of
initializein favor of per-request_metacapabilities,server/discover, the Tasks/SEP-2663 and MRTR/SEP-2322 interactions), wereindependently verified against the GitHub API and this repo's own
schema/draft/schema.tsrather than taken from memory. I'm seeking asponsor per the SEP guidelines; no working group currently covers this area,
so I'll be posting in Discord
#generalas well.