2026-07-28のステートレス化で足場は整った。公式ロードマップが次に狙うのは「ポーリングをやめる」「輸送を1本化する」「APIキーを卒業する」「ツール一覧を全部渡さない」の4点。自作MCPサーバーが今のうちに備えておける形を、一次情報から拾う。
MCP公式ブログ「New MCP Roadmap」の4つの柱（サーバープッシュ通知・輸送層統一・認証刷新・段階的ツール発見）を実装者目線で翻訳し、「今のコードのどこが将来この変更にぶつかるか」を先に点検できるチェックリストにする。
2026-07-28、MCP（Model Context Protocol）は双方向ステートフルな設計から、1回のHTTPリクエストで完結するステートレスなモデルへ移行した（この変更は以前の記事で扱った）。プロトコルレベルのセッションと初期化ハンドシェイクが消え、サーバーは状態を抱えずに水平スケールできるようになった。
公式ロードマップ記事はこの変更を前提条件として位置づけている。原文の言い方を借りれば「protocol-level sessions and the initialization handshake are gone, so a server can scale horizontally without holding state」——つまりステートレス化は目的ではなく、次にやりたいことのための土台だった。次に何が来るかが分かれば、今書いているMCPサーバー・クライアントの設計判断を先取りできる。
原文の課題認識：「Modern agentic workloads no longer fit the standard request-and-response pattern」
クライアントがサーバーの変化を待ち受ける仕組み自体は既に実装済み。ロードマップが新しく狙っているのは、これをもう一段押し進めることだ。
非同期の長時間タスクをMCPの一級市民として扱う拡張が、SEP（MCP強化提案）として仕様化のプロセスに乗っている。
原文の表現では「server-initiated events (webhooks and channels, so clients aren't left polling for results)」。長時間かかる処理の結果を、クライアントが定期的に聞きに行くのではなく、サーバー側から通知する形に置き換える狙いが明言されている。
ここが実装者への影響。今「結果が出るまでポーリングする」実装をしているなら、その待ち受け部分は差し替え前提の暫定コードとして扱っておくのが正しい。webhooks/channelsが来た時に、待ち受けループごと丸ごと入れ替えられる形にインターフェースを切っておくと移行が軽くなる。
2026-07-28リリースで、リモートMCPサーバーは「now no different from any other HTTP workload」——他の普通のHTTPワークロードと変わらない存在になった。ロードマップはこの統一をさらに進め、ローカルで動くサーバーも同じStreamable HTTPを話す方向（原文: 「local servers speaking Streamable HTTP over stdio」）へ寄せていく計画を示している。
目標は明快で、原文では単純に「Unifying on one transport」とだけ書かれている。stdio・SSE・Streamable HTTPと輸送方式が枝分かれしている今の状態を1本化するのが狙いで、ローカル/リモートの区別によらず同じコードパスでMCPサーバーを実装・デバッグできることを目指しているように読める。
留保: 移行の具体的な時期・既存stdio実装の後方互換性の扱いは、この記事の時点で明記されていない。
認証まわりは「すでに実装済みのもの」と「これから来るもの」がはっきり分かれている。
方向性を一言でまとめると、「1本の長寿命なAPIキーを発行して使い回す」設計から離れていく。DPoPはトークンを盗まれても第三者が使い回せないようにする「所有証明」の仕組みで、Workload Identity Federationは長寿命の秘密鍵を持たせずに、実行環境（クラウドのワークロードIDなど）を根拠に短命トークンを都度発行する考え方に近い。
留保: ID-JAG grantとtoken exchangeの正式な仕様策定はまだ進行中で、細部（対応するIdPの範囲、後方互換の扱い等）は原文でも確定的には書かれていない。
原文はこの課題を率直に言い当てている——「Connecting to a server with a hundred tools means the model pays for that entire surface before the user has asked a single question」。ツールが100個あるサーバーに繋いだ時点で、ユーザーがまだ何も聞いていないのに、モデルは100個ぶんの定義を毎回コンテキストとして背負わされる。
対策として計画されているのが「progressive discovery」——原文では「server can offer a small entry point and reveal more of its catalog as the conversation narrows」。サーバーは最初に小さな入り口だけを見せ、会話が具体的になるにつれてカタログの残りを開示していく設計だ。
留保: 具体的なAPI形状（どうやって「入り口」と「残り」を区切るか）は原文の時点でまだ確定していない。
上記4点ほど大きくはないが、原文はもう2つ触れている。1つはツール結果の表現統一——「tools/call response can carry the same output in more than one form」という、同じ出力を複数の形式で返せる仕組みの整理。もう1つはSDKの適合性テスト（conformance testing）の強化で、各言語のSDKが仕様からズレないようにする体制づくりだ。派手さはないが、自作SDKやクライアントを仕様準拠のまま保つ上では地味に効いてくる項目になる。
ロードマップはまだ「計画」段階の項目が大半で、今すぐ実装を変える必要はない。ただし、今書いているコードがどこでこの4点にぶつかるかを先に把握しておくと、変更が来たときの移行コストが変わる。