MCP仕様のバージョン履歴 — 2024年11月から5回の改訂を一覧する
MCPの仕様は2024-11-05から2026-07-28まで5つのリビジョンを重ねた。何が追加され、何が消えたかを1つの時系列表で確認する。
MCPの現行仕様は2026-07-28、5回の改訂を経てここまで来た
MCP(Model Context Protocol)の仕様はYYYY-MM-DD形式のバージョン識別子を使い、後方互換性のない変更を加えた最後の日付を表します。互換性を保つ変更なら、バージョン番号は上がりません。
これまでに5つのリビジョンがあり、現行(Current)は2026-07-28です。2024-11-05、2025-03-26、2025-06-18、2025-11-25の4つは、変更のない「Final」として固定されています。過去のリビジョンを参照する実装が、仕様の書き換えで突然壊れることはありません。変わるのは常に新しいリビジョンの側です。
バージョン番号の読み方 — セマンティックバージョニングではない
2.1.5のような番号に慣れていると誤解しやすい点ですが、MCPのバージョン番号はリリース連番ではなく日付そのものです。「メジャー・マイナー・パッチ」の区別はありません。後方互換の変更は同じ番号のまま加わり、互換性を壊す変更があった日だけ新しい日付が刻まれます。
このため、変更の量や重さは番号の差から読めません。知るにはリビジョンごとのChangelogを見ます。各Changelogの末尾にはGitHub上のリビジョン間の差分リンクがあり、要約で足りない実装者はスキーマ差分まで遡れます。
5つのリビジョンで何が変わったか
MCP仕様のリビジョン年表
- 2024-11-05土台になった最初のリビジョン
ツール・リソース・プロンプトの3つの概念と、当時唯一のリモートトランスポートだったHTTP+SSEを定義しました。ツールの性質を示す仕組みはまだなく、コンテンツ形式はテキストと画像が中心でした。
- 2025-03-26認可の追加とトランスポートの入れ替え
OAuth 2.1ベースの認可フレームワークが入り、HTTP+SSEはStreamable HTTPに置き換わりました。ツールアノテーション(読み取り専用か破壊的かなどの表示)と、JSON-RPCのバッチ処理も加わっています。コンテンツ形式には音声が加わりました。
- 2025-06-18バッチ処理の削除とElicitationの追加
追加したばかりのJSON-RPCバッチ処理を削除しました。入れ替わりに、サーバーがユーザーへ追加の入力を求めるElicitation、構造化ツール出力、ツール結果へのリソースリンクが入っています。HTTPでは、交渉済みのバージョンを
MCP-Protocol-Versionヘッダーで毎回送る要件も加わりました。 - 2025-11-25メタデータと実験的機能の拡充
ツール・リソース・プロンプトへのアイコン付与、ツール名のガイダンス、ElicitationのURLモード、Samplingのツール呼び出し対応が入りました。実験的機能のTasksが初めて登場したのもこの回です。JSON Schema 2020-12が既定の方言に定まり、不正なOriginにはHTTP 403を返す扱いも入りました。
- 2026-07-28接続モデルの土台を入れ替え
initializeハンドシェイクを廃止してステートレス化し、サーバーの対応バージョンを尋ねるserver/discoverを新設しました。Streamable HTTPからはプロトコルレベルのセッションとMcp-Session-Idヘッダーが消え、resources/subscribeはsubscriptions/listenの単一ストリームに統合されています。Tasksは拡張機能(io.modelcontextprotocol/tasks)としてコアの外へ出ました。
追加の翌回に消えた機能と、長く残った機能
改訂の系譜は、機能が一直線に増えていく形をしていません。追加から1リビジョンで引っ込んだものがあり、逆に何回も持ちこたえてから置き換わったものもあります。
寿命が極端に違う機能
追加の次の回に消えた
- JSON-RPCバッチ処理: 2025-03-26で追加、2025-06-18で削除
notifications/elicitation/complete通知とURLモードのelicitationId: 2025-11-25で追加、2026-07-28で削除
置き換えの後も長く残った
initialize/notifications/initializedハンドシェイク: 2024-11-05から2025-11-25の4リビジョンで使われ、2026-07-28で廃止- HTTP+SSEトランスポート: 2025-03-26でStreamable HTTPに置き換わったが残り、2026-07-28で非推奨(Deprecated)へ再分類
HTTP+SSEが非推奨に至るまでの経緯は、HTTP+SSEの非推奨化の記事で追っています。同じ再分類で、includeContextの"thisServer"と"allServers"も非推奨になりました。省略するか"none"へ移行します。これらの値は、Sampling本体より遅れずに削除されます。
2026-07-28では、サーバーからクライアントへ質問を送る方式も入れ替わりました。roots/list・sampling/createMessage・elicitation/createのようなサーバー起点のリクエストに代わり、サーバーがInputRequiredResultを返し、クライアントがinputResponsesを載せて元のリクエストを再試行します。詳しくはMRTR(Multi Round-Trip Requests)の解説にあります。
認可は4回連続で手直しされてきた
初版になかった認可の仕組みは、4つのリビジョンにわたって手が入っています。
2025-03-26でOAuth 2.1ベースの認可フレームワークが入りました。2025-06-18ではMCPサーバーをOAuthのリソースサーバーとして分類し、悪意あるサーバーによるアクセストークンの不正取得を防ぐため、クライアントにResource Indicators(RFC 8707)の実装を求めています。
2025-11-25では認可サーバーの発見をOpenID Connect Discoveryに対応させ、WWW-Authenticateヘッダーによる段階的なスコープ同意を加えました。クライアント登録の推奨手段としてOAuth Client ID Metadata Documentsが入ったのもこの回です。
2026-07-28では、そのClient ID Metadata Documentsが正式な移行先になり、OAuth 2.0 Dynamic Client Registration(RFC 7591)が非推奨に回りました。ただし認可サーバーがClient ID Metadata Documentsに対応していない場合に備え、Dynamic Client Registrationは後方互換のために残されています。細かい変更も続きました。
- 認可サーバーが認可レスポンスに
issパラメーター(RFC 9207)を含めるのが推奨になり、クライアントはissがあれば記録済みの発行者と照合する必要がある - Dynamic Client Registrationでは、クライアントが適切な
application_typeを指定する - 保存したクライアント資格情報は発行した認可サーバーごとに管理し、認可サーバーが変わったら再登録する
認可まわりは、1回のリビジョンで完成させずに、毎回前のリビジョンの穴を埋めてきた領域です。実装の詳細はMCPの認可とセキュリティ考慮事項で扱っています。
改訂の間隔は約2.8か月から約8か月まで開いた
リビジョン間の日数
2024-11-05 → 2025-03-26
141日
約4.6か月
2025-03-26 → 2025-06-18
84日
約2.8か月
2025-06-18 → 2025-11-25
160日
約5.3か月
2025-11-25 → 2026-07-28
245日
約8か月
最初の3回は約2.8〜5.3か月でした。直近は8か月で、最短だった2025-03-26 → 2025-06-18のおよそ3倍です。この間隔から次の改訂時期は読めないので、新しいリビジョンが出るたびにChangelogで確認するのが実態に合います。
2026-07-28で非推奨になったRoots・Sampling・Loggingには、削除までの最短期間が決まっています。機能ライフサイクルのポリシーでは、非推奨の機能は少なくとも12か月は仕様に残ります。緊急削除の例外でも90日です。Roots・Sampling・Loggingは非推奨の期間中も完全に動くので、削除前に移行する猶予があります。推奨される移行先は、Rootsなら別の手段(ツールのパラメーター、リソースURI、サーバー設定)、SamplingならLLMプロバイダーのAPIへの直接接続です。Loggingなら、stdioではstderrへの出力、可観測性にはOpenTelemetryが挙げられています。非推奨レジストリは、削除の対象を2027-07-28以降に最初に出るリビジョンとしています。ポリシーの全文はMCP仕様の改訂ライフサイクルにあります。
自分の実装はどの変更に当たるか
自分が使っているクライアントやサーバーが、どのリビジョンの変更に関係するかは、実装が呼んでいるメソッドから逆引きできます。
依存しているリビジョンの調べ方
- 1
交渉されたバージョンを確認する
2026-07-28では、すべてのリクエストが
_metaのio.modelcontextprotocol/protocolVersionでバージョンを宣言し、サーバーはリクエストごとに受け入れるか拒否します。Streamable HTTPではMCP-Protocol-Versionヘッダーにも同じ値が載ります。 - 2
使っているメソッドを下の表と突き合わせる
実装が呼んでいるメソッドやエラーコードのうち、表にあるものは2026-07-28で挙動が変わります。
- 3
非推奨レジストリを確認する
非推奨レジストリで、Roots・Sampling・Logging・Dynamic Client Registrationそれぞれの削除対象リビジョンを確かめます。
| 実装が依存している点 | 変わったリビジョン | 変更の内容 |
|---|---|---|
| JSON-RPCの配列(バッチ)送信 | 変わったリビジョン2025-06-18 | 変更の内容バッチ処理を削除 |
initializeで接続状態を作る | 変わったリビジョン2026-07-28 | 変更の内容ハンドシェイクを廃止。各リクエストが_metaでバージョンを宣言 |
Mcp-Session-Idでセッションを識別 | 変わったリビジョン2026-07-28 | 変更の内容プロトコルレベルのセッションを削除 |
resources/subscribe・resources/unsubscribe | 変わったリビジョン2026-07-28 | 変更の内容subscriptions/listenへ置き換え |
Last-Event-IDによるSSEストリームの再開 | 変わったリビジョン2026-07-28 | 変更の内容再開と再配信を削除。切れたストリームのリクエストは新しいIDで再発行 |
ping・logging/setLevel | 変わったリビジョン2026-07-28 | 変更の内容削除。ログレベルは_metaのio.modelcontextprotocol/logLevelでリクエストごとに指定 |
tasks/list・tasks/result | 変わったリビジョン2026-07-28 | 変更の内容Tasks拡張へ移行。tasks/listは削除、tasks/resultはtasks/getのポーリングに置き換え |
リソース未発見をエラーコード-32002で判定 | 変わったリビジョン2026-07-28 | 変更の内容-32602(Invalid Params)に変更 |
エラーコードについては、2026-07-28でJSON-RPCのサーバーエラー範囲の割り当て方針も決まりました。-32000から-32019は実装定義のままで、-32020から-32099はMCP仕様用に予約されています。この回に導入されたエラーコードは、HeaderMismatchが-32020、MissingRequiredClientCapabilityが-32021、UnsupportedProtocolVersionが-32022に採番し直されました。詳細はエラーコード割り当てポリシーの解説を参照してください。
2026-07-28には、一覧系のリクエストの結果にttlMsとcacheScopeを必須で載せる変更もあります。詳しくはキャッシュ指定の解説にあります。
この回では、すべての結果にresultType(completeかinput_required)が必須になり、tasks/updateが加わりました。Streamable HTTPのPOSTでは、Mcp-MethodとMcp-Nameの標準ヘッダーも必須になり、notifications/roots/list_changedは削除されています。
まとめ — どこから読むか
最新リビジョンでの接続の実務はMCPクライアントの仕組みに、MCP全体の基礎はMCPとはにあります。