Cursor/Claude Code MCP連携 設定と落とし穴

CursorとClaude CodeをMCPでつなぐと、エディタ内の操作性とターミナル中心の拡張性を一つの流れで扱えるようになります。
この記事は、MCPをこれから実運用に載せたい開発者や、初回設定で止まりたくない人に向けて、CursorをMCPクライアントにする手順、Claude CodeをMCPクライアントにする手順、さらにClaude CodeをCursorからMCPサーバーとして呼ぶ構成までまとめて解説します。
要点は、Node.js 18+の前提を先に満たし、設定ファイルの置き場所と claude mcp add、/mcp の確認導線を外さないことです。
『Claude Code Docs: MCP を使用して Claude Code をツールに接続する』の公式手順を土台にしつつ、現場で詰まりやすい再接続やパス指定まで踏み込みます。
実際に設定してみると、緑の接続表示が出ていてもツールが呼ばれない瞬間があります。
私も一度、Cursor側のトグルを入れ直してログを確認したら復旧したことがあり、それ以降は接続できたように見える段階で止まらず、まず状態確認から入れる手順に固定しました。
MCPは「AI用のUSB-C」とも言われますが、配線だけ整えても通信確認を省くと初日運用は崩れます。
この記事では、その見落としを先回りで潰しながら、CursorとClaude Codeをその日から動かせる形まで持っていきます。

Cursor / Claude Code における MCP とは

MCPの役割とM×N解消

MCPはModel Context Protocolの略で、AIと外部ツールをつなぐ共通規格です。
GitHubSlackChrome系ブラウザ天気API自作CLIのように、つなぎたい先は増える一方ですが、AI側もCursorClaude Codeのように複数あります。
ここで個別接続を積み上げると、「AIごとにツール連携を作り、ツールごとにAI対応を増やす」というM×Nの組み合わせが発生します。
Cloud Aceの解説が「AI用のUSB-C」と表現しているのはまさにこの点で、USB-C対応機器なら同じ端子で接続できるように、MCP対応のクライアントとサーバーなら共通の約束事でつながる、という理解で入ると混乱が減ります。

本記事で扱う構成も、最初に3つへ分けて見ると整理できます。
1つ目はCursorをMCPクライアントとして使い、各種MCPサーバーへ接続する形です。
2つ目はClaude CodeをMCPクライアントとして使い、claude mcp add で外部ツールを足していく形です。
3つ目は少しひねりがあり、Claude CodeをCursorから呼ばれるMCPサーバーとして扱う形です。
最初は私も「どっちがクライアントなのか」でよく迷いましたが、誰が接続を開始して、誰がツールを提供するのかを図にして明示すると、設定ファイルの書き先や確認場所を取り違えなくなりました。

MCP自体は2024年11月に公表された比較的新しい規格ですが、周辺はすでに速いペースで進化しています。
自動発見、通信方式の進化、非同期処理の強化が示されており、単なる「外部ツール接続の小技」ではなく、エージェント実行の土台として拡張されていく流れが見えます。

役割の違いは、次の表で押さえると頭の中が散らかりません。

この見取り図を先に置いておくと、「設定は入れたのに出てこない」「緑表示なのに動かない」といった場面で、どちら側を見直すべきか切り分けやすくなります。

MCPは死んでない？　MCPの2026年ロードマップ公開　「AIツール接続」から「AI自律連携インフラ」へ

AIと外部ツールをつなぐ規格「MCP（Model Context Protocol）」の2026年ロードマップは、MCPの役割が「単なるツール接続の仕組み」から「AI同士が連携する基盤」へと広がりつつあることを示している。そのポイントを整理

atmarkit.itmedia.co.jp

Cursor/Claude Codeで何ができるか

CursorはVS Code系の操作感を保ったまま、エディタ内でAIとの往復を完結させやすいのが強みです。
そこにMCPを足すと、チャットからリポジトリ情報を取りに行ったり、ブラウザを操作したり、社内APIや自作CLIの結果を文脈として取り込んだりできます。
たとえばGitHubのIssue確認、Slackの投稿下書き、天気APIからの値取得、ローカルの運用スクリプト実行といった処理を、エディタから直接扱える形になります。

Claude Codeはターミナル中心のAIコーディングアシスタントで、コード理解、編集、コマンド実行に加えて、MCP経由で外部ツールへ広がります。
公式のClaude Code Docs: MCP を使用して Claude Code をツールに接続するでも、claude mcp add を軸にMCPサーバーを追加し、list や get、対話内の /mcp で管理する流れが案内されています。
CLIベースなので、設定の再現性を持たせたいときや、チームで同じ定義を共有したいときに相性が出ます。

CursorをMCPクライアントとして使う最短手順は、まず設定画面からサーバー追加の入口を開き、MCPサーバー定義を作ることです。
UIの文言はバージョンによって「Add new global MCP server」「Add Custom MCP」「New MCP Server」など揺れますが、やることは同じで、サーバー名、起動コマンド、必要なら引数や環境変数を入れます。
GUIで追加できる場合でも、その裏側では mcp.json 相当の定義が使われるため、途中からはファイル編集の理解があるほうが強いです。
CursorからClaude Codeを呼ぶ構成では、~/.cursor/mcp.json 系の設定ファイルを編集してサーバー定義を書く事例が多く、実務では claude コマンドをフルパス指定したほうが詰まりにくい場面があります。

ここで見落としやすいのが、緑表示だけで安心しないことです。
接続済みに見えても、ログパスの誤りや起動コマンドの解釈ミスで、実際にはツール呼び出しまで通っていないことがあります。
私も最初はUI上の色だけ見て先へ進み、実行段階で止まってから原因を探す流れを何度か繰り返しました。
いまは、追加直後に一度Refreshし、必要ならトグルをいったん無効化してから再有効化し、再接続が走ることを確認したうえで、短いプロンプトで実ツールを呼ばせるところまでをひとまとまりにしています。
見た目の接続成功と、実際のRPC往復は別物だと考えたほうが手戻りが減ります。

構成3パターンの整理

3つの構成は似て見えますが、設定の入口と確認ポイントが異なります。
Cursorをクライアントにする構成では、エディタの設定画面から追加する流れが最短です。
そこでサーバー定義を作成し、必要に応じて mcp.json を直接編集します。
GUIで一度入れてからファイルを開くと、どの項目が実際に保存されているか見えやすく、JSONの形もつかみやすくなります。
編集後は保存して終わりではなく、Refreshやトグルの再有効化で再接続を確認し、ツール一覧やチャット内の実呼び出しまで見ます。

Claude Codeをクライアントにする構成では、入口が明確で、claude mcp add が基本になります。
追加後は claude mcp list や claude mcp get、対話中の /mcp で状態を追えます。
CLI中心なので、状態確認の導線はCursorより文字情報寄りですが、そのぶん登録内容を見失いにくい構造です。
設定スコープを分けて管理しやすい点も利点で、他クライアントへ転用しやすい .mcp.json ベースの運用に寄せやすいのもこの系統です。

Claude CodeをCursorからMCPサーバーとして使う構成は、今回もっとも混乱しやすい部分です。
見た目はCursorの設定なのに、実際に起動されるのはClaude Codeなので、問題が出たときに「設定ファイルはどこか」「失敗しているプロセスは何か」を分けて追う必要があります。
ここでも私は役割を毎回図にするようになってから、パス指定ミスや接続先の取り違えが減りました。
Cursorがクライアント、Claude Codeがサーバー、と一文で書いてから設定に入るだけで、頭の中の配線が整います。

実務目線では、最短で触り始めるならCursorの設定画面から1つMCPサーバーを追加し、裏で生成される mcp.json を確認する流れがいちばん入りやすいのが利点です。
そこで接続表示が緑になっても止まらず、Refreshと再有効化で再接続が走るかを見て、短い実行テストまで通す。
この一連の確認を先に体に入れておくと、その後にClaude Code側の claude mcp add や、CursorからClaude Codeをサーバーとして呼ぶ構成へ移っても、どこで詰まっているのかを同じ手順で切り分けられます。

まず押さえたい前提条件と準備

NodeとClaude Codeのセットアップ

このセクションでは、設定を書き始める前に実行環境を揃えます。
Claude Codeはターミナルで動く前提のツールなので、エディタ側の設定より先に node と claude が素直に動く状態を作っておくほうが詰まりません。
とくに MCP を使う構成では、サーバー起動や外部ツール呼び出しが Node の実行環境に乗ることが多く、ここが曖昧だと後ろの手順まで連鎖して崩れます。

まず見ておきたいのが Node.js のバージョンです。
前提は Node.js 18+ で、古い Node では MCP 周りの起動で不安定さが出ます。
筆者も Node 16 のまま動かそうとして、設定ファイルの書き方より前に CLI の挙動で引っかかりました。
Node 18 以降に切り替えたら、同じコマンドでも反応が落ち着いたので、ここは象徴的な分岐点だと感じています。
確認はターミナルで次の 1 行です。

node -v

v18 以上なら先に進めます。
v16 以前が返る場合は、Node を更新してから作業したほうが切り分けが楽です。
MCP は AI と外部ツールをつなぐ共通プロトコルで、いわば「AI 用の USB-C」のような役割を持っていますが、接続口になる Node 側が古いと、その先の設定を整えても素直に立ち上がりません。

Claude Code本体の導入は OS ごとに手順が分かれます。
Claude Code Docs:Claude Code の概要やセットアップドキュメントに沿うと、Mac では Homebrew の cask、Windows では WinGet が基本導線です。
実行コマンドは次のとおりです。

{{ogp:https://code.claude.com/docs/ja/overview|Claude Code の概要 - Claude Code Docs|Claude Code は agentic coding ツールで、コードベースを読み取り、ファイルを編集し、コマンドを実行し、開発ツールと統合します。ターミナル、IDE、デスクトップアプリ、ブラウザで利用できます。|https://claude-code.mintlify.app/_next/image?url=%2F_mintlify%2Fapi%2Fog%3Fdivision%3D%25E3%2581%25AF%25E3%2581%2598%25E3%2582%2581%25E3%2581%25AB%26appearance%3Dsystem%26title%3DClaude%2BCode%2B%25E3%2581%25AE%25E6%25A6%2582%25E8%25A6%2581%26description%3DClaude%2BCode%2B%25E3%2581%25AF%2Bagentic%2Bcoding%2B%25E3%2583%2584%25E3%2583%25BC%25E3%2583%25AB%25E3%2581%25A7%25E3%2580%2581%25E3%2582%25B3%25E3%2583%25BC%25E3%2583%2589%25E3%2583%2599%25E3%2583%25BC%25E3%2582%25B9%25E3%2582%2592%25E8%25AA%25AD%25E3%2581%25BF%25E5%258F%2596%25E3%2582%258A%25E3%2580%2581%25E3%2583%2595%25E3%2582%25A1%25E3%2582%25A4%25E3%2583%25AB%25E3%2582%2592%25E7%25B7%25A8%25E9%259B%2586%25E3%2581%2597%25E3%2580%2581%25E3%2582%25B3%25E3%2583%259E%25E3%2583%25B3%25E3%2583%2589%25E3%2582%2592%25E5%25AE%259F%25E8%25A1%258C%25E3%2581%2597%25E3%2580%2581%25E9%2596%258B%25E7%2599%25BA%25E3%2583%2584%25E3%2583%25BC%25E3%2583%25AB%25E3%2581%25A8%25E7%25B5%25B1%25E5%2590%2588%25E3%2581%2597%25E3%2581%25BE%25E3%2581%2599%25E3%2580%2582%25E3%2582%25BF%25E3%2583%25BC%25E3%2583%259F%25E3%2583%258A%25E3%2583%25AB%25E3%2580%2581IDE%25E3%2580%2581%25E3%2583%2587%25E3%2582%25B9%25E3%2582%25AF%25E3%2583%2588%25E3%2583%2583%25E3%2583%2597%25E3%2582%25A2%25E3%2583%2597%25E3%2583%25AA%25E3%2580%2581%25E3%2583%2596%25E3%2583%25A9%25E3%2582%25A6%25E3%2582%25B6%25E3%2581%25A7%25E5%2588%25A9%25E7%2594%25A8%25E3%2581%25A7%25E3%2581%258D%25E3%2581%25BE%25E3%2581%2599%25E3%2580%2582%26logoLight%3Dhttps%253A%252F%252Fmintcdn.com%252Fclaude-code%252Fc5r9_6tjPMzFdDDT%252Flogo%252Flight.svg%253Ffit%253Dmax%2526auto%253Dformat%2526n%253Dc5r9_6tjPMzFdDDT%2526q%253D85%2526s%253D78fd01ff4f4340295a4f66e2ea54903c%26logoDark%3Dhttps%253A%252F%252Fmintcdn.com%252Fclaude-code%252Fc5r9_6tjPMzFdDDT%252Flogo%252Fdark.svg%253Ffit%253Dmax%2526auto%253Dformat%2526n%253Dc5r9_6tjPMzFdDDT%2526q%253D85%2526s%253D1298a0c3b3a1da603b190d0de0e31712%26primaryColor%3D%25230E0E0E%26lightColor%3D%2523D4A27F%26darkColor%3D%25230E0E0E%26backgroundLight%3D%2523FDFDF7%26backgroundDark%3D%252309090B&w=1200&q=100}}

# Mac
brew install --cask claude-code

# Windows
winget install Anthropic.ClaudeCode

インストール後に使う CLI コマンド名は claude です。
更新も別途必要で、Homebrew と WinGet で入れた場合は自動更新前提ではありません。
Mac では brew upgrade claude-code、Windows では winget upgrade Anthropic.ClaudeCode で追従します。
最初の導入時に古いバージョンのまま記事の手順をなぞると、UI やメッセージ差分で余計に迷うので、claude が起動することと、更新経路が見えていることを先に押さえておくと安定します。

Windows ではもうひとつ前提があります。
公式セットアップではGit for Windowsが必要です。
PowerShell だけで始めると、後で Git 系コマンドやパス解決まわりで手戻りが出ることがあります。
実際に使ってみると、CLI ツール同士をつなぐ場面では、エディタ設定よりシェルまわりの素直さが効いてきます。

設定ファイルの場所

Claude Codeのユーザー設定ファイルの配置は、OS やインストール方法によって異なる場合があります。

この手の設定で見落としやすいのが、PATH 任せにした実行ファイル指定です。
とくにCursorからClaude Codeを呼ぶ構成では、claude という名前だけで通すより、実行ファイルのフルパスを書いたほうが事故が減ります。
ターミナルでは動くのにCursor経由だと起動しない、という場面は、設定ファイルの JSON より PATH 解決で止まっていることが珍しくありません。
前のセクションでも触れたとおり、見た目の接続表示と実際の起動は分けて見たほうが切り分けが進みます。

Windows ではこの話がさらに実務的です。
パスにスペースが入るとダブルクォーテーションが必要になり、PowerShell と cmd では解釈も少し変わります。
MCP の stdio サーバーを Windows ネイティブで起動する場合、npx を直接渡すより cmd /c を挟んだほうが安定するケースがある、とClaude 。
設定ファイルを書き終えてから悩むより、まず同じコマンドをターミナルで単体実行し、起動する文字列をそのまま設定に写す、という順番のほうがブレません。

APIキーと環境変数の設計

MCP で外部サービスにつなぐと、認証情報の扱いも設計の一部になります。
ここで基準にしたいのは、秘密情報を設定ファイルやリポジトリに直書きしないことです。
mcp.json や .claude.json に API キーをそのまま入れると、設定共有が楽になる代わりに漏えい経路も増えます。
チーム利用ではもちろん、個人環境でもバックアップやスクリーンショット経由で露出しやすくなります。

そのため、API キーやトークンは環境変数で注入する形が扱いやすいのが利点です。
たとえば GitHub 連携なら、必要な権限だけを持つトークンを切り出して渡します。
GitHub では fine-grained PAT が用意されており、用途に応じて権限範囲を絞れます。
repo のように広い権限を何となく渡すのではなく、必要な操作に合わせて最小限に寄せたほうが、万一のときに被害範囲を限定できます。
MCP サーバーは外部 API やローカルツールを横断して触るので、便利さと引き換えに認証の面積が広がりやすいんですよね。

環境変数の設計では、「どのスコープで使う値なのか」を分けておくと後で混乱しません。
個人全体で使うキー、特定プロジェクトだけで使うキー、ローカル検証専用のキーを同じ名前で混在させると、どこで読み込まれているのか追いにくくなります。
Claude Code側でも設定のスコープを意識した整理ができるので、普段から「ユーザー共通」と「プロジェクト限定」を分ける発想にしておくと、使い回しと安全性の両方が保ちやすくなります。

認証まわりは「動けばよい」で進めると後で詰みやすい部分です。
実際に使ってみると、MCP サーバーそのものの追加より、トークン権限の不足や入れ場所のぶれで止まる場面のほうが多く出ます。
逆に言えば、Node のバージョン、claude コマンドの所在、設定ファイルの場所、API キーの渡し方を先に揃えておくと、その後の設定手順は素直に追えるようになります。

Cursor で MCP サーバーを追加する手順

GUIから追加

Cursorを MCP クライアントとして最短で試すなら、まずは設定画面から 1 台だけサーバーを足す流れが素直です。
設定を開いて MCP 関連のセクションに入り、「新規MCPサーバー」に相当する項目を選びます。
ここはCursorの版によって表記が揺れていて、「New MCP Server」「Add new global MCP server」「Add Custom MCP」のように見えることがあります。
ラベル名を探すというより、MCP サーバーを追加する導線を探すつもりで見たほうが迷いません。

入力する項目は、実務上は サーバー名、起動コマンド、引数、環境変数 の 4 つと考えると整理できます。
たとえばローカルの stdio ベース MCP サーバーなら、command に実行ファイル、args に起動引数、env に API キーを渡す構成です。
MCP の stdio は標準入力と標準出力で JSON-RPC をやり取りする方式で、『Model Context Protocolの examples』でもローカルツール連携の基本形として扱われています。
GUI でも、実際にやっていることはこの command / args / env の定義にすぎません。

ここで詰まりやすいのは、設定が保存できたことと、サーバーが実際に呼ばれることを同じ意味で見てしまう点です。
私の環境でも、GUI で追加して緑表示になったのに、チャット中ではツールが一向に使われないことがありました。
そのときは曖昧に任せるより、「天気MCPを使って」とプロンプトで明示したほうが安定して呼んでくれました。
接続済みの表示はあくまで起動の入口であって、モデルがそのツールを選ぶかどうかは別の段階です。

Example Servers - Model Context Protocol

A list of example servers and implementations

modelcontextprotocol.io

mcp.jsonを編集して追加

GUI で項目を埋めるだけでは細部を揃えにくいときは、mcp.json を直接編集したほうが早い場面があります。
Cursorまわりは一次情報として GUI ラベルやファイル配置の説明が強くなく、記事や実例を追いながら合わせる形になりやすいので、ここは 実例ベース で捉えるのが現実的です。
よく使われるのは ~/.cursor/mcp.json で、ユーザー単位の設定をここに置く形です。

最小構成は、サーバー名の下に command と args を置く形です。たとえばこんな JSON です。

{
  "mcpServers": {
    "weather": {
      "command": "npx",
      "args": ["-y", "weather-mcp-server"]
    }

API キーが必要なサーバーなら、env を追加して渡します。

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@example/github-mcp-server"],
      "env": {
        "GITHUB_TOKEN": "your_token_here"
      }

ただし、前のセクションで触れた通り、秘密情報をそのまま書く形は避けたいところです。
実運用では env のキー名だけを揃え、実際の値は安全な方法で注入する設計に寄せるほうが後で困りません。
GitHub連携を使うなら、トークンの権限も広げすぎず、用途に必要な範囲に留めたほうが整理しやすくなります。

設定ファイル編集の利点は、GUI だと見えにくい差分を文字列として追えることです。
とくに command と args の分け方、環境変数のキー名、パスの引用符の有無は、JSON で見たほうが原因を切り分けやすくなります。
CursorからClaude Codeや Node 系の stdio サーバーを呼ぶときは、PATH に乗っているつもりのコマンドが拾われずに止まることがあるので、単に claude や node と書くより実行ファイルの位置を明示したほうが安定します。

Windows ではここがさらに露骨で、スペースを含むパスはダブルクォーテーションが必要ですし、npx 系の起動では cmd /c を挟んだほうが通る場面があります。
『Claude Code Docs: MCP を使用して Claude Code をツールに接続する』でも、Windows ネイティブ環境でのコマンド指定に注意が入っています。
ターミナル単体では動くのにCursor経由だと起動しないときは、JSON の書式より先に、同じ command と args をシェルでそのまま再現できるかを見るほうが近道です。

MCP を使用して Claude Code をツールに接続する - Claude Code Docs

Model Context Protocol を使用して Claude Code をツールに接続する方法を学びます。

code.claude.com

接続確認・Refresh・再有効化

実際には、チャット中にツール利用の提案が出るか、ツール実行の許可ダイアログ（UI の文言はバージョンによって異なる可能性があります）が現れるか、ログにサーバー起動やツール呼び出しの痕跡が出るか、という複数の面で見る必要があります。

このとき、UI の色やラベル文言はバージョンによって変わる可能性があります。
本文中で特定の英語ラベルを固定的に示すのは避け、ここでは「ツール実行の許可ダイアログ／許可フロー」といった一般表現で記述します。

接続が怪しいときの復旧も、設定の保存し直しより 再読込 のほうが効くことがあります。
MCP サーバーのトグルをいったん OFF にしてから ON に戻す、設定画面の Refresh を押す、Cursor自体を再起動する、という順で戻ることがあります。
CloudBuildersの実装例でも、見た目の状態と実際の接続が噛み合わない場面で再接続を挟む流れが紹介されていました。
特に mcp.json を外で編集したあと、UI が古い状態を握ったままになっていると、JSON は正しいのに反映されないという妙なズレが起きます。

ログも見逃せない判断材料になります。
サーバーが起動できていないなら、ツール候補が出ない以前にプロセスが落ちていますし、認証エラーなら起動はしても呼び出し時に止まります。
GUI の一覧だけではその差が見えません。
緑でつながって見えるのに仕事をしないときほど、許可ダイアログ、ツール実行の提案、ログメッセージの 3 つを並べて見ると原因が分かれます。

運用面では、最初から複数の MCP を常用セットにしないほうが安定します。
ツール候補が多い構成は便利ですが、導入初期は「呼ばれない」の原因が、接続失敗なのか、選択競合なのか、プロンプト不足なのか判別しにくくなります。
まず 1 つだけ有効にして実働確認を取り、その後で 2 つ目、3 つ目を足していくほうが、Cursorを MCP クライアントとして使う感覚を掴みやすくなります。

Claude Code で MCP サーバーを追加する手順

claude mcp add の基本構文と追加例

Claude Code側で MCP サーバーを足すときの起点になるのが、『Claude Code Docs: MCP を使用して Claude Code をツールに接続する』にある claude mcp add です。
基本構文は claude mcp add [options] -- [args...] で、 が登録名、-- の後ろが実際に起動するサーバーコマンドです。
ローカルの stdio サーバーを登録するなら、この形で覚えておくと迷いません。

たとえば天気系のサーバーを 1 つだけ試すなら、次のような最小構成から入ると切り分けが楽です。

claude mcp add --transport stdio weather -- npx -y @example/weather-mcp

登録名を weather にしておけば、あとで一覧を見たときも役割がすぐ分かります。
GitHub系のサーバーでも考え方は同じで、名前だけ github に変え、後段のコマンドを対象サーバーに合わせれば流れは変わりません。
最初から複数本を同時に足すより、まず 1 サーバーだけで通すほうが、接続失敗なのか権限不足なのかを見分けやすくなります。

GUI から触りたい場合は、Cursorの設定画面で MCP サーバー追加の項目を開き、サーバー名、command、args を入力して保存する流れになります。
ただ、画面上で追加した内容も、実体としては mcp.json に落ちる運用が中心です。
途中から手修正に切り替える場面も多いので、設定画面で一度ひな形を作ってから mcp.json を開き、command と args が意図した形になっているかを見るほうがズレを減らせます。
CLI で登録して構成をコード化しておくと、マシン移行のときにも同じ設定をすぐ戻せました。
新しい端末で 1 個ずつ GUI を触り直すより、残しておいたコマンドをそのまま流すだけで揃うので、再現性の差がはっきり出ます。

Windows では、前のセクションで触れた通り、npx をそのまま渡すより cmd /c を挟んだほうが通る場面があります。
パスにスペースが入る構成では引用符の崩れで起動に失敗しやすいので、GUI で追加したあとも mcp.json の中身まで見ておく意味があります。
設定画面だけで済ませず、最終的な JSON と CLI コマンドの両方を把握しておくと、あとで同じ環境を別マシンに移すときに詰まりません。

list/get/remove と /mcp で状態確認

追加したあとの確認は、まず CLI 側で登録状態を見ます。
一覧は claude mcp list、個別の詳細は claude mcp get 、不要になった定義の削除は claude mcp remove です。
get まで見ると、名前だけ登録されていて実行コマンドが想定と違う、といった事故に気づけます。

このあたりはスコープも意識しておくと混乱が減ります。
MCP の設定はユーザー全体で使うものと、プロジェクト単位で閉じたいものが分かれます。
毎回使う汎用サーバーはユーザースコープ、リポジトリ専用のサーバーはプロジェクトスコープ、という分け方にしておくと、別案件に移ったときに不要なツールまで混ざりません。
Cursor側でも設定画面から追加したグローバル設定と、ワークスペース配下の mcp.json で持つ設定が混在しやすいので、どこに定義があるのかを先に揃えておくほうが後で効きます。

IDE 内の確認は、拡張のチャットで /mcp を打つ導線が手早いです。
『Claude Code Docs: Use Claude Code in VS Code』の流れに沿って見ると、登録済みサーバーだけでなく、そこから見えているツールやリソースまで辿れます。
Cursorを主戦場にしていると、設定画面の緑表示だけでつながった気になりがちですが、そこはまだ入口です。
一覧が緑でも、実際には再接続できておらず、チャット側でツールが見えないことがあります。

Cursorの設定画面から追加したあとに挙動が曖昧なら、いったん該当サーバーを無効化してから再度有効化し、Refresh をかけて再接続の成否を見る流れが実務では安定します。
mcp.json を直接編集した直後は、UI が古い状態を握っていることがあるためです。
見た目が緑でも、再有効化後にチャットで /mcp を開くとツールが消えていることがあり、そこで初めて設定ミスや起動失敗に気づく、という順番は珍しくありません。

Use Claude Code in VS Code - Claude Code Docs

Install and configure the Claude Code extension for VS Code. Get AI coding assistance with inline diffs, @-mentions, pla

code.claude.com

更新・バージョン整合性の確認

MCP 周りで不思議な不具合が出たとき、設定そのものだけでなく、Claude Code本体のバージョン差も見ておきたい判断材料になります。
Homebrewで入れた場合は brew upgrade claude-code、WinGetで入れた場合は winget upgrade Anthropic.ClaudeCode が更新コマンドです。
どちらも自動更新前提ではないので、古い CLI のまま設定だけ触っていると、ドキュメントどおりに入力しても挙動が合わないことがあります。

更新前後で合わせて見たいのが claude --version です。
ターミナルで見えている claude と、Cursorから呼ばれている claude が別物になっていると、CLI では通るのに IDE では噛み合わない、というズレが起きます。
とくに mcp.json 側で実行パスを明示していない構成では、その差が表面化しやすいのが利点です。
前のセクションでも触れた通り、実行ファイルの位置をはっきり書く構成に寄せると、この種の食い違いを追いやすくなります。

運用の感覚としては、MCP サーバーを増やす前にClaude Code本体と接続先サーバーの両方を揃え、1 サーバーだけで /mcp の表示と実呼び出しを確認してから横に広げるほうが、遠回りに見えて結局早いです。
CLI で claude mcp add を使って構成を残しておくと、更新後に作り直す場面でも手順が散らばりません。
設定画面で追加、必要に応じて mcp.json を編集、緑表示だけで終わらず Refresh と再有効化で再接続を確かめる、という流れを一つの型として持っておくと、Cursorを MCP クライアントとして使うときのブレが減ります。

実例1: Cursor から外部 MCP サーバーを使う

CursorをMCPクライアントとして最短で試すなら、まずは失敗要因が少ない天気MCPから入ると流れを掴みやすくなります。
設定の入口はCursorの設定画面にあるMCP関連メニューで、バージョンによってAdd new global MCP serverAdd Custom MCPNew MCP Serverのように表記が揺れます。
ラベルは少し違っても、やることは同じで、外部MCPサーバーの定義を追加して保存するだけです。

GUIから追加する場合は、コマンドと引数を分けて入れます。
天気MCPの例では、npx でパッケージを直接起動する構成が扱いやすく、実例としては command に npx、args に -y と対象パッケージ名を並べる形です。
Model Context Protocolの stdio サーバーは標準入出力でやり取りする前提なので、ローカルで起動できるコマンドとして定義できればCursor側からそのまま呼べます。
Model Context Protocolの examples でも stdio ベースの構成が入門例として多く、考え方の相性がいいやり方です。

GUIで追加したあとに、そのまま mcp.json も開いて中身を見ておくと詰まりどころを減らせます。
UI上では登録できていても、JSON側で command や args が意図どおりになっていないことがあるからです。
たとえばプロジェクト単位で持たせるなら .cursor/mcp.json に次のような形で定義します。

{
  "mcpServers": {
    "weather": {
      "command": "npx",
      "args": ["-y", "weather-mcp-server"]
    }

（※パッケージ名は実際に使うものに置き換えてください。上記は最小構成の閉じ例です。）

チャットからの呼び出しとRun Tool表示

接続の確認は設定画面ではなく、チャットで行うほうが確実です。
天気MCPを追加したら、Cursorのチャットに「東京の天気を取得して」と入力します。
ここでツールが認識されていれば、ツール実行の許可フローとして許可ダイアログが表示され（UIラベルはバージョンで異なる場合があります）、実行対象のMCPツールを承認できる流れに入ります。
Cursorのツール許可まわりは説明されていて、保護設定や自動実行の扱いが分かれています。

実務上は、この許可ダイアログが出ること自体が最初の関門です。
設定一覧でサーバーが見えていても、チャット側でツール候補として現れなければ、MCPサーバーは実働状態に入っていません。
チャットで実行を許可したら、そのまま実行ログも合わせて見ます。
どのツールを呼んだのか、呼び出し時にエラーが出ていないか、レスポンスが返っているかまで追えるので、単に「答えが返ってきた」で済ませないほうが原因切り分けが速くなります。
（参照記事へのリンクはここでは示していません） うまく動かないときは、設定項目を片っ端から触るより、起動条件を順に潰したほうが早く収束します。
Claude Code系の前提としてNode.js 18以上が必要という整理はすでに触れた通りで、npx ベースのMCPでもここが外れていると起動以前で止まります。
ターミナルで同じコマンドをそのまま打って起動するかを見ると、JSONの問題なのか、そもそも実行環境の問題なのかが分かれます。

• 必要な環境変数を使うサーバーなのに未設定のままになっていないかどうか確認してください。
• Cursorで Refresh や無効化→再有効化を行い、再接続できているかどうか確認してください。
• チャットの指示文でツール利用を明示しているか

パスまわりは見落としやすい箇所です。
特にWindowsでは、スペースを含むパスやコマンド解釈の違いで起動に失敗しやすく、spawn ENOENT 系のエラーに繋がります。
スペースを含むパスは引用符で囲う必要がありますし、『Claude Code Docs: MCP を使用して Claude Code をツールに接続する』でもWindowsネイティブでは cmd /c を挟む注意が出てきます。
Cursorで mcp.json を書くときも、この系統の問題はそのまま起きます。

環境変数が必要なMCPサーバーでは、サーバー一覧が生きていても実行時に失敗することがあります。
天気MCPのように導入しやすい例はここでつまずきにくいのですが、別の外部API系サーバーへ広げると、APIキー未設定でRun Tool後にエラーになる流れが増えます。
設定画面の色ではそこまで分かりません。

もう一つ地味に効くのが、プロンプト側の書き方です。
チャットで曖昧に質問すると、モデルが通常回答で済ませてツールを呼ばないことがあります。
「東京の天気を取得して」「MCPツールを使って東京の天気を調べて」のように、取得行為を明示したほうが、ツール呼び出しの判定が安定します。
ツールがあるのに使われない場面では、接続不良とプロンプト不足が混ざって見えるので、ここも切り分け対象です。

この一連の確認で詰まりがちな順番は、実際には mcp.json の誤記、再接続不足、チャット側でツールを呼べていない、の3つに集まりやすい印象です。
CursorをMCPクライアントとして使うときは、設定追加、JSON確認、Refresh、再有効化、チャット実行、ログ確認までをひと続きの作業として扱うと、導入直後の迷子を避けやすくなります。

実例2: Claude Code を Cursor から MCP サーバーとして使う

構成の全体像

ここでの向きは、CursorがMCPクライアント、Claude CodeがMCPサーバーです。
先にこの役割を固定しておくと、どちらの設定を触るべきかで迷いません。
普段はClaude Codeをターミナル側の操作主体として見ることが多いのですが、この構成では逆にCursorから呼ばれる側として扱います。
つまり、設定の中心はCursor側にあり、Claude Codeはその呼び出し先として登録される、という理解です。

イメージとしては、Cursorのチャットやエージェント機能からツールを呼ぶと、その先でClaude CodeのCLIが起動し、stdio経由でやり取りする流れになります。
MCPの標準トランスポートとしてstdioが使われる整理はModel Context Protocolの公式ドキュメントにも沿っていますし、ローカルプロセス同士をつなぐ用途ではこの形が一番扱いやすい部類です。

実務では、設定ファイルに1行足しただけで終わり、とはなりませんでした。
特に混乱しやすいのが、「Claude CodeにMCPサーバーを追加する」のではなく、「Cursorに対してClaude CodeをMCPサーバーとして見せる」点です。
前者は claude mcp add が主役ですが、今回の主役はCursor側の設定画面と mcp.json です。
DevelopersIO: Claude CodeをCursorからMCPサーバとして使う（リンクはここでは示していません）でもこの向きで整理されていて、CLIそのものをCursorから呼ぶ発想だと腑に落ちます。

mcp.jsonへの登録

最短で進めるなら、Cursorの設定画面からMCPサーバー追加の導線を開き、そのまま mcp.json を編集する流れが素直です。
UI上のラベルは版によって Add new global MCP server だったり New MCP Server だったり揺れますが、到達点は同じで、最終的には ~/.cursor/mcp.json にサーバー定義を書きます。
GUIだけで完結する版もありますが、実際にはJSONを直接見たほうが原因を追いやすく、再現性も保てます。

考え方は単純で、Claude Codeの実行ファイル claude を command に置き、必要な引数を args に分けて渡します。
このとき、claude をPATH任せにせずフルパス指定に寄せると安定します。
私の環境でも、相対パス指定だと開発マシン間で動作がばらつきました。
フルパスに変えた途端に安定し、トラブルが激減しました。
Nodeのバージョン管理ツールやシェル初期化の違いが絡むと、同じ設定を配っても片方では起動して片方では沈黙する、という状況が起こりがちです。
そういう揺れを消すには、どの実行ファイルを叩くのかを明示したほうが早く収まります。

mcp.json では、コマンド本体だけでなく環境変数の置き場もあわせて考えておくと後で困りません。
APIキーを使うツール連携があるなら env にまとめる、プロジェクトごとに切り替えたい値があるならグローバル設定とワークスペース設定を分ける、といった設計にしておくと、別案件へ移ったときに設定を崩さず済みます。
CursorはMCP関連の設定スコープが版や画面によって見え方を変えるので、ワークスペース固有の値をグローバルに混ぜない整理が効いてきます。

Windowsではここにもう一段注意点があります。
パスにスペースが入るならダブルクォーテーションが必要で、PowerShellと cmd では引用符の解釈も揃いません。
Microsoftの案内どおり、スペースを含むパスは引用符で囲う前提で書いたほうが安全ですし、Claude Code Docs: MCP を使用して Claude Code をツールに接続するでもWindowsネイティブのコマンド実行では cmd /c を挟む注意が出ています。
mcp.json に書いたコマンドをターミナルでそのまま再現できる形にしておくと、JSONの問題なのか、コマンド解釈の問題なのかを切り分けやすくなります。

なお、ここで使うコマンド名や引数は版によって動く形が変わることがあります。
Claude Codeは更新サイクルが速く、Cursor側のMCP UIも表記や導線が入れ替わることがあるので、具体例を写経するときはDevelopersIO: Claude CodeをCursorからMCPサーバとして使うのような実例記事と、公式のMCPドキュメントの両方を見比べながら揃えるほうが手戻りが少なくなります。

接続テストと権限確認

mcp.json を保存してCursor側でサーバーを有効化すると、まず状態表示が緑になることがあります。
ただ、この緑表示だけでは足りません。
前のセクションでも触れた通り、一覧上で接続済みに見えても、実際にツール呼び出しまで通らないケースは普通にあります。
今回の構成では特に、Cursor側が見えていることと、Claude Code側が起動して応答していることを両方確認する必要があります。

接続テストでは、Cursorで対象サーバーを有効化したあと、実際にチャットからツール利用が発生する指示を投げます。
そのうえでClaude Code側の /mcp やログを見て、登録内容と疎通を確かめます。
Claude Code Docs: Use Claude Code in VS CodeにあるIDE統合系の導線を見ても、UI表示だけでなく実動作を追う前提になっています。
サーバーが起動していれば、少なくとも呼び出しの痕跡が残るので、何も出ていなければCursorからそこまで到達していません。

ここで詰まりやすいのは、権限まわりと再接続です。
Cursorにはツール実行の許可フローがあり、MCPツール保護や自動実行関連の設定によっては、一覧で見えていても実行直前で止まります。
緑の表示を見て安心してしまうと、この段差を見落とします。
実際には、ツール実行ダイアログが出るか、許可後にログが流れるか、再度同じ操作をしても通るかまで見ておかないと、初回だけ動いた定義なのか、常用できる定義なのか判別できません。

再接続確認では、Refresh と再有効化が効きます。
mcp.json を触ったあとにRefreshをかけ、いったんトグルをOFFにしてから再度ONに戻すと、設定の読み直しと再接続をまとめて試せます。
これで再びツールが現れ、Claude Code側にも呼び出しが記録されるなら、設定はひとまず固まっています。
逆に、最初は通ったのに再有効化後は沈黙するなら、パス解決や環境変数の受け渡しに問題が残っていることが多いです。

接続済みだがAIが使わない時

Cursorで接続が見えているのに、チャットではまったくツールが呼ばれない場面は珍しくありません。
ここで起きているのは「つながっていない」よりも、「AIがそのツールを選ぶ根拠を持てていない」ケースです。
特にMCPサーバーをいくつも並べた直後は、候補が多すぎて埋もれます。
Cursorで同時に扱えるツール数は最大40という情報がありますが、上限まで積めることと、毎回うまく選ばれることは別の話です。
実務では最初から欲張らず、まず1つだけ有効にした状態で動作を見るほうが切り分けが早く進みます。

ツールが出てこないときは、プロンプトの書き方でも差が出ます。
私の環境では、Run Toolが出ない場面で「この質問は天気MCPを使って答えて」と明示すると、成功率が一気に上がりました。
AI側が通常の知識回答で済ませるか、MCPを呼ぶべきか迷っている状態では、ツール名や用途を文中に入れたほうが通りやすくなります。
曖昧に「調べて」と書くより、「この件はClaude Code経由のMCPツールを使って確認して」のように役割まで書いたほうが、ツール選択のブレが減ります。

もう一つ見落とされやすいのが、サーバー側のログです。
Cursor側で緑でも、実際にはMCPサーバーに一度もリクエストが届いていないことがあります。
この段階ではUIの見た目より、サーバープロセスに呼び出し痕跡が残るかどうかのほうが信用できます。
Claude Code Docs: MCP を使用して Claude Code をツールに接続するでも、登録状態や呼び出し状況をCLI側で追える前提になっています。
画面上では接続済み、サーバー側では無反応という食い違いが出たら、まず「AIが使わなかった」のか「呼ぼうとして失敗した」のかをログで分けて見ると詰まりにくくなります。

役割の混同も、使われない原因として根深いです。
Cursorがクライアントで、Claude Codeや天気MCPがサーバーなのか、それともClaude Codeがクライアントとして別のMCPを呼ぶのか。
この整理が曖昧なまま設定を増やすと、どこに指示を書けばよいのか、どこのログを見ればよいのかが毎回ぶれます。
私は mcp.json のコメントや名前付けの時点で「client」「server」を書き分けるようにしてから、確認箇所を見失いにくくなりました。

緑表示でも動かない時

緑表示は「定義が認識された」ことの確認にはなりますが、「実際に動いた」証明にはなりません。
ここで疑うべきものは、だいたい3つに絞れます。
ログパスや起動コマンドの誤り、環境変数の未設定、そして設定変更後の再読込漏れです。
見た目だけ整っていても、起動直後にプロセスが落ちていれば、チャットからは沈黙して見えます。

コマンドまわりでは、Claude Codeの前提条件と実行バイナリの整合を先に見ます。
Node.js 18+ が前提なのに古いNodeが拾われていたり、claude --version では通るのにCursorからは別のPATHが参照されていたりすると、同じマシンの中で結果が割れます。
前のセクションで触れたフルパス指定が効くのはこのためです。
ターミナルで動くコマンドをそのまま mcp.json に移したつもりでも、IDE経由では別のPATHで起動され、claude や node が見つからないことがあります。

Windowsではここに引用符の問題が重なります。
スペースを含むパスを囲っていない、PowerShell前提の書き方を cmd 解釈で渡している、cmd /c を挟むべきところを省いている、といった小さな差で起動そのものが失敗します。
こういうケースは「接続は緑だが何も起きない」に見えやすく、実際にはプロセス起動前で止まっています。
パスに空白があるProgram Files配下の実行ファイルを使うときは、目視では正しそうでも引用符不足で落ちることがあるので、ここを先に疑ったほうが早く絞れます。

環境変数も同じくらい多い落とし穴です。
GitHub系やAPI連携のMCPは、サーバー定義が正しくても env に必要な値が入っていなければ、起動はしても処理だけ失敗します。
しかもこの状態は、一覧表示だけでは見えません。
CloudBuilders: CursorでECS/EKSのMCP Serverを使うのような実装例でも、緑表示の先にログ確認が必要になるのはこのためです。
認証エラーや読み込み失敗は、画面の色よりログの文面に先に出ます。

設定を直したあとに動かない場合は、修正内容そのものより、再読込が中途半端なことも多いです。
Cursorは起動後に設定を取りこぼすことがあり、保存した mcp.json をその場で読んでいないことがあります。
このときはRefreshだけで戻る場合もありますが、トグルをいったんOFFにして再度ONにする操作まで入れたほうが反映が安定します。
起動中のCursorが古い設定を握ったままになる場面では、ファイルを直しても見た目が変わらず、結果として「緑なのに動かない」が続きます。

CursorはMCP設定を一度で素直に読み込むこともあれば、変更を取りこぼしたまま走り続けることもあります。
こういうときは原因追及を広げる前に、再読込の手順を固定したほうが早いです。
私がまず試すのは、対象サーバーを無効化してから有効化し直し、その後でウィンドウを再読み込みする流れです。
順番を決めておくと、設定ミスなのか、単なる読込漏れなのかを見分けやすくなります。

手順としては、対象MCPをOFFにする、設定画面または mcp.json の内容を保存する、再度ONにする、必要ならCursorのウィンドウを再読み込みする、という並びが安定します。
Refreshだけでは古いプロセスが残ることがあり、逆に再起動だけではトグル状態が更新されないこともあります。
無効化から有効化まで入れると、設定の再読込と再接続をまとめてやり直せます。

この典型パターンは、起動直後に設定が読まれていないときにも効きます。
とくにCursorを開いたまま mcp.json を触ったあと、一覧は前のまま、チャットでは新しい設定が使われない、という状態で止まりやすいのが利点です。
トグルを再ONにすると、新しい command や args、env の内容までまとめて取り込み直されることがあり、そこで初めてツールが出てきます。

再読込で戻るかどうかを見ると、問題の層も見えてきます。
無効化→有効化→ウィンドウ再読み込みで直るなら、設定内容より読み込みタイミングの問題だった可能性が高いです。
これで変わらない場合は、claude --version が通るか、Node.js 18+ を満たしているか、指定した実行ファイルがPATH上にあるかを順に見たほうが筋が通ります。
CursorからClaude Codeを呼ぶ構成では、IDEの見た目だけではなく、CLI前提が崩れていないかまで合わせて見る必要があります。

もう一歩踏み込むなら、WindowsではPATH任せをやめてフルパスに寄せるだけで、再読込後の安定度が上がることがあります。
スペースを含むパスはダブルクォーテーションで囲い、必要なら cmd /c を経由させる形にそろえると、再起動のたびに挙動が変わる状態を抑えやすくなります。
再読込で直る症状は軽く見えますが、実際には設定読込、PATH、引用符、役割整理のどこかにズレがある合図でもあります。
ここをそのままにすると、別のMCPサーバーを足した瞬間にまた同じ場所で止まります。

セキュリティと運用の注意点

APIキー管理と権限最小化

CursorやClaude CodeでMCPを広げ始めると、詰まりやすいのは接続設定そのものより、認証情報の置き場所と権限の広さです。
APIキーやPATを mcp.json やリポジトリ内の設定ファイルに直接書く運用は、共有時にそのまま漏れる経路を作ります。
鍵は環境変数か、ローカルの安全な秘密管理に置いて、設定ファイル側には参照だけ残す形のほうが事故の面積を小さくできます。

権限も同じで、動いたからそのままにする運用は後から効いてきます。
実際、運用でいちばん効いたのは「鍵の棚卸し日」をルール化したことでした。
使っていないトークンを消し、不要なスコープを外すだけで、普段の作業中に感じる不安が目に見えて減ります。
とくにGitHub連携では、repo を何となく付けたままにせず、public_repo や read:org で足りる場面を切り分けるだけでも、漏えい時の影響範囲が違ってきます。

MCPサーバーの数が増えるほど、無効化していないだけのサーバーが残りがちです。
Cursorはツールの許可管理や allowlist / denylist を持っており、『Cursor Docs』 でも自動実行対象の制御が前提になっています。
常用しないMCPサーバーを有効のまま置くより、不要なものは無効化し、使わなくなった定義は削除するほうが筋が通ります。
権限最小化はOAuthスコープやPATだけでなく、「そもそも接続先を減らす」ことまで含めて設計したほうが保守しやすくなります。

本番に近い環境へ持ち込む前には、OAuthスコープとPATの権限範囲を一度棚卸しして、作業内容と対応が取れているかを見直しておくと崩れません。
読み取りだけで足りるサーバーに書き込み権限を付けたまま動かすと、設定ミスが起きたときに被害の向きまで広がります。

Cursor Docs

Cursor is the best way to build software with AI.

docs.cursor.com

設定ファイル・拡張ディレクトリのレビュー

不審なリポジトリを開くときは、ソースコード本体だけでなく設定も一緒に読む前提にしたほうが安全です。
MCPやエージェント連携では、危ない動作が src/ ではなく .claude/、.vscode/、.cursor/ の中に入っていることがあります。
レビュー対象をアプリコードだけに限定すると、起動時に読み込まれる設定やツール定義を見落とします。

たとえば .cursor/ 配下の mcp.json や関連設定には、どのコマンドを起動するか、どの環境変数を渡すかがそのまま書かれます。
ここに見慣れない実行ファイル、不要に広い権限を前提にしたサーバー、意図が読めないラッパースクリプトが混ざっていれば、レビューの優先度は高いです。
.vscode/ の tasks や settings、.claude/ のプロジェクト固有設定も同じで、見た目はただの補助ファイルでも、実際には外部コマンド起動や認証情報参照の入口になります。

体感としては、怪しい挙動の原因がコードより設定にあった、という場面は珍しくありません。
とくに他人のサンプルをそのまま持ち込んだリポジトリでは、ディレクトリ名が自然でも中身は雑に足し込まれていることがあります。
レビュー時に package.json や実装ファイルだけ追っていると、.claude/ や .cursor/ 側で別のコマンドが呼ばれていることに気づきません。
設定ファイルもコードレビュー対象に含める、という線引きを最初から置いておくと、この見落としを減らせます。

自作サーバーでも同じです。
stdioベースのMCPサーバーはローカルプロセスとして動くぶん、設定の一行がそのまま実行経路になります。
前のセクションで触れたPATHや引用符の話は動作面の落とし穴でしたが、運用面では「何を起動する設定なのか」を人が読んで説明できる状態に保つことが効きます。
意味の説明が付かない command や args は、その時点でレビュー対象として濃く見たほうが整理できます。

ログと監査の設計

MCP連携は、接続できるようになった後のログ設計で差が出ます。
原因調査のためにログを厚くすると、今度は機密データが出力されやすくなります。
APIレスポンス全文、Authorizationヘッダー、PAT、プロンプト内の秘密情報がそのまま残る構成は、障害解析より漏えいのほうが先に問題になります。
残すべきなのは、失敗した操作名、呼び出したサーバー、時刻、成否、必要最小限のエラー内容です。

ログの出力先も運用設計に含めておくと、後で散らかりません。
ローカル開発ではターミナル出力だけで足りますが、チーム利用に寄るとファイル出力や集中管理の経路が必要になります。
その際に、どこへ保存され、誰が読めて、いつ消えるのかまで決めておかないと、調査用ログがそのまま長期保管されます。
ローテーションを入れて保持期間を区切るだけでも、蓄積した秘密情報の量を抑えられます。

監査の観点では、「誰がどのMCPサーバーを有効化し、どの権限で使っていたか」が追える状態に寄せると、問題が起きたときの切り分けが速くなります。
特定のツール呼び出しで失敗が続いたのか、権限変更の直後に不具合が出たのか、鍵の差し替えで止まったのかが見えるからです。
MCPは便利なぶん、IDEの中で複数の外部系統が見えにくくつながります。
だからこそ、ログは「出せるだけ出す」ではなく、「あとで責任範囲を追える最小単位を残す」という考え方のほうが運用に合います。

今日やるチェックリスト

最初の一歩は、読み取り専用のstdioサーバーを1つだけ登録して、動く状態を両側で確認することです。
Cursorでは接続状態の表示が緑になっているかを見て、Claude Codeでは /mcp や CLI の一覧確認で登録内容と起動状態を確かめます。
ここを欲張って同時に増やすより、1本ずつ通したほうが原因が濁りません。
実際、1サーバーから始める運用に切り替えてから、トラブル対応は半分くらいまで減り、導入時の心理的な壁も一気に下がりました。

問題が出たら、切り分けは3点に絞ると進みます。
役割の再確認で「今触っているのがクライアント側かサーバー側か」を戻し、command と args はフルパスで見直し、反映系の不調は再読込で潰します。
Model Context Protocolの stdio はローカルプロセス連携の基本形なので、ここが安定すると次の拡張でも迷いにくくなります。

• 読み取り専用のstdioサーバーを1つだけ追加する
• CursorのUI表示とClaude Codeの /mcp・CLI の両方で状態確認する
• 詰まったら「役割の再確認」「フルパス化」「再読込」で切り分ける

次に試す連携先

次の拡張先として相性がいいのは、GitHubSlackブラウザのような安全な読み取り系です。
まずは参照だけで価値が出る連携から広げると、権限設計と運用ルールを崩さずに実用域へ持っていけます。
GitHubならトークンの権限を絞ったうえでリポジトリ確認、Slackなら検索や参照、ブラウザなら取得中心の操作から始める流れが堅実です。
認証やスコープの設計は GitHub Docsや Cursor Docsの考え方に沿って最小権限で揃え、常用しないサーバーは無効化して接続面を締めておくと、日々の運用が散らかりません。