AIコーディングエージェントのMCP対応状況を比較する — 5ツールの実装差

MCP対応状況で見るべきはトランスポートと認証方式

MCP(Model Context Protocol)サーバーをどれだけ豊富に繋げるかは、ツール自体の対応状況より先に「そのMCPサーバーが要求する通信方式と認証方式をクライアント側が受け付けるか」で決まります。Claude Code・Cursor・Cline・Windsurf・Roo Codeは全社がMCPをサポートすると謳っていますが、対応トランスポート・OAuthの有無・設定ファイルの置き場所は一致していません。あるMCPサーバーが「OAuth必須のStreamable HTTP」で公開されている場合、OAuthに対応していないクライアントでは接続できず、ヘッダーに手動でトークンを埋め込む代替手段を探すことになります。

比較する5つのツール

比較対象はClaude Code(CLI/VS Code拡張)・Cursor・Cline・Windsurf・Roo Codeです。いずれもMCPクライアントとしてサーバーを追加・管理する機能を持ちますが、Windsurfだけは事情が異なります。公式ドキュメントdocs.windsurf.comは現在docs.devin.aiへ転送されており、WindsurfはCognition社が提供する「Devin Desktop」アプリの一部として、レガシーのCascadeエージェントと新しいDevin Localエージェントを切り替える構成になっています。本記事のWindsurf欄は、このCascadeエージェントのMCP実装(~/.codeium/windsurf/mcp_config.json)を対象にしています。

対応トランスポートの比較表

MCPの通信方式にはstdio(ローカルプロセス起動)・SSE(レガシーのServer-Sent Events)・Streamable HTTP(現行の推奨方式)・WebSocketがあります。5ツールの対応状況は次のとおりです。

WebSocketに対応しているのはClaude Codeだけです。ドキュメントは「サーバーがイベントを能動的にプッシュするならWebSocket、リクエストに応答するだけならHTTPを使う」と使い分けを明記しており、OAuthとclaude mcp add --transportフラグはWebSocketでは使えずヘッダー認証限定になる点が制約です。SSEも--transport httpで追加した場合、v2.1.265以降はまずHTTPで接続を試み、サーバーが受け付けなければSSEへ自動的に切り替わる仕様です。

Clineの挙動には注意点があります。設定にtypeを書かないエントリは、Streamable HTTPではなく後方互換のためレガシーSSEとして扱われます。新しいサーバーを繋ぐときは"type": "streamableHttp"を明示しないと、意図せずレガシー方式で接続してしまいます。

認証方式の比較 — OAuth対応が分かれ目

リモートMCPサーバーの認証方式で最も差が出るのがOAuthへの対応です。

Claude CodeとCursorは、OAuthに対応していないサーバー向けの逃げ道も用意しています。Claude Codeはclaude mcp login <name>でOAuthフローを単独実行でき、動的クライアント登録に対応しないサーバーには--client-id・--client-secret・--callback-portで固定のOAuthアプリ認証情報を渡せます。Cursorも同様に、mcp.jsonのauthオブジェクトにCLIENT_ID・CLIENT_SECRET・scopesを書く静的OAuth設定を持ちます。

Cline・Roo Codeは、ヘッダーや環境変数でトークンを渡す方式が中心です。Roo Codeは"${env:GITHUB_PERSONAL_ACCESS_TOKEN}"のような環境変数を参照する構文をサポートしますが、OAuth専用のサインインフローはドキュメントに記載がありません。OAuthを必須とするリモートMCPサーバーを使う場合、この2ツールでは接続元のサービス側でトークンを別途発行してヘッダーに渡す運用になります。

設定ファイルのスキーマは似ているようで違う

5ツールとも設定のトップレベルキーはmcpServers(Windsurfも同様)で揃っていますが、細部のフィールド名が異なります。リモートサーバーのURLを指定するキーは、Claude Code・Cursor・Cline・Roo Codeがurlなのに対し、WindsurfはserverUrl(またはurl)を使います。

リモートサーバーをJSONで書く場合、Claude Codeは次の形です。

{
  "mcpServers": {
    "server-name": {
      "type": "http",
      "url": "https://api.example.com/mcp",
      "headers": { "Authorization": "Bearer ${TOKEN}" }
    }
  }
}

Cursorのリモートサーバー設定は、Claude Codeと違ってtypeを書かず、url(必要に応じてheadersやauth)だけで完結する形です(typeが必須になるのはCursorのSTDIOサーバーだけです)。Streamable HTTPを示すtypeの値もツールごとに異なり、Claude Codeが"http"、Clineが"streamableHttp"、Roo Codeが"streamable-http"という表記です。ただしClaude Codeはstreamable-httpをMCP仕様が使う正式名としてhttpの別名でも受け付けるため、Roo Codeの設定はそのままコピーしても通ります。一方、Clineのキャメルケース表記streamableHttpはClaude Codeでは受け付けられず、他クライアント向けの設定例をそのままコピーすると接続に失敗することがあります。

環境変数の埋め込み構文もツールごとに異なります。Claude Codeがサポートする構文は${VAR}と${VAR:-default}で、${env:VAR}形式はサポート構文に含まれていません。Cursorは${env:NAME}(:-defaultのようなフォールバック構文の記載はありません)、Roo Codeは${env:VAR}、Windsurfは${env:VAR}と${file:/path}(ファイルの中身を読み込む方式)をサポートします。Clineの設定例ではenvブロックに生の値を書く形が中心で、URL側の変数展開の記載はドキュメント上薄めです。

設定ファイルのスコープ(有効範囲)も揃っていない

同じMCPサーバーをプロジェクト単位で共有したいのか、自分の全プロジェクトで使いたいのかによって、どのファイルに書くべきかがツールごとに変わります。

Claude Codeはローカル(そのプロジェクトの自分専用・~/.claude.json)・プロジェクト(チーム共有・.mcp.jsonをリポジトリにコミット)・ユーザー(全プロジェクト共通・~/.claude.json)の3階層を持ち、同名サーバーが複数階層にあるときはローカル優先で解決します。Cursorも同様に、プロジェクト直下の.cursor/mcp.jsonとホームディレクトリの~/.cursor/mcp.jsonの2階層を持ちます。Roo Codeはグローバルなmcp_settings.jsonとプロジェクト直下の.roo/mcp.jsonの2階層で、プロジェクト設定がグローバル設定を上書きする方式です。

Clineは~/.cline/mcp.json(CLI)、もしくは拡張機能のMCP設定JSONが基本で、プロジェクト単位で切り替える専用の設定ファイルはドキュメント上見当たりません。Windsurf(Cascade)も~/.codeium/windsurf/mcp_config.jsonという単一のグローバル設定が基本で、チーム単位の統制は個別のプロジェクトファイルではなく管理者ダッシュボードのallowlistで行う設計です。プロジェクトごとに使うMCPサーバーを切り替えたいチームには、Claude Code・Cursor・Roo Codeのようにプロジェクトスコープの設定ファイルを持つツールのほうが向いています。

接続できるMCPサーバーの数に上限があるツールもある

MCPサーバーを増やしていくと、次に効いてくるのが「同時にいくつのツールを持てるか」というスケーラビリティです。ここも実装差があります。

Windsurf(Cascade)は、接続中のMCPサーバーが提供するツールの合計数に100個という明示的な上限を持っています。ドキュメントには「Cascadeは同時に最大100個のツールにしかアクセスできない」と明記されており、複数のMCPサーバーを繋ぐほどこの上限に近づきます。他の4ツールのドキュメントには、こうした総ツール数の明示的な上限は見当たりません。

Claude Codeはツール数の上限を設ける代わりに、ツール検索(Tool Search)という別の仕組みでスケールを担保しています。既定で有効なこの機能は、接続済みの全ツールを毎回コンテキストに載せるのではなく、必要なタイミングでツールを検索して呼び出す方式です。あわせて、1回のツール呼び出しの出力が1万トークンを超えると警告を出し、既定では2万5000トークンで出力を打ち切る仕組み(MAX_MCP_OUTPUT_TOKENSで変更可能)も持っています。これは「繋げるサーバーの総数」ではなく「1回の応答が肥大化しないか」を制限する、Windsurfとは別の軸のスケーラビリティ対策です。

プロトコル拡張機能への対応にも差がある

MCPの仕様には、ツール呼び出し以外にもプロンプトのテンプレート化(Prompts)、構造化データの参照(Resources)、サーバーがクライアントに追加情報を求めるElicitation、インタラクティブなUIを返すApps拡張など、いくつかの発展的な機能があります。この対応状況を最も詳しく公開しているのはCursorで、Tools・Prompts・Resources・Roots・Elicitation・Apps拡張のすべてに対応していると明記しています。とくにMCP Apps拡張は、MCPツールが通常のテキスト応答に加えてインタラクティブなUIビューを返せる仕組みで、5ツールの中で明示的にサポートを謳っているのはCursorだけです。Claude Codeのドキュメントは、サーバーからのElicitationリクエストへの応答(フォーム入力またはブラウザでの認証フローに答える形)、サーバーのroots/listリクエストへの応答(セッションの起動ディレクトリと--add-dirで追加したディレクトリを返す)、Prompts・Resourcesのlist_changed通知を受けた能力の自動更新を明記しており、独自のChannels機能(サーバーからセッションへイベントをpushする仕組み)も持っています。ただしApps拡張への対応を明記した記述は見当たりません。Cline・Windsurf・Roo CodeのドキュメントにもTools呼び出しへの言及はありますが、同じくApps拡張への対応を明記した記述は見当たりません。

Windsurf(Cascade)だけが持つ正規表現allowlist

企業向けの管理機能では、Windsurf(Cascade)のMCP allowlistが他4ツールより踏み込んだ実装を持っています。管理者はサーバーのcommandとargsの各要素を正規表現で指定でき、argsの配列長も含めて完全一致を要求するマッチングルールです。一度でも1つのサーバーをallowlistに載せると、それ以外の全サーバーが自動的にブロックされる仕様もあわせ持ちます。

Claude Codeの管理者向け制御は、固定のサーバー集合を配布するmanaged-mcp.json・managedMcpServersに加え、コマンドパターンとURLパターンで照合するallowedMcpServersによるallowlistとdeniedMcpServersによる拒否リストを持ちます(disabledMcpjsonServersは組織向けの統制ではなく、プロジェクトの.mcp.jsonサーバーをローカルで承認・拒否する設定です)。ただしWindsurfのように引数1つ1つを正規表現でマッチさせたり配列長の厳格一致を要求したりする仕組みはありません。Cursorも企業ダッシュボードでコマンドパターン・URLパターンによるallowlistを持ちますが、同じくWindsurfほど詳細なマッチングルール(引数ごとの正規表現・配列長の厳格一致)は公開されていません。

使い分け早見表

まとめ

MCP対応は「対応している/していない」の二値ではなく、トランスポートの種類・OAuthの有無・設定ファイルのスキーマという3つの軸で実装差が出ます。WebSocket対応と静的OAuth認証情報の両方を持つのはClaude Codeだけで、企業向けの細粒度allowlistではWindsurf(Cascade)が最も踏み込んでいます。Cline・Roo Codeはドキュメント上OAuth専用フローの記載が見当たらず、ヘッダー認証中心の運用になります。OAuthを必須とするサーバーを繋ぐ予定があるかどうかで選択が分かれます。Claude Code側のMCP設定手順はClaude Code MCP設定ガイド、ツールごとの権限ルールの書き方はClaude Code MCP権限ルールにまとめています。個別のMCPサーバー選びでは、シンボル単位でコード理解を強化するSerena MCPも選択肢になります。