MCP互換性は「対応済み」だけでは判定できない

MCPの導入可否を「MCP対応」という一語で判定してはいけない。少なくとも、プロトコルrevision、SDK/package、実際にwire上で選ばれるrevision、Gatewayが広告する対応revision、下流targetのrevision、認可・trust・監査の実装を分離して確認する必要がある。

2026-07-28 revisionは、従来の2025-eraとwire behaviorが異なる。2025-eraは initialize handshake を使う一方、2026-07-28はstatelessなmodern eraとして server/discover とrequestごとのversion情報を使う。さらに公式TypeScript SDK v2でも、v2 packageを使うだけでは2026-07-28をwire上で話すことにはならず、modern revisionの利用は明示的なopt-in/negotiationを要する。

AWS AgentCore Gatewayの現行ドキュメントは、この違いを実運用上のversion gateとして露出している。Gatewayは複数のMCP revisionを同時に広告でき、clientはrequestごとにrevisionを指定する。したがって「GatewayがMCP対応」「SDKがv2」という情報だけでは、実際にどのrevisionで通信するかは確定しない。

対象はMCPを利用するhost/client/server、SDK、Gateway、proxy、tool serverの導入・更新・移行・監査である。特定providerだけの推奨構成ではなく、versioned protocolを業務接続境界として扱う際の確認原則を示す。

本記事は、MCP接続そのものが安全性、tool correctness、認可、exactly-once、可用性を保証するとは主張しない。

MCP TypeScript SDKのprotocol-version資料は、2024-10-07〜2025-11-25を legacy era、2026-07-28を modern eraとして区別する。legacyでは initialize handshakeを行い、modernでは server/discover によるadvertisementを使う。

運用上の意味: compatibility matrixは「MCP = yes/no」ではなく、revision/eraを列として持つ必要がある。

公式TypeScript SDK v2のmigration資料は、v2 packageを利用しても2026-07-28のwire behaviorが自動で有効になるわけではなく、modern revisionを話すには明示的なversion negotiation/opt-inが必要だと説明する。

運用上の意味: dependency inventoryだけでprotocol conformanceを判定しない。runtime configurationとnegotiated/served revisionをreadbackする。

Amazon Bedrock AgentCore Gatewayの現行ドキュメントは、2026-07-28、2025-11-25、2025-06-18、2025-03-26をsupported revisionsとして示す。2026-07-28 requestはstatelessで、older revisionsは従来のinitialize handshakeを継続する。Gatewayは supportedVersions を広告し、requestで指定されたrevisionが広告集合にない場合は拒否する。

運用上の意味: Gateway導入時は「製品がMCP対応か」ではなく、対象endpointが現在広告しているrevision集合とclientが実際に要求するrevisionを照合する。

MCPのprotocol connectivity、SDK support、Gateway version routingが成立しても、server/tool trust、authorization policy、data boundary、audit completeness、failure/retry semantics、tool result correctnessは別レイヤーである。

運用上の意味: compatibility testとsecurity/operability testを同じPASSにまとめない。

• 「SDK v2だから2026-07-28対応」と推定する。
• 「GatewayがMCP対応だからclient/server間の全revisionが互換」と推定する。
• Gateway inboundで新revisionが通ることから、下流targetまで同じrevisionで動くと推定する。
• 接続成功をauthorization、tool trust、監査、データ保護の成立証拠にする。
• release noteやroadmapをnormative contractとして扱う。

GX A3では、AgentCore Gatewayのdownstream target syncがinboundとは別のversion境界を持ち得るという外部運用報告も捕捉された。ただし、この点は今回の公開claimとして一般化しない。現行公式ドキュメントだけでは、全target経路について同一のdownstream negotiation挙動を保証できないためである。

導入・移行時に最低限、次をreadbackする。

• 使用するMCP protocol revision。
• SDK/packageのversionだけでなく、runtimeで有効なversion negotiation設定。
• host/client/serverが実際に話すrevision/era。
• Gateway/proxyが広告する supportedVersions。
• upstreamとdownstream targetを分けたversion support。
• authorization、scopes、audience、credential isolation。
• server/tool registry・allowlist・publisher/trust policy。
• tool schema/versionと変更管理。
• audit/retention、rate/size limit、timeout/retry。
• provider/plan/region/organization policyによるavailability。

• provider横断のhost/client/server conformance matrix。
• 各SDKのrelease/tagとwire-revision対応の完全な同期表。
• Gateway/proxyの全製品で共通するnegotiation semantics。
• inbound revisionとdownstream target revisionの自動変換・fallbackの一般保証。
• registry/tool trustの共通標準。
• tenant別のaudit/retention/data-residency。
• latency/cost/incident rateのprovider横断実測。
• revision migrationが実業務のtool semanticsへ与える影響。

導入前: revisionを固定し、client/server/Gatewayの対応集合を表にする。 更新前: SDK更新とprotocol revision更新を別changeとして扱う。 試験: handshake/discovery、version rejection、fallback、tool list/call、authorization failure、audit recordを個別に検証する。 本番判定: 「接続できた」ではなく、期待revisionで通信したことをreadbackし、security/operability gateを別途通す。 ロールバック: 旧revisionを外す前に、利用中clientが新revisionへ移行済みか確認する。

Evidence as of: 2026-10-11 JST.

Primary / author-maintained: - Model Context Protocol TypeScript SDK — Protocol versions. - Model Context Protocol TypeScript SDK — Supporting protocol revision 2026-07-28. - Amazon Bedrock AgentCore — Use an AgentCore gateway. - AWS Artificial Intelligence Blog — How AgentCore Gateway supports the MCP 2026-07-28 spec. - MCP 2026-07-28 specification and existing EA-157 canonical evidence packet.

GX provenance: - GX01_RUN_20260928_1113_A3 (A3 Agent・相互運用標準). RUN ID/date/slot are provenance only and are not the public article identity.

「MCP対応」は単独では互換性の証拠にならない。protocol revision、SDK、実際のwire revision、Gatewayのsupported revisions、下流target、authorization/trust/auditを分離して確認する。2026-07-28は2025-eraとwire behaviorが異なり、SDKのmajor versionだけから実通信revisionを推定してはならない。