MCP 2026-07-28版とは
MCP 2026-07-28版とは、AIと外部ツールをつなぐ共通規格である Model Context Protocol の最新仕様です。公式チェンジログは、前回の版である 2025-11-25 以降の変更をまとめたものだと明記しています。
MCP は、AIモデルが外部のツールやデータへ接続するための共通の約束事です。この規格に沿ってサーバーを用意しておけば、対応するAIツールから同じ手順で呼び出せます。Xが公開した公式MCPサーバーのように、サービス提供側が MCP サーバーを用意する例も増えています。
変更の中心は「状態を持たなくする」こと
今回の版で貫かれている方針は一貫しています。接続をまたいで状態を持つ仕組みを、プロトコルの中から取り除くというものです。
従来の MCP には、クライアントとサーバーのあいだで会話の状態を保持する仕組みがありました。接続時に initialize でお互いの能力を伝え合い、その後のやり取りはその前提を共有したまま進む。セッション ID を持ち回る設計です。
2026-07-28版はこれをやめました。すべてのリクエストが単独で完結する形に変わっています。
何が消えたのか
削除された要素は多岐にわたります。
2026-07-28版で削除された主な要素（公式チェンジログによる）
| 削除されたもの | 置き換わった仕組み |
|---|---|
プロトコルレベルのセッション／Mcp-Session-Id ヘッダー | サーバーが発行するハンドルを通常のツール引数で渡す |
initialize / notifications/initialized ハンドシェイク | 各リクエストが _meta でバージョンと能力を申告 |
HTTP GET エンドポイント／resources/subscribe 等 | subscriptions/listen（1本の長寿命 POST レスポンスストリーム） |
ping / logging/setLevel / notifications/roots/list_changed | ログ水準はリクエストごとに _meta で指定 |
サーバー起点のリクエスト（sampling/createMessage 等） | MRTR パターン（結果を返して再送で受け取る） |
SSEストリームの再開／メッセージ再送（Last-Event-ID） | 新しいリクエストIDで発行し直す |
これらはいずれも「主要な変更」として挙げられているもので、既存の実装に影響します。
This document lists changes made to the Model Context Protocol (MCP) specification since the previous revision, 2025-11-25. ／ Remove protocol-level sessions and the Mcp-Session-Id header from the Streamable HTTP transport. List endpoints (tools/list, resources/list, prompts/list) no longer vary per-connection. Servers that need cross-call state use explicit, server-minted handles passed as ordinary tool arguments (SEP-2567). — 対象となる版と、セッション廃止に関する記述より
セッション廃止で何が変わるか
ここが実装に最も響く部分です。
状態は「ツールの引数」として持ち回る
セッションが無くなると、呼び出しをまたいで状態を保ちたい場合に困ります。仕様はその答えも示しています。
サーバーが発行する明示的なハンドルを、通常のツール引数として渡すという方式です。プロトコルの裏側で暗黙に状態が引き継がれるのではなく、状態への参照が引数として表に出てきます。
暗黙の前提が減るぶん、何が起きているかは追いやすくなります。代わりに、状態を表す値を自分で定義して受け渡す責任がサーバーとツールの設計側に移りました。
引数として渡す値の構造を確認しながら組むと、実装時に詰まりにくくなります。
無料ツールJSON整形・検証JSONデータを見やすく整形＆構文エラーを検証。開発やAPI連携に必須。今すぐ使ってみる →
Servers that need cross-call state use explicit, server-minted handles passed as ordinary tool arguments (SEP-2567). — 呼び出しをまたぐ状態をハンドルとして引数で渡す方式に関する記述より
一覧が接続ごとに変わらなくなった
見落とされやすいのが、一覧取得の挙動が変わった点です。tools/list・resources/list・prompts/list は、もう接続ごとに違う結果を返しません。
これは制約であると同時に利点でもあります。同じ問い合わせに同じ答えが返るなら、キャッシュできるからです。実際、仕様は関連する変更も加えています。サーバーは tools/list の結果を毎回同じ並び順で返すことが推奨されており、その理由としてクライアント側のキャッシュとLLMのプロンプトキャッシュの命中率向上が挙げられています。
さらに、一覧系や resources/read の結果には ttlMs と cacheScope という2つのフィールドが必須になりました。ttlMs は鮮度の目安をミリ秒で示すもので、クライアントが応答をキャッシュしてポーリングを減らせるようにします。cacheScope は public か private で、経路の途中にあるキャッシュ機構が応答を保存してよいかを制御します。
Servers SHOULD return tools from tools/list in a deterministic order to enable client-side caching and improve LLM prompt cache hit rates. ／ Require ttlMs and cacheScope fields on results returned by tools/list, prompts/list, resources/list, resources/read, and resources/templates/list via a new CacheableResult interface. ttlMs is a freshness hint (in milliseconds) allowing clients to cache responses and reduce polling; cacheScope ("public" or "private") controls whether shared intermediaries may cache the response. — 一覧の決定的順序と、キャッシュ関連フィールドの追加に関する記述より
バージョンの申告は毎回行う
initialize が無くなったぶん、バージョンの擦り合わせ方も変わりました。
すべてのリクエストが _meta にプロトコルバージョンとクライアント能力を載せて運びます。クライアントは各リクエストで自分を名乗ることが推奨され、サーバーも各結果の _meta で自分を名乗ることが推奨されます。噛み合わない場合は UnsupportedProtocolVersionError が返ります。
あわせて server/discover という新しい呼び出しが追加されました。サーバーはこれを必ず実装しなければなりません。対応するプロトコルバージョン・能力・識別情報を知らせるためのもので、クライアントは他のリクエストの前に呼んで版を選ぶこともできますし、STDIO（標準入出力でやり取りする接続方式）では後方互換性の確認用としても使えます。
Make MCP stateless: remove the initialize/notifications/initialized handshake. Every request now carries its protocol version and client capabilities in _meta (io.modelcontextprotocol/protocolVersion, io.modelcontextprotocol/clientCapabilities). Clients SHOULD identify themselves on each request (io.modelcontextprotocol/clientInfo), and servers SHOULD identify themselves in each result's _meta (io.modelcontextprotocol/serverInfo). Version mismatches return UnsupportedProtocolVersionError (SEP-2575). ／ Add server/discover: servers MUST implement this RPC to advertise their supported protocol versions, capabilities, and identity. Clients MAY call it before any other request for up-front version selection, or use it as a backward-compatibility probe on STDIO (SEP-2575). — ステートレス化の内容と、server/discover の追加および呼び出し方に関する記述より
サーバーからの問い合わせ方が変わった
もうひとつ設計思想として大きいのが、サーバーが自分からリクエストを送る仕組みの廃止です。
MRTRという新しいやり方
従来は、サーバー側が処理の途中でクライアントに追加の情報を求めるとき、roots/list・sampling/createMessage・elicitation/create といったリクエストをサーバーから送っていました。これが MRTR（Multi Round-Trip Requests） というパターンに置き換わります。
新しい流れはこうです。サーバーは結果を返します。ただしその結果の resultType は input_required で、inputRequests フィールドに「処理を続けるために必要な情報の要求」が入っています。クライアントはそれを見て、元のリクエストを再送するときに inputResponses を添えて必要な情報を渡します。
サーバーが会話の主導権を握って割り込むのではなく、いったん返して、必要なものを揃えて出し直してもらう。リクエストとレスポンスの対応関係が単純になる方向の変更です。
追加情報が要るときの流れ（従来とMRTRの対比）
| 段階 | 従来（サーバー起点） | MRTR |
|---|---|---|
| きっかけ | サーバーが処理を止めてリクエストを送る | サーバーが結果を返す（resultType は input_required） |
| 要求の乗せ方 | roots/list・sampling/createMessage・elicitation/create | 結果の inputRequests フィールド |
| クライアントの応答 | サーバーからのリクエストへ返信 | 元のリクエストを再送し inputResponses を添える |
| 対応関係 | サーバー起点の往復が入れ子になる | 1リクエストに1レスポンスのまま |
これに合わせて、すべての結果に resultType フィールドが必須になりました。通常の結果は complete、MRTR の途中結果は input_required です。古い版のサーバーからこのフィールドが無い結果が返ってきた場合、クライアントは complete として扱わなければなりません。
Multi Round-Trip Requests (MRTR) pattern introduced which replaces the previous approach of sending server-initiated requests, such as roots/list, sampling/createMessage, or elicitation/create. Servers return an InputRequiredResult (resultType: "input_required") whose inputRequests field carries the requests for the additional information needed to process the request. Clients respond with inputResponses on a retry of the original request providing the requested information. (SEP-2322). ／ All results now carry a required resultType field: "complete" for ordinary results and "input_required" for multi round-trip request interim results. Clients MUST treat results from earlier-protocol servers that omit the field as "complete" (SEP-2322). — MRTR パターンの導入と、resultType フィールドの必須化に関する記述より
通知の流れも整理された
変更を知らせる仕組みも作り直されました。HTTP GET エンドポイントと resources/subscribe / resources/unsubscribe が、subscriptions/listen という1本の長寿命 POST レスポンスストリームに置き換わっています。
クライアントは受け取りたい種類を指定して申し込みます。ツール一覧の変更・プロンプト一覧の変更・リソース一覧の変更・リソース購読の4種類です。サーバーは受理を返し、通知には購読 ID を付けます。
ここで区別が必要なのは、リクエストに紐づく通知はこのストリームには流れないという点です。進捗通知やメッセージ通知は、従来どおりそのリクエスト自身の応答ストリームを流れます。監視系の通知と、処理中の通知が別経路になった、という整理です。
Replace the HTTP GET endpoint and resources/subscribe/resources/unsubscribe with subscriptions/listen: a single long-lived POST-response stream for opted-in server-to-client change notifications. Clients opt in to specific types (toolsListChanged, promptsListChanged, resourcesListChanged, resourceSubscriptions); the server acknowledges and tags notifications with io.modelcontextprotocol/subscriptionId. Request-scoped notifications such as notifications/progress and notifications/message continue to flow on the response stream of the request they relate to, not the subscriptions/listen stream (SEP-2575). — 通知の受け取り方の変更と、リクエスト単位の通知との区別に関する記述より
長時間の処理は公式拡張へ移った
実験的な位置づけだった tasks（長時間かかる処理を扱う仕組み）は、中核のプロトコルから外れて公式の拡張へ移動しました。
設計も作り直されています。応答を待ってブロックする tasks/result は廃止され、tasks/get によるポーリングに変わりました。クライアントからサーバーへ入力を渡す tasks/update が新設され、tasks/list は削除されています。またサーバーは、リクエストごとの明示的な同意なしにタスクのハンドルを返せるようになりました。
Move experimental tasks out of the core protocol and into an official extension (io.modelcontextprotocol/tasks). The redesigned extension replaces the blocking tasks/result method with polling via tasks/get and a new tasks/update for client-to-server input, removes tasks/list, and allows servers to return task handles unsolicited without per-request opt-in (SEP-2663). — tasks の拡張への移動と再設計に関する記述より
実装している場合に確認したいこと
既存の MCP サーバーやクライアントを動かしているなら、影響範囲の確認が要ります。
壊れる可能性が高い箇所
まずセッション ID に依存している実装です。Mcp-Session-Id ヘッダーを読んで状態を引き当てているサーバーは、そのままでは動きません。状態が要るなら、サーバー側で発行するハンドルをツールの引数として受け渡す形へ書き換えることになります。
次に接続断からの復帰処理です。SSE ストリームの再開機能が削除されたため、Last-Event-ID を使った途中再開はできません。切れたら処理中のリクエストは失われるので、新しいリクエスト ID を付けて出し直す必要があります。再送を前提にした設計になっているか確認しておくべきところです。
そして削除された呼び出しです。ping・logging/setLevel・notifications/roots/list_changed はいずれも無くなりました。ログの水準はリクエストごとに _meta で指定する方式に変わっており、この項目が無いリクエストに対してサーバーはメッセージ通知を出してはならないとされています。
Remove ping, logging/setLevel, and notifications/roots/list_changed. Log level is now set per-request via io.modelcontextprotocol/logLevel in _meta; servers MUST NOT emit notifications/message for requests that did not include this field (SEP-2575). ／ Remove SSE stream resumability and message redelivery (the Last-Event-ID header and SSE event IDs) from the Streamable HTTP transport. A broken response stream loses the in-flight request; clients MUST re-issue it as a new request with a new request ID (SEP-2575). — 削除された呼び出しと、ストリーム再開機能の廃止に関する記述より
細かいが効いてくる変更
主要な変更以外にも、実装に影響する調整が入っています。
リソースが見つからないときのエラーコードが -32002 から -32602（Invalid Params） へ変わりました。JSON-RPC（MCP が土台にしている、JSON で手続きを呼び出す規約）の仕様に合わせるための修正です。またエラーコードの割り当て方針が定められ、-32000 から -32019 は実装側が自由に使える範囲、-32020 から -32099 は MCP 仕様のために予約された範囲となりました。
入出力スキーマの制約も緩められています。inputSchema と outputSchema は JSON Schema 2020-12 のあらゆるキーワードを使えるようになり、structuredContent は任意の JSON 値を取れるようになりました。
こうしたスキーマやエラー応答を扱うときは、構造を確認しながら進めるのが確実です。
無料ツールJSON整形・検証JSONデータを見やすく整形＆構文エラーを検証。開発やAPI連携に必須。今すぐ使ってみる →
Change resource not found error code from -32002 to -32602 (Invalid Params) to align with JSON-RPC specification. ／ Define an error code allocation policy partitioning the JSON-RPC server-error range: -32000 to -32019 remains implementation-defined (existing SDK usage is grandfathered), -32020 to -32099 is reserved for the MCP specification. ／ Loosen inputSchema and outputSchema to allow any JSON Schema 2020-12 keywords, and structuredContent to allow any JSON value. — エラーコードの変更、割り当て方針、スキーマ制約の緩和に関する記述より
まとめ：プロトコルが引き受けていた複雑さが、実装側へ移った
2026-07-28版の MCP は、プロトコルの側で状態を管理するのをやめたというひと言に集約できます。セッションも初期化ハンドシェイクも消え、すべてのリクエストが単独で完結する形になりました。
利点は分かりやすいところです。リクエストが独立しているぶん、キャッシュしやすく、負荷分散もしやすくなります。一覧が接続ごとに変わらなくなり、決定的な順序が推奨され、キャッシュの有効期限まで結果に載るようになったのは、その方向を後押しする変更です。
一方で、プロトコルが暗黙に引き受けていた複雑さは消えたわけではなく、実装側へ移りました。状態が要るならハンドルを設計して引数で回す。接続が切れたら出し直す。以前は考えなくてよかったことを、サーバーとクライアントの設計で扱うことになります。
既存の実装を持っているなら、まずセッション ID への依存と接続断からの復帰処理を確認するのが出発点になります。削除された呼び出しの一覧は公式チェンジログにまとまっているので、そちらを当たるのが確実です。
同じ「足回りの設計で結果が変わる」という話は、ハーネスの設定でスコアが3倍になった事例やコンテキストエンジニアリングの考え方とも地続きです。MCP サーバーを実際に触ってみるなら、Xが公開した公式MCPサーバーが入り口として分かりやすいところです。
無料ツールJSON整形・検証JSONデータを見やすく整形＆構文エラーを検証。開発やAPI連携に必須。今すぐ使ってみる →
