GitHub MCP Server、ステートレスな新プロトコルを先行サポート——初期化ハンドシェイクとRedisセッションを廃止

GitHubは7月23日、同社のMCP Serverが近日公開予定のMCP `2026-07-28`仕様をサポートしたと発表した。今回の改訂は、単にツールへいくつかのフィールドを追加するものではなく、リモートMCPの接続ライフサイクルを全面的に書き換えるものだ。`initialize`／`initialized`ハンドシェイクと`Mcp-Session-Id`は廃止され、プロトコルバージョン、クライアント情報、Capabilitiesは各リクエストで個別に送信する方式へ変更された。これにより、リクエストを任意のサーバーで処理できるようになり、スティッキー・ロードバランシングや共有セッションストレージが不要になる。

GitHubによると、新版の採用に伴い、Redisセッション、初期化時のデータベース書き込み、および呼び出しごとのデータベース読み取りを廃止したという。新しい`Mcp-Method`、`Mcp-Name` HTTPヘッダーにより、ゲートウェイはJSON-RPCの内容全体を事前に解析することなく、ルーティング、レート制限、シークレットスキャンを実行できる。ツール一覧とリソース読み取り結果には、`ttlMs`と`cacheScope`も付与できるようになった。分散トレーシングにはW3C Trace Contextを統一して使用する。

ステートレスであることは、アプリケーションが状態を保持できないことを意味しない。ブラウザー、ショッピングカート、その他の長いワークフローに関するコンテキストを必要とするツールは、明示的なハンドルを返し、モデルが後続のパラメーターでそのハンドルを送り返す必要がある。サーバーがユーザー入力を求める場合も、`InputRequiredResult`を返す方式へ変更された。クライアントは回答を収集した後、元の呼び出しを再送信する。長時間タスクは、オプションのTasks extensionへ移された。

これらの変更によって大規模なMCPデプロイは簡素化されるが、プロトコルを独自実装しているチームにとっては、依然として移行が必要な変更となる。旧版の実験的Tasks API、セッションに依存するサーバー、特定のエラーコードを照合するクライアントは、修正が必要になる可能性がある。公式のTier 1 SDKは後方互換性を維持し、テスト支援も提供している。エンジニアリングチームは今後、単に「ツールを正常に呼び出せる」ことだけで互換性を判断せず、正式なconformance suiteを使用して検証すべきだ。