社内APIやデータベースにAIエージェントから安全にアクセスさせたい場合、MCP（Model Context Protocol、AIモデルと外部ツール・データ源をつなぐ標準プロトコル）に対応したクライアントを選ぶ場面が出てきます。Claude Desktop、Cursor、VS Code、Windsurf、Cline、Zedはいずれも MCP に対応していますが、設定ファイルの置き場所も、OAuth（外部サービスへの認可を安全に行う仕組み）への対応度も、クライアントごとにばらばらです。あるエディタの公式ドキュメント通りに設定をコピーしても動かない、という状況に心当たりがあるなら、この整理が参考になるはずです。
MCPはもともと「AIがどのツールとどう話すか」というサーバー側の方言を統一するために作られたプロトコルです。ところが皮肉なことに、サーバー側の断片化が解消された結果、今度はクライアント側の方言が増えてしまいました。設定キーの名前、環境変数の渡し方、リモートサーバーへの認証フローへの対応具合は、6つのクライアントでそれぞれ異なります。これはSRE（Site Reliability Engineering、信頼性を工学的に担保する職能）の視点で見ると、認証情報の扱いと運用の再現性に関わる重要な選定ポイントです。
どんな場面でこの選定が必要になるか
社内のREST APIやDBをMCPサーバー経由でAIエージェントに公開する構成を組むとき、まず迷うのが「どのクライアントを開発者に使わせるか」です。
チームによってCursorを使う人もいればVS CodeのCopilot Chatを使う人もいて、同じMCPサーバーの設定を使い回したいという要望が出てきます。ここで設定方式の違いを把握していないと、ローカルでは動くのに別のクライアントでは「command not found」になる、といった障害調査に時間を取られます。
またリモートのMCPサーバーを運用し始めると、OAuth 2.1（認可の標準プロトコルの新しい版）のフローにクライアントが対応しているかどうかで、認証情報の扱い方が根本的に変わります。これはセキュリティ設計そのものに直結する判断です。
判断軸
クライアント選定では、次の4つの軸で整理すると自分のケースに当てはめやすくなります。
設定のスコープ管理です。プロジェクト単位で設定ファイルを置けるか、それとも全クライアント共通のグローバル設定しか持てないか。CursorとVS Codeは.cursor/mcp.jsonや.vscode/mcp.jsonのようにプロジェクトスコープの設定をサポートしており、リポジトリごとに異なるMCPサーバーを使い分けたいチームに向いています。
リモートOAuthへの対応度です。Claude DesktopとCursorはブラウザベースの認可フローを自動的に開き、リフレッシュトークンを保存してくれます。一方でWindsurfとZedは動的クライアント登録（認可サーバーに事前登録なしでクライアントを認識させる仕組み）への対応が歴史的に遅れており、認可サーバー側が事前登録済みクライアントしか受け付けない場合は、個人アクセストークンをヘッダーに手動で渡すフォールバックが必要になります。
スクリプト化・再現性です。CursorやVS Code、Zedは設定ファイルを直接編集できるため、dotfilesやIaC（Infrastructure as Code、インフラ構成をコードで管理する手法）のリポジトリに含めてチーム全体に配布できます。一方Clineは設定をGUIのMCP Serversパネルから行う方式で、非エンジニアのチームメイトには優しい反面、設定をコードとして管理したい運用には不向きです。
ツール数の上限とゲートウェイの要否です。クライアントは同時に公開できるツール数に上限があり、数十個程度が目安とされています。数百のエンドポイントを持つ社内APIをまるごと1つのMCPサーバーとして公開すると、黙って切り捨てられるツールが出てきます。この場合はMCPゲートウェイ（複数の内部APIを集約して公開する中間層）を挟んで、公開するツールを絞り込む設計が必要です。
クライアント比較
| クライアント | 設定の置き場所 | プロジェクトスコープ | リモートOAuth |
|---|---|---|---|
| Claude Desktop | claude_desktop_config.json（ユーザー単位） | 非対応 | 自動対応 |
| Cursor | .cursor/mcp.json | 対応 | 自動対応 |
| VS Code | .vscode/mcp.json | 対応 | 自動対応（新しめのリリース） |
| Windsurf | mcp_config.json | 非対応 | 部分対応 |
| Cline | 拡張機能のGUIパネル | 非対応 | 手動ヘッダーが一般的 |
| Zed | settings.json | 非対応 | 限定的 |
ケース別の推奨
リポジトリごとに異なるMCPサーバーを使い分けるチーム開発なら、CursorかVS Codeを選ぶのが妥当です。.cursor/mcp.jsonや.vscode/mcp.jsonをリポジトリにコミットしておけば（シークレットは環境変数参照にして）、クローンした全員が同じ設定を使えます。
個人のローカル環境で、ンプロジェクトを横断して使う共通ツール（たとえば社内ドキュメント検索など）を使いたいだけなら、Claude Desktopのグローバル設定で十分です。プロジェクトごとの切り替えが不要なぶん、設定の管理コストが低く済みます。
リモートのMCPサーバーを本番運用し、認可サーバー側でOAuth 2.1のダイナミッククライアント登録をサポートしているなら、Claude DesktopかCursorでブラウザ認可フローをそのまま使うのが安全です。トークンの保存・更新をクライアント任せにできます。
認可サーバーが事前登録済みクライアントしか受け付けない、あるいは社内の認証基盤がOAuthに未対応の場合は、個人アクセストークンをヘッダーで渡す方式に妥協することになります。この場合はどのクライアントを使っても大差はないため、チームの使い慣れたエディタを優先してよい局面です。
非エンジニアのメンバーにもMCPサーバーを触ってもらう必要があるなら、ClineのGUIパネルは設定ファイルを直接編集させずに済む利点があります。ただしチーム全体への設定配布はスクリプト化できないため、別途手順書を用意する前提になります。
あえて見送るべき条件
次のような条件では、いったん導入を見送るか別の対策を優先したほうがよい場合があります。
- 社内APIのエンドポイント数が数百規模で、ゲートウェイを用意する余裕がない場合。ツール数上限で機能が黙って切り捨てられ、原因特定に時間がかかります
- 認可サーバーがOAuth 2.1の動的クライアント登録に対応しておらず、かつWindsurfやZedでの自動認可を前提に設計してしまっている場合。個人アクセストークンの管理ルールを先に決める必要があります
- macOSのGUIアプリからMCPサーバーを起動する構成で、
npxやpythonのパスを絶対パスで書いていない場合。GUIから起動したプロセスはシェルのPATHを継承しないため、ターミナルで動いてもcommand not foundになります
設定前に確認しておきたいこと
クライアントを選ぶ前に、which npxで実行パスを確認し、設定ファイルには絶対パスを書いておくと、GUIアプリ特有のPATH問題を避けられます。
バージョンを固定せずnpx -y @acme/orders-mcpのような書き方をしていると、キャッシュされた古いビルドが動き続けることがあります。チーム共有の設定ではバージョンを明示するか、@latest運用のルールをドキュメント化しておくと安全です。
最後に、MCPサーバーが公開するツール数が数十を超える見込みがあるなら、先にゲートウェイパターンの導入を検討してください。クライアント選定よりも先に対処すべき構造的な制約です。
MCPクライアント選びは、設定ファイルの便利さよりも認証情報の扱いとスクリプト化のしやすさで決めるのが安全です。自分のチームがプロジェクトスコープの設定を必要としているか、リモートOAuthをどこまで自動化したいか、この2点を基準に選定を進めてみてください。