GitHub MCP ServerがステートレスMCPを先行サポート、新版では接続フェーズと共有sessionストレージを廃止

GitHubは7月23日、公式のGitHub MCP ServerがMCP `2026-07-28`仕様を先行サポートしたと発表した。今回の改訂の中心はツールの追加ではなく、リモートエージェントツールのトランスポートモデルの刷新だ。`initialize`／`initialized`ハンドシェイクと`Mcp-Session-Id`は廃止され、プロトコルバージョン、クライアント情報、capabilitiesは各リクエストで送信されるようになった。このため、同じエージェントによる連続した呼び出しを、一般的なround-robinロードバランサーで異なるインスタンスへ振り分けられ、sticky sessionやRedisなどの共有session storeは不要になる。

ゲートウェイがJSON-RPC payloadを解析せずにトラフィックのルーティング、レート制限、スキャンを行えるよう、新仕様ではStreamable HTTPに`Mcp-Method`や`Mcp-Name`などのヘッダーを付与することを求めている。リストやリソースの読み取り結果についても、`ttlMs`と`cacheScope`を通じてキャッシュの有効期間を表現できる。GitHubによると、これにより同社のサービスでは初期化時のデータベース書き込みと呼び出しごとのsession読み取りを廃止し、ログおよびシークレットスキャンのためのDeep Packet Inspectionも不要になった。従来は複数回のやり取りが必要だったログインやelicitationについては、サーバーが`InputRequiredResult`を返し、クライアントが入力を収集した後に元のリクエストを再送する方式へ変更された。

これはセルフホスト型MCPサービスを運用するエンジニアリングチームに直接的な運用上の価値をもたらすが、「ステートレス」なのはプロトコル層に限られる。ブラウザ、ショッピングカート、ワークフローの状態は、引き続き明示的なhandleとしてツールのパラメーターに含める必要がある。新版では同時にTasksがextensionへ変更され、リソースが存在しない場合のエラーコードが調整され、Roots、Sampling、Loggingなどのコアcapabilitiesが非推奨となった。Tier 1 SDKは旧バージョンとの互換性を維持しているものの、プロトコルを手書きした実装、旧Tasks APIに依存する実装、固定エラーコードを照合する実装については、引き続き公式conformance suiteを実行すべきであり、アップグレードを単なるバージョン文字列の置き換えと見なすことはできない。