MCP拡張機能のサポートマトリクスの読み方

MCPのコア仕様に無い機能は「拡張機能(extension)」という別枠で追加されます。公式拡張は、対話にUIを埋め込むMCP Apps・機械間認証のOAuth Client Credentials・企業ID基盤と連携するEnterprise-Managed Authorizationの3つです。どれも両側が対応して初めて動くオプトイン機能で、capabilities.extensionsフィールドで宣言し合うネゴシエーションを経て、クライアントによって対応状況にばらつきがあります。サポートマトリクスはそのばらつきを一覧できる公式表で、自分が使っているクライアントで何が使えないかを先に確認しておくと、動かないときに「サーバー側の不具合か、クライアントが未対応なだけか」を切り分けられます。

MCP拡張機能とは何か — コア仕様と何が違うか

拡張機能とは、コア仕様の外側に定義された追加機能で、モジュール性の高い機能(認証など独立した関心事)・特定業界向けの機能・将来コア仕様入りを目指す実験的機能を実装するための仕組みです。識別子は{vendor-prefix}/{extension-name}という形式を取り、公式拡張はio.modelcontextprotocolという予約プレフィックスを使います。サードパーティが独自拡張を作る場合は、自分が所有するドメインを逆順にしたプレフィックス(com.example/my-extensionのような形)を使うルールになっており、Javaのパッケージ命名と同じ発想で衝突を避けます。

公式拡張はMCPのGitHub Organization内にext-接頭辞のリポジトリとして置かれます。認証系拡張はext-auth、MCP Appsはext-appsが実装のソースです。まだ正式仕様になっていない段階のアイデアはexperimental-ext-接頭辞のリポジトリで育てられ、Working GroupかInterest Groupに紐づけられたうえでSEP(仕様変更提案)プロセスを経て正式拡張へ昇格します。実際にこの経路を通った例がMCP Tasksで、当初はコア仕様に実験的に置かれていたものが2026-07-28リビジョンでio.modelcontextprotocol/tasksという独立拡張へ切り出されました。

拡張機能はコア仕様と独立して進化します。破壊的変更が避けられない場合は、拡張の設定オブジェクト内でcapabilityフラグやバージョニングを使うのが基本方針で、それでも無理ならio.modelcontextprotocol/my-extension-v2のように新しい識別子を発行します。フィールドの削除・改名・型変更・必須フィールドの追加はすべて破壊的変更として扱われます。

3つの公式拡張が解決する課題

MCP Appsは3つの中でもっとも対応が進んでいる拡張です。サーバーがツールの結果をテキストだけでなく操作可能なUIとして返せるようになるため、設定フォームやダッシュボードのようなツールとの相性が良い機能です。残る2つは認証系拡張です。マシン間の定期実行や、社内SSO配下でのアクセス制御など、対話的ログインが前提にならない運用シーンをカバーします。

クライアント別サポート状況

公式マトリクスが対応済みとしているクライアントと、拡張機能ごとの対応状況は次のとおりです(コミュニティ管理の表のため、実際に使う前に必ず公式マトリクスで最新状況を確認してください)。

Claude(web)とClaude Desktopは、いずれもMCP Appsには対応済みですが、OAuth Client CredentialsとEnterprise-Managed Authorizationには未対応です。この2つの認証拡張に現時点で対応しているのはArchestra.AIだけで、他のクライアントはまだ実装していません。Goose・Postman・MCPJam・PostHog CodeもMCP Appsのみ対応で、認証系2拡張は未対応という点でClaude(web)やCursorと同じ位置づけです。表の11クライアント全体を見渡すと、MCP Appsは一気に広がった一方、認証拡張は実装が追いついていないという段階差が見えます。同じ「Claude」でも面によってUI表示の挙動が変わるわけではなく、MCP Appsに関してはweb版・Desktop版ともに同じ対応状況です。ただしDesktop版はローカルの.mcpb拡張機能やstdioサーバーを扱える分、接続できるサーバーの範囲そのものはweb版より広くなります。VS CodeのGitHub Copilot拡張機能がMCP Appsに対応している一方、Claude CodeのCLI自体はこの表に含まれていません。これは対話にHTMLを埋め込むUI拡張という性質上、GUIを持つエディタ統合・チャットクライアントが対象で、ターミナル上で動くCLIエージェントは対象外になりやすいためです。VS CodeとClaude Desktopの対応差の詳細はVS CodeのMCP Apps対応とClaude Desktopの違いで、MCP Apps対応クライアントの全量一覧はMCP Appsの対応クライアント一覧で扱っています。

対応を宣言するJSONの中身

拡張の対応表明は、通常のリクエスト・レスポンスの_metaフィールドに載ります。クライアントは各リクエストの_meta内clientCapabilities.extensionsで対応する拡張を宣言し、サーバーはserver/discoverのレスポンスでcapabilities.extensionsに対応拡張を列挙します。この往復が揃って初めて、両者は同じ拡張機能を前提に会話を始められます。JSONの具体的なフィールド構成や設定オブジェクトの中身はMCP拡張機能のネゴシエーション方式で詳しく扱っています。

認証系の2拡張は、コア仕様が定めるDCR(Dynamic Client Registration)やCIMD(Client ID Metadata Document)といった基本の認可機構とは管理も追跡も別枠です。DCR・CIMDはコア仕様の一部としてすべての準拠実装に関わる一方、OAuth Client CredentialsとEnterprise-Managed Authorizationはあくまで追加のオプトイン機能で、対応状況はext-authリポジトリと本マトリクスで別途確認する必要があります。「OAuthに対応している」というクライアントの説明を見ても、それが基本のDCR/CIMDの話なのか、この2つの拡張の話なのかは区別して読む必要があります。

SDKは拡張への対応を選べる

拡張機能への対応はSDK側にも及びます。公式SDK(TypeScript・Python・Go・Rust・C#等)はプロトコル準拠のために拡張機能を実装する義務を負っておらず、どの拡張を実装するかはSDKメンテナーの裁量に委ねられています。あるSDKがMCP Appsに対応していても、別のSDKでは未実装ということが起こり得るため、「言語Xの公式SDKを使えば拡張機能も自動で使える」とは限りません。SDKが拡張に対応している場合は、そのSDKのドキュメントに対応拡張の一覧を載せる運用になっています。拡張機能は既定で無効化されており、開発者が明示的にオプトインしない限り有効になりません。

対応していないクライアントでは何が起きるか

クライアントとサーバーの両方がcapabilities内のextensionsフィールドで対応を宣言して初めて有効になり、どちらか一方だけが対応している状態では、拡張は単純に有効化されません。

片側だけが対応している場合の挙動はサーバー側の設計に委ねられています。望ましい実装は、UIで表示する内容を持つサーバーが、UI拡張に対応していないクライアントに対してもテキストとして意味の通る結果を返す形です。逆に、特定の認証拡張が必須のサーバーは、対応していないクライアントからの接続を拒否してよいことになっています。つまり「MCP Appsに未対応のクライアントでツールを呼んだら壊れた」という状況は、サーバー側の実装がフォールバックを用意していないために起きるもので、拡張機能の仕様自体はそこまで強制していません。動かないときはクライアントの対応状況とサーバーのフォールバック実装の両方を疑う必要があります。

まとめ

MCP拡張機能は、コア仕様を太らせずに認証やUIのような発展的な機能を追加するための仕組みで、公式扱いになっているのはMCP Apps・OAuth Client Credentials・Enterprise-Managed Authorizationの3つです。もっとも普及しているのはMCP Appsで、Claude(web)・Claude Desktop・VS Code・Cursor・ChatGPTなど主要クライアントの大半が対応済みです。一方の認証拡張2つはArchestra.AIなど一部のクライアントに限られ、Claude・VS Code・Cursorはまだ対応していません。拡張は両側の合意があって初めて動くオプトイン機能なので、想定どおりに動かないときは、クライアントの対応状況とサーバー側のフォールバック実装のどちらに原因があるかを切り分けてください。MCPの接続方法自体の基礎はMCP実用ガイドにまとめています。