MCPの 2026-07-28 Release Candidateを読むと、remote MCP serverやgatewayの前提が少し変わりそうです。大きいのは、protocol layerのsessionに寄せすぎず、各requestのmetadata、server discovery、cache hint、trace contextを見ながら運用する方向が強まっていることです。
この記事は、2026年6月17日に確認したMCP公式ブログ、draft changelog、draft authorization、GitHub releaseをもとにした実務メモです。RCなので、final specまでに細部は変わる可能性があります。その前提で、今すぐ実装を固定する話ではなく、gatewayやclient cacheを点検する観点として整理します。
sessionが消える、ではなく責務が移る
今回のRCで目を引くのは、protocol sessionや Mcp-Session-Id、initialize handshakeへの依存を薄くし、requestごとの _meta にprotocol version、client identity、client capabilitiesを載せる方向です。
これは「状態を一切持たない」という単純な話ではありません。protocolのsessionで吸収していた前提が、application state、server側のhandle、client側のcache、gatewayのrouting判断へ分かれていく、という見方のほうが実務には近いです。
- protocol session: request継続のための暗黙状態に頼りすぎない。
- application state: job id、cursor、draft idなどは明示的なhandleとして扱う。
- client identity: requestごとに、どのclient能力で呼ばれているかを見られるようにする。
- gateway: sticky sessionより、routing、cache、traceの境界として振る舞う。
remote MCP serverを作る側は、session headerがあるから同じbackendに寄せればよい、という設計を少し疑ったほうがよさそうです。逆に、server-mintedなhandleを明示し、再試行や別connectionでも意味が崩れない形に寄せる余地が出ます。
server/discoverはpreflightの入口になる
RCでは server/discover が出てきます。serverがprotocol version、capabilities、identityを返し、clientが互換性や利用可能な機能を事前に見るための入口です。
これは、以前の記事で書いてきた「MCP導入前preflight」と相性がよい変更です。clientやagentがいきなりtool callを始める前に、serverがどのprotocol世代を想定しているか、どのcapabilityを出しているか、どのmigration riskがあるかを短いreportにできます。
preflightで見たい項目: - server/discover が返るか - protocol version が想定範囲か - client capabilities を request ごとに渡せるか - deprecated feature に依存していないか - tools/list のcache hintを扱えるか
ここで大事なのは、preflightを「使える / 使えない」の二択にしないことです。RC対応済み、migrationが必要、観察だけでよい、というように段階を分けたほうが、spec final前の運用には向いています。
tools/listはcacheされる前提で読む
Streamable HTTPまわりでは、list endpointの結果がper-connectionで変わらない前提になり、tools/list などに ttlMs と cacheScope が入る方向が示されています。これはgatewayやclientにとってかなり大きいです。
今までは「tool listを毎回取りに行けばよい」と雑に考えても、個人環境なら大きな問題になりにくかったかもしれません。けれど、複数client、複数user、gateway cache、prompt cache hitが絡むと、古いtool listを見ているだけでagentの判断がずれます。
- private cache: userやworkspaceに閉じるべきtool listを共有しない。
- stale表示: いつ取得したtool listかをclient側で見えるようにする。
- listChangedが届かない環境: pollingやTTL切れの扱いを決める。
- deterministic order: tool順序が揺れて、差分やprompt cacheが乱れないようにする。
特にagent UIでは、「今見えているtool listが新しいのか」「cacheされた古い一覧なのか」が分からないと、原因調査が難しくなります。cacheは高速化だけでなく、説明可能性の問題として扱う必要があります。
trace contextはgatewayをただのpipeにしない
RCでは Mcp-Method、Mcp-Name headerや、OpenTelemetry trace context向けの _meta keyも見えています。これにより、gatewayは単にbytesを流す場所ではなく、どのmethodがどのserverへ向かい、どのrequestがどのtool実行へつながったかを観測する境界になります。
ここで気をつけたいのは、観測したいからといってraw logをそのまま保存しないことです。trace id、method、tool name、duration、statusのような最小限のfieldに絞り、credential、argument内のsecret、local path、private URLは保存しない設計が必要です。
deprecated featureは移行reportに分ける
Roots、Sampling、Loggingはdeprecated側へ寄っています。古いclientの便利機能に寄せたserverほど、ここで移行負担が出そうです。たとえばlocal file rootsをUIで選ばせていた設計は、tool parameterやresource URI、server configへ寄せると説明量が増えます。
ただし、deprecated featureを見つけた瞬間にblocking扱いにすると、RC段階では運用が固くなりすぎます。reportでは、breaking changeとmigration noteを分けたいです。
reportの分け方: blocking: 現行clientで明確に動かない migration: final specまでに置き換え方を決めたい observe: RC段階では観察だけでよい
小さく作るならmcp-rc-drift-check
OpenClawや個人のagent workflowに落とすなら、いきなりremote serverへ接続して診断するより、fixture-onlyの mcp-rc-drift-check から始めるのが低リスクです。
mcp-rc-drift-check:
input:
- server/discover fixture
- client capability fixture
- tools/list fixture
- resources/list fixture
checks:
- session header依存
- initialize依存
- ttlMs / cacheScope 欠落
- nondeterministic tool order
- trace context欠落
- deprecated Roots / Sampling / Logging依存
output:
- rc-drift-report.md
- json summary
この道具は、HTTP requestを投げません。credentialも読みません。保存済みfixtureだけを見て、gatewayやclientがRC方向にどれくらい寄っているかを、blocking、migration、observeに分けて出します。spec final前の試作としては、このくらい静的なほうが扱いやすいです。
今日の結論
MCP 2026-07-28 RCは、remote MCP serverやgatewayに「sessionでつなぐ」だけでは足りない、という合図に見えます。request metadata、server discovery、list cache、trace contextを分けて見られるようにしておくと、final spec後の移行が少し楽になります。
今すぐ本番実装をRCに固定する必要はありません。まずはfixtureを集め、session header依存、cache hintの欠落、trace contextの欠落、deprecated feature依存をreportにする。小さな静的checkから始めるのが、agent環境ではいちばん安全そうです。
