MCPに来る2つの拡張案──ツール結果の部分ストリーミングと進捗通知の構造化を、提案PRの本文で読む

3行まとめ

1. MCP（Model Context Protocol）のGitHubリポジトリに、tools/callの結果を完了前に部分ストリーミングできるようにするSEP-2998が2026年7月2日にPRとして提出されている。ステータスは「Draft」で、参照実装はまだ無い。
2. 同時期、進捗通知（notifications/progress）にこれまでのmessage文字列だけでなくevent/text/actor/dataを持つ構造化contentを追加するSEP-2632も2026年4月22日から出ているが、こちらのSEP本体ファイルのStatus欄は「idea」（PR本文にも「currently in idea status」と明記）で、SEP-2998の「Draft」より前の段階にある。
3. どちらも既存のクライアント・サーバーの動作を壊さない「追加のみ」の変更として設計されているが、SEP（MCP Enhancement Proposal）はDraft→In-Review→Acceptedという審査プロセスを経る必要があり、この記事執筆時点ではどちらもAcceptedに達していない。

何が提案されているか

MCPは、AIアシスタントが外部のツールやデータソースに接続するための共通規格で、Anthropicが2024年11月に発表し、現在はコミュニティで仕様を拡張し続けている（基本的な仕組みはMCPとはを参照）。その拡張プロセスがSEP（Specification Enhancement Proposal）で、GitHub上のPull Requestとして提案され、テンプレートに沿ってStatus（Draft/In-Review/Accepted/Rejected/Withdrawn/Final/Superseded/Dormant）とType（Standards Track/Informational/Process/Extensions Track）を明記する形式になっている。

今回見つかった2件は、どちらもツール呼び出しまわりの「途中経過をどう見せるか」を扱っている点で近い領域の提案だ。

SEP-2998: ツール結果の部分ストリーミング

現在のMCPではtools/callは「リクエスト→単一の最終レスポンス」という構造で、ツールが実行を終えるまでクライアント側は結果を受け取れない。SEP-2998は、サーバー側がnotifications/tools/partial_resultという新しい通知を使い、実行中に順序付きの構造化チャンクをストリーミングできるようにする提案だ。PR本文（著者kuwatly、2026-07-02提出）は、この仕組みをpartialResultsというクライアント側capabilityでオプトイン化し、最終的なCallToolResultは常に完全な形で返る（クライアントが対応していなくても、途中経過を全部落としても、最終応答は自己完結する）設計だと説明している。

PR本文が挙げる想定ユースケースは3つ。

PR本文は、この提案がSEP-1391・SEP-2133・SEP-2322・SEP-2632・SEP-2663など既存の複数のSEPと組み合わさる設計だとも書いており、後述のSEP-2632と地続きの提案であることが分かる。テスト状況の欄には「Draft SEPの提案段階であり、参照実装はまだ無い（SEPプロセス上、参照実装が要るのはAcceptedに達する前ではなく、その前段階の話として記録されている）」と明記されている。

SEP-2632: 進捗通知への構造化コンテンツ追加

もう一方のSEP-2632（著者stevehaertel、2026-04-22提出）は、進捗通知notifications/progressが今はmessageという人間可読な文字列1つしか運べないという制約を扱う。PR本文は、ツール・ワークフロー・マルチエージェントの場面では、進捗イベントが単一文字列以上の情報を運ぶ必要があるとして、event・text・actor・dataというフィールドを持つオプションのcontentを追加する提案をしている。ツール寄りの例ではdata.toolName・data.input・data.outputという兄弟フィールドの形も示されている。

PR本文によれば、この提案の動機の一部はLangflow側のIssue（langflow-ai/langflow#12828）で示された実証実験にあり、既存のmessageのみの仕組みでもネストした委任実行を透明化するUXが作れることを示しつつ、プロトコルレベルで構造化した方が良いという着想につながったとしている。「Breaking Changes」欄は明確に「No」で、messageしか使わない既存実装はそのまま動く設計だと書かれている。

SEP-2998には「前身」がある——2月にクローズされたPR #776

SEP-2998のPRコメント欄（この記事の執筆にあたりGitHub APIで取得）を見ると、著者kuwatly氏が最初のコメントでこう書いている。

this is the SEP-formatted resubmission of #776 that Jonathan invited when closing it [...]. It formalizes the resultToken/separate-notification design Mike proposed [...], and is intended to resolve the one-response-per-request objection Darrel raised [...]. Would appreciate your eyes on whether it lands that cleanly.

（これは、Jonathanがクローズ時に招いた形での、PR #776のSEP形式での再提出だ。Mikeが提案した resultToken／別通知方式の設計を正式化しており、Darrelが指摘した「1リクエストにつき1レスポンス」問題への異論を解消することを意図している。この着地がきれいに決まっているか、目を通してもらえるとありがたい）

実際にPR #776（「feat: add support for partial results and streaming responses」、2026年2月6日にクローズ）を確認すると、これは同じ「ツール結果の部分ストリーミング」というアイデアの以前の提案で、SEPプロセスを経ずに直接コードとして提案された結果クローズされ、SEP形式で出し直すよう著者が促されていたことが分かる。SEP-2998は真新しい思いつきではなく、半年ほど前の議論を土台にした2度目の挑戦だ。

SEP-2632は「スポンサーが見つからない」——bot からの催促コメントも

SEP-2632のPRコメント欄（同じくGitHub APIで取得、計6件）を読むと、この提案が抱える具体的な停滞理由が見えてくる。著者stevehaertel氏は2026年4月23日、CIチェックが通った直後にこう書いている。

Alright! All checks have passed Now I'm looking for a sponsor :) Any volunteers?

（よし、チェックは全部通った。これからスポンサーを探す。誰か立候補してくれる？）

SEPプロセスでは、提案がIn-Reviewに進むには既存のメンテナー・貢献者による「スポンサー」が必要な設計になっている。この提案には6月にkuwatly氏（SEP-2998の著者）から、MCP Apps文脈での具体的なユースケース（tool-input-partialはあるが出力側の段階的更新が無い、A2UIのストリーミングUIをMCP App内で動かしたい、など）を添えたコメントが2件つき、技術的な関心自体は集まっている。ところが2026年7月27日、自動化されたSEPライフサイクルbotがこう投稿している。

This SEP proposal has been inactive for 94 days. [...] Do you need help finding a sponsor?

（このSEP提案は94日間動きがありません。スポンサー探しに助けが必要ですか？）

これに対し著者は8月6日、「続けたいが、スポンサーを見つける助けが要る。kuwatly、あなたがスポンサーになってくれないか」と返信しており、この記事の確認時点（GitHub APIで2026年8月31日に再確認）でもPRはopenのままスポンサー未確定の状態が続いている。GitHub API上のPRメタデータでは、SEP-2998・SEP-2632ともstate: open・merged: falseで、それぞれ2026年7月29日・8月6日を最後に更新が止まっている。技術的な内容の是非以前に、「誰が責任を持って審査プロセスに乗せるか」という運営上のボトルネックが、少なくともSEP-2632では可視化されている。

2つのSEPの比較表

正直に測れなかったこと

この2件のPRが実際に「Accepted」まで進むかどうか、進むとしていつ着地するかはまだ分からない。しかも2件は同じ段階にいるわけではなく、SEP-2998のStatus欄は正規語彙の「Draft」だが、SEP-2632は同欄が「idea」（TEMPLATE.mdの正規語彙Draft/In-Review/Accepted/...には無い値）。PR本文は"The SEP is currently in idea status, consistent with the SEP workflow before a sponsor is assigned."と書いており、スポンサー未確定の段階を指す表記だと分かる。MCPのSEPプロセスはDraftの後にIn-Review・Acceptedという段階を踏む設計になっており、開発差分が入っている段階（open PR）と、仕様として正式に確定した段階（Accepted/Final）は別物として扱う必要がある。筆者はこの記事のために両PRの本文をcurlで取得して読んだが、SEPプロセス側のディスカッション（レビューコメントのスレッド）までは追っておらず、コミュニティの賛否がどちらに傾いているかは確認していない。日本語圏では、この記事作成時点でSEP-2998・SEP-2632という番号そのものへの言及記事は見当たらなかった（Zenn記事検索で該当ゼロ）。MCPの仕様は継続的に更新されており、この記事の内容が公開後も同じ状態であるとは限らない。

関連記事

• MCP（Model Context Protocol）とは
• プロンプトエンジニアリング入門