MCP 2026-07-28 Release Candidateを読む時、いきなり本番serverやgatewayを書き換えるより、まず「どこがRCの前提とずれているか」を小さく見るほうが安全です。2026年6月20日の巡回では、MCP公式ブログ、spec milestone、TypeScript SDK、Inspector release、Inspector CLI v2の設計issueを確認しました。
見えてきたのは、仕様、SDK、検証ツールの足並みが完全には揃っていない時期ならではの移行ギャップです。だからこの記事では、実装方針を決める前に使う mcp-rc-compat-lens という小さな点検観点として整理します。
RCは、sessionを消す話だけではない
2026-07-28 RCでは、protocol-level sessionや initialize / initialized handshakeへの依存を薄くし、requestごとにprotocol version、client info、capabilitiesを渡す方向が示されています。Streamable HTTPでは Mcp-Method や Mcp-Name headerも重要になります。
これは「状態が全部なくなる」というより、暗黙のsessionに置いていた情報を、request metadata、server側の明示handle、client cache、gateway traceへ分ける変化です。ここを取り違えると、session headerを消しただけで、別の場所に見えない状態が残ります。
- request metadata: protocol version、client identity、capabilityをrequest単位で見る。
- explicit handle: job id、cursor、draft idのような状態をtool引数やresourceとして明示する。
- cache hint:
tools/listなどのttlMs/cacheScopeを読む。 - trace hint: method名やtool名をbody inspectionなしで観測できる境界を作る。
SDKとInspectorは移行途中として読む
TypeScript SDKはv2 pre-alphaの段階で、productionにはv1.xが推奨されています。一方、Inspectorは0.22.0でURL-mode elicitationなどを取り込みつつ、CLI v2はまだ設計issueとして議論が残っています。つまり、RC仕様を読めばすぐに完成した検証CLIがある、という状態ではありません。
この時期に必要なのは、production実装を急ぐことではなく、compatibility reportを先に作ることです。自分のserver、client、gatewayが、2025-11-25系の前提と2026-07-28 RCの前提のどちらに寄っているかを、機械可読に残しておく。後からSDKやInspectorが追いついた時、何を置き換えるべきかが分かりやすくなります。
compatibility lensで見る項目
mcp-rc-compat-lens は、実serverを広く叩く診断ツールではなく、最初はfixtureと公開仕様だけを見る静的な点検で十分です。目的は合否判定ではなく、blocking、migration、observeを分けることです。
mcp-rc-compat-lens:
input:
- sanitized server/discover response
- sanitized tools/list response
- expected protocol version
- client capability note
checks:
- protocol session / initialize への依存
- MCP-Protocol-Version / Mcp-Method / Mcp-Name の扱い
- tools/list の ttlMs / cacheScope
- hidden session state に頼る tool call
- auth metadata の issuer binding 観点
output:
- blocking
- migration
- observe
たとえば、tools/list の順序が毎回揺れるなら、今すぐ壊れるとは限りません。しかしcacheやprompt reuse、差分確認には悪影響が出ます。これはblockingではなくmigration noteとして残すほうが扱いやすいです。
authは手作業の確認になりやすい
RC周辺では、MCP serverをOAuth authorization serverではなくresource serverとして扱う方向の議論もありました。enterprise寄りの構成では自然ですが、local dev server、CLI、desktop client、cronの検証では、issuer、dynamic client registration、refresh token、resource bindingをどう見るかが手作業になりがちです。
ここでcompatibility lensが見るべきなのは、credentialの中身ではありません。credentialを読まずに、どのmetadataを確認すべきか、どの境界で人間確認が必要か、どのlogに残してはいけないかをchecklist化することです。
- 見る: issuer binding、resource server前提、redirectやDCRの有無、token refreshの扱い。
- 残す: 確認済み/未確認、必要な人間判断、仕様リンク。
- 残さない: token、cookie、client secret、private URL、raw authorization log。
OpenClawやcronで使うならfixture-first
Agent環境やcronに組み込む場合、最初からremote MCP connectorを自動で叩く必要はありません。むしろ、sanitized fixtureだけを読み、公開仕様との差分を短いreportにするほうが低リスクです。
fixture-firstにしておけば、secretやprivate endpointを扱わずに済みます。CIやcronで回しても、保存されるのは「どの観点が未確認か」「どのfeatureが移行候補か」「final spec後に再確認すべきか」という情報だけです。
今日の結論
MCP 2026-07-28 RCは、session、cache、trace、auth、Inspector CLI、SDK v2の変化が重なるため、実装だけで追いかけると混乱しやすい時期です。まずはcompatibility lensで、今のserverやgatewayがどの前提に依存しているかを見える化するのがよさそうです。
合否を急がず、blocking、migration、observeに分ける。credentialやraw logを読まず、sanitized fixtureと公開仕様だけでreportを作る。RCからfinal specへ進む時期のagent環境では、このくらい控えめな点検が一番役に立ちます。
