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

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

MCP Appsなど4つの拡張は、クライアントごとに対応状況が違います。サポートマトリクスの読み方と、未対応のとき何が起きるかを解説します。

MCPのコア仕様に無い機能は「拡張機能(extension)」という別枠で追加されます。サポートマトリクスが対応状況を載せているのは、対話にUIを埋め込むMCP Apps・機械間認証のOAuth Client Credentials・企業ID基盤と連携するEnterprise-Managed Authorization・スキルを配るSkills over MCPの4つです。どれも両側が対応して初めて動くオプトイン機能で、capabilities.extensionsフィールドで宣言し合うネゴシエーションを経て有効になります。

使っているクライアントで何が使えないかを先に見ておくと、動かないときに「サーバー側の不具合か、クライアントが未対応なだけか」を切り分けられます。

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

拡張機能とは、コア仕様の外側に定義された追加機能です。モジュール性の高い機能(認証など独立した関心事)、特定業界向けの機能、将来コア仕様入りを目指す実験的機能を実装するための仕組みになっています。識別子は{vendor-prefix}/{extension-name}という形式で、io.modelcontextprotocolという予約プレフィックスを使います。

サードパーティが独自拡張を作る場合は、自分が所有するドメインを逆順にしたプレフィックス(com.example/my-extensionのような形)を使います。Javaのパッケージ命名と同じ発想で、名前の衝突を避ける作りです。

拡張はMCPのGitHub Organization内にext-接頭辞のリポジトリとして置かれます。認証系拡張はext-auth、MCP Appsはext-apps、Skills over MCPはext-skills、MCP Tasksはext-tasksが仕様の置き場所です。

まだ正式仕様になっていない段階のアイデアはexperimental-ext-接頭辞のリポジトリで育てます。Working GroupかInterest Groupに紐づけたうえで、SEP(仕様変更提案)プロセスを経て正式な拡張に昇格する流れです。

手順

拡張がSEPから正式になるまで

  1. 1

    提案する

    メインのMCPリポジトリに、種別をExtensions TrackとしてSEPを起票します。

  2. 2

    公式SDKで参照実装を作る

    少なくとも1つのSDKでの参照実装が、SEPをレビューに回す前の必須条件です。

  3. 3

    レビューを受ける

    コアメンテナーがSEPを審査し、採否の最終権限を持ちます。

  4. 4

    拡張リポジトリに公開する

    承認されたら、拡張リポジトリへ仕様を追加するPRを出します。

  5. 5

    他の実装が採用する

    公開後に、他のクライアント・サーバー・SDKが同じ拡張を実装できます。

この経路を通った例がMCP Tasksです。当初はコア仕様に実験的に置かれていたものが、2026-07-28リビジョンでio.modelcontextprotocol/tasksという独立拡張へ切り出されました。

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

4つの拡張が解決する課題

拡張機能識別子できること
MCP Apps識別子io.modelcontextprotocol/uiできること対話の中にグラフ・フォーム・動画プレーヤーなどインタラクティブなHTML UIをインライン表示する
OAuth Client Credentials識別子io.modelcontextprotocol/oauth-client-credentialsできることユーザーの対話的ログインなしで、サーバー間・機械間の認証を行う
Enterprise-Managed Authorization識別子io.modelcontextprotocol/enterprise-managed-authorizationできること企業のID基盤(IdP)経由で、組織単位のアクセス制御を一元化する
Skills over MCP識別子io.modelcontextprotocol/skillsできることMCPサーバーからスキルを見つけ、指示書と補助ファイルを読み出す

MCP Appsは、サーバーがツールの結果をテキストだけでなく操作可能なUIとして返せる拡張です。設定フォームやダッシュボードのようなツールと相性が良い機能です。

認証系の2拡張は、マシン間の定期実行や社内SSO配下のアクセス制御など、対話的ログインが前提にならない運用を受け持ちます。

Skills over MCPは、SKILL.mdを含むディレクトリ(Agent Skills仕様のスキル)の探索と取得をMCPで行う拡張です。コード審査や文書処理のように、複数のツールと参照資料を組み合わせる再利用ワークフローを、サービス側のサーバーに同梱して配る用途が想定されています。クライアントのスキル機能そのものとの違いはSkills over MCPの解説にまとめています。

MCP Tasksも拡張の一覧には載っていますが、サポートマトリクスの列には含まれていません。

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

マトリクスは14クライアントを載せています。コミュニティが管理する表なので、実際に使う前にMCP公式サイトのマトリクスで最新の状況を確かめてください。

クライアントMCP AppsOAuth Client CredentialsEnterprise AuthSkills
Claude(web)MCP Apps対応OAuth Client Credentials—Enterprise Auth—Skills—
Claude DesktopMCP Apps対応OAuth Client Credentials—Enterprise Auth—Skills—
VS Code(GitHub Copilot)MCP Apps対応OAuth Client Credentials—Enterprise Auth—Skills—
Microsoft 365 CopilotMCP Apps対応OAuth Client Credentials—Enterprise Auth—Skills—
CursorMCP Apps対応OAuth Client Credentials—Enterprise Auth—Skills—
ChatGPTMCP Apps対応OAuth Client Credentials—Enterprise Auth—Skills一部
Archestra.AIMCP Apps対応OAuth Client Credentials—Enterprise Auth対応Skills—
GooseMCP Apps対応OAuth Client Credentials—Enterprise Auth—Skills—
PostmanMCP Apps対応OAuth Client Credentials—Enterprise Auth—Skills—
MCPJamMCP Apps対応OAuth Client Credentials—Enterprise Auth—Skills—
PostHog CodeMCP Apps対応OAuth Client Credentials—Enterprise Auth—Skills—
fast-agentMCP Apps—OAuth Client Credentials—Enterprise Auth—Skills一部
MCP InspectorMCP Apps—OAuth Client Credentials—Enterprise Auth—Skills一部
mcpc(MCP CLI)MCP Apps—OAuth Client Credentials対応Enterprise Auth対応Skills対応

表を列ごとに数えると、対応の広がりは拡張によってまるで違います。

数字

14クライアントのうち、各拡張に対応しているもの

  • MCP Apps

    11

    表の14のうち、fast-agent・MCP Inspector・mcpcを除く全て

  • OAuth Client Credentials

    1

    mcpcのみ

  • Enterprise Auth

    2

    Archestra.AIとmcpc

  • Skills

    4

    対応はmcpcのみ。ChatGPT・fast-agent・MCP Inspectorは「一部」

ClaudeのwebアプリとClaude Desktopは、MCP Appsだけに対応しています。OAuth Client Credentials・Enterprise-Managed Authorization・Skills over MCPの3拡張は、どちらも対応欄が空です。

Skillsの列に印が付くクライアントは、MCP Appsの列に印があるクライアントとほとんど重なりません。MCP Appsがチャット・エディタ系のGUIに広がっているのに対し、Skillsと認証系の対応はCLIや検査ツールに偏っています。

Claude CodeのCLI自体は、この表に載っていません。VS CodeのGitHub Copilot拡張機能とClaude Desktopの対応差はVS CodeのMCP Apps対応とClaude Desktopの違いで、MCP Apps対応クライアントの全量一覧はMCP Appsの対応クライアント一覧で扱っています。

Skillsの「一部」は、リンク先がそれぞれ別のページです。ChatGPTはMCPサーバーからのスキル取り込みの手順、fast-agentは自身のSkills over MCPのドキュメント、MCP InspectorはCLIのスキル検証コマンド(--verify)の節が、それぞれの根拠になっています。「一部」が仕様のどこまでを指すかは行ごとに違い、表からは分かりません。

対応を宣言するJSONの中身

クライアントは、各リクエストの_metaにあるio.modelcontextprotocol/clientCapabilitiesの中で、対応する拡張を宣言します。MCP Appsなら次の形です。

"_meta": {
  "io.modelcontextprotocol/clientCapabilities": {
    "extensions": {
      "io.modelcontextprotocol/ui": {
        "mimeTypes": ["text/html;profile=mcp-app"]
      }
    }
  }
}

サーバーはserver/discoverのレスポンスでcapabilities.extensionsに対応拡張を列挙します。この往復が揃って初めて、両者は同じ拡張を前提に会話を始められます。拡張ごとに設定オブジェクトのスキーマが決まっていて、空のオブジェクトは「設定なし」の意味です。

Skills over MCPを宣言するサーバーは、resourcesのcapabilityと拡張の両方を載せなければなりません。任意の設定directoryReadはresources/directory/readへの対応を示し、既定値はfalseです。クライアントがskills/listやskills/getを送るのは、サーバーの宣言を確かめてからになります。

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のドキュメントに対応拡張の一覧を載せることになっています。拡張は既定で無効で、開発者が明示的にオプトインして初めて有効になります。

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

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

その場合の振る舞いは、対応している側の設計で決まります。仕様の説明は、コア仕様の挙動に戻るか、拡張が必須ならエラーで拒否する、という二択です。

くらべる

片側だけが対応しているとき

UIを持つサーバーの例

フォールバックを用意する

UI拡張に未対応のクライアントにも、テキストとして意味の通る結果を返します。ツールを呼んだ利用者には、UIの代わりに文字の結果が届きます。

認証拡張が必須のサーバーの例

接続を拒否する

対応していないクライアントからの接続を、サーバー側が拒否してかまいません。拡張が前提条件になっている場合の設計です。

「MCP Appsに未対応のクライアントでツールを呼んだら壊れた」という状況は、サーバーがフォールバックを用意していないときに起きます。動かないときは、クライアントの対応状況とサーバーのフォールバック実装の両方を切り分けの対象にできます。

自作クライアントを表に載せるには

自分でMCPクライアントを作る場合の手順は、マトリクスのページに書かれています。ext-authやext-appsのリポジトリで拡張仕様を読み、リクエストの_metaで対応を宣言します。サーバーのserver/discoverのレスポンスからextensionsを読み取り、拡張のプロトコル要件を実装します。最後にマトリクスの更新をプルリクエストで出します。

まとめ

Claudeで使うサーバーに認証系の2拡張やSkills over MCPを接続の必須条件として載せると、webアプリやClaude Desktopからは接続を断られます。MCP Appsを使うサーバーは、テキストで意味の通る結果を返すフォールバックを前提に作っておくと、マトリクスの空欄に左右されません。

MCPの接続方法自体の基礎はMCP実用ガイドにあります。

この記事を共有:XはてブLinkedIn
MCP をもっと見る →