# MCP互換性は「対応済み」だけでは判定できない CURRENT_STATUS: CURRENT OBSERVATION: SPEC_ONLY FRESHNESS: CURRENT PAGE_TYPE: update_note CANONICAL_URL: /tools/ea-157-mcp CLAIM_IDS: none EVIDENCE_IDS: EA-157-CURRENT-APPROVAL, EA-157-CURRENT-BODY-READBACK UNKNOWN_IDS: EA-157-UNKNOWN-01 OPS_IDS: none ## Summary 「MCP対応」は単独では互換性の証拠にならない。protocol revision、SDK、実際のwire revision、Gatewayのsupported revisions、下流target、authorization/trust/auditを分離して確認する。2026-07-28は2025-eraとwire behaviorが異なり、SDKのmajor versionだけから実通信revisionを推定してはならない。 ## Current judgment 「MCP対応」は単独では互換性の証拠にならない。protocol revision、SDK、実際のwire revision、Gatewayのsupported revisions、下流target、authorization/trust/auditを分離して確認する。2026-07-28は2025-eraとwire behaviorが異なり、SDKのmajor versionだけから実通信revisionを推定してはならない。 ## Scope MCP互換性は「対応済み」だけでは判定できない ## Confirmed ## UNKNOWN - EA-157-UNKNOWN-01: - 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へ与える影響。 ## Evidence - EA-157-CURRENT-APPROVAL (RESEARCH): 現行本文の監査・revision対応 - EA-157-CURRENT-BODY-READBACK (IMPL): 現行本文の収録照合 ## Failure / limits 「SDK v2だから2026-07-28対応」と推定する。 ## Failure / limits 「GatewayがMCP対応だからclient/server間の全revisionが互換」と推定する。 ## Failure / limits Gateway inboundで新revisionが通ることから、下流targetまで同じrevisionで動くと推定する。 ## Failure / limits 接続成功をauthorization、tool trust、監査、データ保護の成立証拠にする。 ## Failure / limits release noteやroadmapをnormative contractとして扱う。 GX A3では、AgentCore Gatewayのdownstream target syncがinboundとは別のversion境界を持ち得るという外部運用報告も捕捉された。ただし、この点は今回の公開claimとして一般化しない。現行公式ドキュメントだけでは、全target経路について同一のdownstream negotiation挙動を保証できないためである。 ## Practice 導入・移行時に最低限、次をreadbackする。 ## Practice 使用するMCP protocol revision。 ## Practice SDK/packageのversionだけでなく、runtimeで有効なversion negotiation設定。 ## Practice host/client/serverが実際に話すrevision/era。 ## Practice Gateway/proxyが広告する `supportedVersions`。 ## Practice upstreamとdownstream targetを分けたversion support。 ## Practice authorization、scopes、audience、credential isolation。 ## Practice server/tool registry・allowlist・publisher/trust policy。 ## Practice tool schema/versionと変更管理。 ## Practice audit/retention、rate/size limit、timeout/retry。 ## Practice provider/plan/region/organization policyによるavailability。 ## 結論・何が分かったか 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、可用性を保証するとは主張しない。 ## 確認できたclaim ### Claim 1 — 2026-07-28は2025-eraと同じwire behaviorではない 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を列として持つ必要がある。 ### Claim 2 — SDK/package versionとwire revisionは同じではない 公式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する。 ### Claim 3 — Gatewayは複数revisionを同時に扱い得る 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を照合する。 ### Claim 4 — 接続成功とenterprise-gradeな安全性は別判定である 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挙動を保証できないためである。 ## Availability Gate 導入・移行時に最低限、次をreadbackする。 1. 使用するMCP protocol revision。 2. SDK/packageのversionだけでなく、runtimeで有効なversion negotiation設定。 3. host/client/serverが実際に話すrevision/era。 4. Gateway/proxyが広告する `supportedVersions`。 5. upstreamとdownstream targetを分けたversion support。 6. authorization、scopes、audience、credential isolation。 7. server/tool registry・allowlist・publisher/trust policy。 8. tool schema/versionと変更管理。 9. audit/retention、rate/size limit、timeout/retry。 10. provider/plan/region/organization policyによるavailability。 ## OPEN_UNKNOWN - 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. ## SAFE_WORDING 「MCP対応」は単独では互換性の証拠にならない。protocol revision、SDK、実際のwire revision、Gatewayのsupported revisions、下流target、authorization/trust/auditを分離して確認する。2026-07-28は2025-eraとwire behaviorが異なり、SDKのmajor versionだけから実通信revisionを推定してはならない。 NEXT: /agent/start.json STOP: This is a knowledge projection, not an execution order.