MCPサーバーはClaude・ChatGPT・Cursorで何が変わるか

同じMCPサーバーなのに挙動が違って見える理由

MCPサーバーは1つ作れば、Claude・ChatGPT・Cursorのどれに繋いでも動きます。プロトコルはコア仕様の範囲で共通だからです。ツール呼び出し(tools/call)、リソース取得、プロンプトのやり取りといった基本動作は、どのホストでも同じ手順で成立します。

それでも「ChatGPTでは画面が出ないのにClaudeでは出る」「Cursorだと一部の応答形式が反映されない」といった差が実際に起きます。原因はプロトコル本体ではなく、ホストがどの拡張機能(extensions)に対応しているかにあります。コア仕様は共通、拡張機能はホストごとに実装状況が違う——この二層構造を理解すると、挙動差の見え方が整理できます。

MCPの用語では、Claude・ChatGPT・Cursorのような製品は正確には「MCPホスト」です。ホストは接続するMCPサーバーごとに専用の「MCPクライアント」を内部で1つずつ生成し、そのクライアントがサーバーとの接続を維持します。本記事で「クライアント」と呼ぶときは、この意味でのホスト製品(あるいはホストが内部生成するクライアント)を指しています。

プロトコルが共通でも拡張機能で差が出る仕組み

MCPの拡張機能は常にオプトインです。クライアント(ホスト)側は各リクエストの_meta["io.modelcontextprotocol/clientCapabilities"]にあるextensionsで対応を宣言し、サーバー側はserver/discoverレスポンスのextensionsフィールドで対応を宣言します。両者が一致した拡張だけが実際に有効になります。ここでいうクライアントとは、Claude・ChatGPT・CursorのようなLLMを埋め込んだホストアプリケーションのことです。

たとえば、あるMCPサーバーがMCP Apps(io.modelcontextprotocol/ui)を実装し、ツールの説明に_meta.ui.resourceUriでインタラクティブなHTML画面を紐づけているとします。

• ホストがMCP Appsに対応していれば、ツール呼び出しの結果としてサンドボックス化されたiframeにHTML画面が描画されます。ユーザーはグラフをクリックしたり、フォームに入力したりできます
• ホストがMCP Appsに対応していなければ、同じツール呼び出しの結果はテキストや構造化データとして返るだけです。プロトコル上のエラーにはならず、機能が「格上げされない」形でフォールバックします

サーバー側のコードは一切変えていません。差を生んでいるのは、ホスト(Claude / ChatGPT / Cursor)がその拡張を実装しているかどうかだけです。この切り分けを知らずに「サーバーのバグではないか」と実装側を疑って時間を使ってしまう例は珍しくありません。挙動差の原因は多くの場合サーバーでなくホスト実装の側にあります。

Claude・ChatGPT・Cursorの対応状況

公式サイトに掲載されているExtension Support Matrix(コミュニティが更新している一覧)で確認できる範囲では、MCP Appsについて次の対応状況になっています。

3つとも表明上はMCP Appsに対応しています。つまり、同じMCPサーバーの同じツールを呼んだとき、3ホストとも画面自体は描画される見込みです。ここで実務上重要になるのが、対応表明があることと、実際の描画品質・操作感が同一であることはイコールではないという点です。チャット中心のホスト(Claude・ChatGPT)とエディター統合が主軸のホスト(Cursor)では、画面をどこに・どの大きさで配置するかというUI上の判断も異なります。

ホストごとにiframeのサイズ制約、許可するcsp(コンテンツセキュリティポリシー)の範囲、sendOpenLinkのような個別capabilityの扱いが異なります。仕様上は「MCP Appsに対応」でも、実際にどこまでのJavaScript API・外部リソース読み込みを許可するかはホストの実装判断に委ねられています。したがって「対応している」という1行の情報だけで、3ホストの体験が完全に同じだと期待するのは早計です。

認証系の拡張ではさらに差が開く

MCP Appsは3ホストとも足並みが揃っていますが、認証系の拡張機能では状況が変わります。OAuth Client Credentials(自動化システム向けのマシン間認証)とEnterprise-Managed Authorization(企業IdP経由の一元アクセス統制)については、サポート表を見る限り、Claude・ChatGPT・Cursorのいずれも対応を表明していません。エンタープライズ向けクライアント(Archestra.AI)が先行している段階です。

これは、個人利用が中心のチャットホストと、業務システムへの統合を前提とするエンタープライズ向けクライアントとで、認証まわりの優先度が違うことの表れです。CI/CDパイプラインからMCPサーバーを自動呼び出ししたい、あるいは従業員ごとの個別承認を廃してIT部門で一元管理したい、という要件がある場合、この3ホストのどれを使ってもまだ標準の対話的認可フロー(ブラウザが開いてユーザーがログインする方式)に頼ることになります。

実務でどう確認すればよいか

3ホストのどれかで想定通り動かないとき、切り分けの順番は次の通りです。

1. コア仕様の問題か拡張機能の問題かを区別する。ツール呼び出し自体が失敗するならコア仕様側(認証・接続設定・サーバーのエラーログ)を疑い、画面や自動認証だけが機能しないなら拡張機能側の対応差を疑う
2. ホストの拡張対応をサポート表で確認する。このサポート表はコミュニティが更新しているため、空欄は「非対応の確定」ではなく「未反映の可能性」を含む。重要な判断の前には該当ホストの公式ドキュメントも当たる
3. サーバー側の拡張実装も確認する。ホストが対応していても、MCPサーバー自体がその拡張を実装していなければ同じくフォールバックする

自作のMCPサーバーを複数ホストで配布する場合は、拡張機能に依存する体験(画面描画など)をコア機能の上乗せとして設計し、非対応ホストでもテキスト応答だけで最低限の操作が完結するようにしておくと、ホスト間の差異に振り回されずに済みます。これは段階的強化(progressive enhancement)の考え方そのもので、Webフロントエンドで新しいブラウザAPIを使うときの設計方針と同じです。対応ホストではリッチな画面、非対応ホストでは最低限のテキスト応答という2段構えにしておけば、どのホストでツールを配布しても機能停止は起きません。

このアプローチを取ると、サーバー開発者は「ホストの対応状況を常に追いかける」作業から解放されます。3ホストのうちどれかが新しい拡張に対応しても、しなくても、サーバー側のコードを変更する必要がないからです。ネゴシエーションが自動で行われる設計は、サーバー側とホスト側の開発サイクルを独立させるための仕組みでもあります。

よくある質問

MCPサーバー側で「対応ホストごとに実装を分ける」必要はあるか

いいえ、その必要はありません。サーバーは拡張機能への対応をserver/discoverレスポンスのextensionsフィールドで宣言するだけで、あとはホスト側との自動ネゴシエーションに任せます。ホストが対応していれば拡張機能が有効になり、対応していなければ自動でコア仕様の応答にフォールバックするため、サーバー側の実装を分岐させる必要はありません。

3ホストで同じMCPサーバーの動作確認をするにはどうすればよいか

MCP Inspectorのような開発ツールでプロトコルレベルの応答を確認したうえで、実際に使う各ホスト(Claude・ChatGPT・Cursor)にサーバーを接続し、画面描画や認証フローがホストごとにどう振る舞うかを個別に確認するのが確実です。プロトコルが共通でも、ホストのUI実装まではプロトコルが保証しないためです。

ローカルサーバーとリモートサーバーで挙動差の出方は変わるか

STDIO(標準入出力)接続のローカルサーバーは通常1つのクライアントとだけ通信し、Streamable HTTP接続のリモートサーバーは複数クライアントに同時対応します。ただし拡張機能のネゴシエーション自体は接続方式に関わらずクライアントごとに独立して行われるため、ローカル・リモートの違いが挙動差の直接の原因になることはありません。

まとめ

MCPサーバーはClaude・ChatGPT・Cursorのどこでもコア仕様のレベルでは同じように動きますが、拡張機能への対応状況はホストごとに独立して決まります。「プロトコルは共通・体験はホスト実装依存」という二層構造を覚えておけば、動作の違いに遭遇したときも慌てずに切り分けられます。MCP Appsは3ホストとも対応表明済みで画面描画自体は期待できる一方、実装の細部(csp範囲やcapability制御)まで同一とは限りません。認証系の拡張はまだどのホストも対応しておらず、自動化・企業統制の用途では標準の認可フローが前提になります。挙動が違って見えたときは、コア仕様と拡張機能のどちらの層で差が出ているかをまず切り分けてください。拡張機能の全体像はMCP拡張機能のサポート状況を表でどう読むかで、Claude CodeへのMCPサーバー導入手順はClaude Code MCP設定ガイドで扱っています。CursorとClaude Codeを併用する開発フローについてはCursorとClaude Codeの併用ワークフロー実践ガイドも参考になります。