MCP Appsの対応クライアント一覧とExtensionsの仕組み
MCP Appsを実装するクライアントは11個。Claude・ChatGPT・Cursorも対応済みですが、同じExtensions枠のOAuth Client Credentialsは対応クライアントがまだゼロです。
MCP Appsに対応するクライアントは11個、ChatGPTやCursorも含まれる
MCPのExtension Support Matrixによると、MCP Apps(対話型のHTMLインターフェースをチャット内に描画する拡張機能)に対応しているクライアントは次の11個です。
| クライアント | MCP Apps | OAuth Client Credentials | Enterprise-Managed Authorization |
|---|---|---|---|
| Claude(web) | MCP Apps✓ | OAuth Client Credentials— | Enterprise-Managed Authorization— |
| Claude Desktop | MCP Apps✓ | OAuth Client Credentials— | Enterprise-Managed Authorization— |
| VS Code GitHub Copilot | MCP Apps✓ | OAuth Client Credentials— | Enterprise-Managed Authorization— |
| Microsoft 365 Copilot | MCP Apps✓ | OAuth Client Credentials— | Enterprise-Managed Authorization— |
| Goose | MCP Apps✓ | OAuth Client Credentials— | Enterprise-Managed Authorization— |
| Postman | MCP Apps✓ | OAuth Client Credentials— | Enterprise-Managed Authorization— |
| MCPJam | MCP Apps✓ | OAuth Client Credentials— | Enterprise-Managed Authorization— |
| ChatGPT | MCP Apps✓ | OAuth Client Credentials— | Enterprise-Managed Authorization— |
| Cursor | MCP Apps✓ | OAuth Client Credentials— | Enterprise-Managed Authorization— |
| Archestra.AI | MCP Apps✓ | OAuth Client Credentials— | Enterprise-Managed Authorization✓ |
| PostHog Code | MCP Apps✓ | OAuth Client Credentials— | Enterprise-Managed Authorization— |
Claude(web)とClaude Desktopに加えて、ChatGPTやCursorのような競合クライアントも対応済みという点が目を引きます。MCP Appsはベンダー横断で採用が進んでいる拡張機能だと分かります。表はコミュニティが維持しており、実装状況は今後も更新される見込みです。表に載っていないクライアントは、単純に対応が無いのか、対応はしているが表への反映が追いついていないのかを、表単体からは区別できません。判断材料が欲しい場合は、次に紹介する概要ページの記載とも突き合わせるのが確実です。
そもそもMCP Appsで何ができるのか
MCP Appsは、MCPサーバーが対話型のHTMLインターフェース(データの可視化・フォーム・ダッシュボードなど)をチャットの中にそのまま描画できるようにする拡張機能です。テキストの応答だけでは伝えにくい情報を、ユーザーが実際に操作できる形で返せます。
MCP Apps概要ページが挙げる典型的な使いどころは次のとおりです。
- 複雑なデータの探索: 「地域別の売上を見せて」と聞かれたとき、テキストの数字の羅列ではなく、クリックでドリルダウンできる地図を返す
- 選択肢の多い設定: デプロイ設定のように依存関係のある選択肢が多い場面で、対話の往復ではなく1画面のフォームでまとめて見せる
- リッチメディアの表示: PDFや3Dモデル、生成画像をテキスト説明ではなく実際のビューアーで表示する
- リアルタイムの監視: ログやメトリクスのダッシュボードを、都度聞き返さなくても更新され続ける状態で表示する
技術的には、ツールの説明に_meta.ui.resourceUriでUIリソースへの参照を含め、ホストがそれをサンドボックス化されたiframe内にレンダリングする仕組みです。アプリとホストはpostMessage APIを介したJSON-RPC通信で結ばれ、アプリ側はホスト経由でツール呼び出しを要求したり、会話のコンテキストを更新したりできます。iframeのサンドボックスにより、アプリは親ページのDOMやホストのCookieにアクセスできず、サーバー作者を完全に信頼しなくてもホスト側が安全にサードパーティ製アプリを描画できる設計です。
この一覧が示すもう1つの事実 — OAuth Client Credentialsはまだゼロ
Extension Support Matrixには、MCP Apps以外に2つのExtensionが並んでいます。それぞれの識別子と役割は次のとおりです。
| Extension | 識別子 | 役割 |
|---|---|---|
| MCP Apps | 識別子io.modelcontextprotocol/ui | 役割チャット内に描画する対話型HTMLインターフェース |
| OAuth Client Credentials | 識別子io.modelcontextprotocol/oauth-client-credentials | 役割対話的なユーザーログインを介さないマシン間認証 |
| Enterprise-Managed Authorization | 識別子io.modelcontextprotocol/enterprise-managed-authorization | 役割エンタープライズのID基盤による集中アクセス制御 |
なお認証系の2つの拡張(OAuth Client CredentialsとEnterprise-Managed Authorization)の対応状況は、MCPのコア認可機能(Dynamic Client Registration・OAuth Client ID Metadata Documents)とは別枠で追跡されています。認証・認可まわりを実装する際は、ext-authリポジトリの最新状況もあわせて確認する必要があります。
この2つの対応状況を見ると、MCP Appsとは対照的な景色が広がります。OAuth Client Credentialsに対応しているクライアントは、表に載っている11個の中で1つもありません。Enterprise-Managed Authorizationに対応しているのはArchestra.AIのみです。
同じExtensionという枠組みでも、採用の進み方には大きな差があります。MCP AppsはUIをチャットに埋め込むという、ユーザーに直接見える体験の変化を伴うため各クライアントの実装優先度が高いのに対し、OAuth Client Credentialsのような認証系の拡張はマシン間連携のバックエンド実装が主眼で、対応してもエンドユーザーには見えにくい性質があります。表に並ぶ3つの拡張の対応状況を横に比べることで、どの領域の実装が先行しているかが読み取れます。
Extensionsはなぜ「オプトイン」なのか
MCPのExtensionsは、コアプロトコルにない機能をモジュール的・専門的・実験的に追加する仕組みです。識別子は{ベンダープレフィックス}/{拡張名}の形式を取り、公式拡張にはio.modelcontextprotocolというベンダープレフィックスが付きます。MCP Appsの識別子はio.modelcontextprotocol/uiです。
Extensionsは常にオプトイン(明示的な有効化が必要)です。クライアントとサーバーの双方が、それぞれのcapabilities内のextensionsフィールドで対応を宣言して初めて有効になります。クライアントは各リクエストの_metaにあるio.modelcontextprotocol/clientCapabilitiesで対応拡張を宣言し、サーバー側の対応状況はserver/discoverのレスポンスから読み取ります。つまり表の✓は「実装済み」を示すもので、実際に機能するかは接続するサーバー側が同じ拡張に対応しているかどうかにもかかります。
ドキュメント間でもクライアント一覧に差がある
MCP Appsの対応クライアントは、実はドキュメント内の2つのページで記載が食い違っています。この記事で紹介したExtension Support Matrix(/extensions/client-matrix)は11クライアントを挙げているのに対し、MCP Apps自体の概要ページ(/extensions/apps/overview)の「Client support」節はClaude・Claude Desktop・VS Code GitHub Copilot・Microsoft 365 Copilot・Goose・Postman・MCPJam・Archestra.AIの8クライアントのみを挙げ、Cursor・ChatGPT・PostHog Codeの3つが抜けています。
どちらのページも「詳細はclient matrixを見よ」と互いを参照しており、対応クライアントの一次情報としてはExtension Support Matrixが更新の起点になっていると読めます。概要ページ側の記載更新が追いついていない可能性があり、対応状況を正確に把握したいなら、この記事で示したExtension Support Matrix側の一覧を参照するのが確実です。
クライアントを実装する側がこの表をどう使うか
MCP AppsはコアMCP仕様に対する拡張であり、ホスト側の対応状況はクライアントごとに異なる、とドキュメントは注記しています。この記事の一覧表を鵜呑みにせず、自分が使うクライアントのバージョンで実際にMCP Appsが動くかを確かめてから設計を進めるのが安全です。MCP Appsに対応したいクライアント実装者向けに、ドキュメントは次の手順を示しています。
ext-appsリポジトリで拡張仕様を確認するcapabilitiesのextensionsフィールドで対応を宣言し、サーバーのserver/discoverレスポンスから拡張対応を読み取る- 拡張のプロトコル要件を実装する
- この一覧表を更新するプルリクエストを送る
実装の入り口は2つ用意されています。1つは@mcp-ui/clientパッケージで、MCP AppsのビューをホストアプリケーションにレンダリングするReactコンポーネントを提供します。もう1つはSDKに含まれるApp Bridgeモジュールで、サンドボックス化されたiframeでのレンダリング・メッセージのやり取り・ツール呼び出しのプロキシ・セキュリティポリシーの適用をまとめて扱います。どちらもstdioやHTTPではなくpostMessageを通信路にしており、Webの標準的な仕組みの上に構築されているため、特定のフレームワークに縛られません。リポジトリにはReact・Vue・Svelte・Preact・Solid・vanilla JavaScriptのスターターテンプレートが揃っており、サーバー側の実装例も3D可視化・データ探索・業務アプリケーション・メディア表示・ユーティリティといった分野で公開されています。既存の実装例を出発点にすれば、通信プロトコルをゼロから組む必要はありません。
この表はコミュニティメンテナンスであり、GitHub上でプルリクエストを通じて更新されます。自作のMCPホストがMCP Appsに対応したら、この表への追加を送ることで一覧に載せられます。拡張機能が公式化されるまでのプロセス自体はMCPのSEPプロセス、実験的な拡張から正式な拡張へ切り替わった実例はMCP Tasksが拡張機能に移った理由で扱っています。
まとめ — MCP Appsは横並びの採用、認証系拡張はこれから
MCP Appsに対応するクライアントは11個で、Claude・ChatGPT・Cursorのような主要クライアントが横並びで実装を終えています。一方で同じExtension Support Matrixに載るOAuth Client CredentialsとEnterprise-Managed Authorizationは、対応クライアントがそれぞれ0個・1個にとどまり、認証系の拡張の採用はこれからという段階です。自作クライアントやサーバーがどの拡張に対応すべきかを判断するときは、この一覧の更新状況を都度確認するのが確実です。表に載っていない、あるいは実装予定のクライアントを使っている場合は、対応が来るまで代替の表示手段を用意しておく必要があります。MCPの基礎から確認したい場合はMCPとはを先に読むと文脈がつかみやすくなります。