こんにちは、ミナトです。CursorでMCPサーバーを入れたのに「0 tools enabled」「No tools found」「no tools or prompts」と出ると、設定できているのか壊れているのか分かりにくいですよね。調べた内容を整理すると、よくある原因はMCPサーバーそのものより、Cursorから見た実行コマンド・Node.jsのパス・npxの扱い・環境変数・ツール単位の有効化あたりに集まっています。

この記事では、CursorのMCP設定で「0 tools enabled」と表示される時に見る順番を、初めての方にも分かるように整理しました。公式ページ、GitHub Issue、Cursorフォーラム、Qiita、Zennなどの情報を元に、何から確認すれば手戻りが少ないかを中心にまとめます。当サイトではアフィリエイト広告を利用しています。記事内のリンクから商品やサービスを購入・申込された場合、運営者に報酬が発生することがあります。

この記事のポイント
✅ 「0 tools enabled」は、MCPの設定欄に出ていてもCursorがツール一覧を受け取れていない状態として見る
✅ まずはmcp.jsonの書き方、commandとargsの分け方、JSON構文を確認する
✅ npxやNode.jsのパス問題が多いため、フルパス指定やMCP Inspectorでの単体確認が有効
✅ Cursor v1.0以降はツール単位の有効・無効設定も確認したい
今日のセールをまとめてチェック！
本日のセール・タイムセールをまとめてチェックできます。
Amazon
楽天市場
Yahooショッピング
メルカリ

cursor 0 tools enabledで最初に見るべき原因と切り分け

cursor 0 tools enabledで最初に見るべき原因と切り分け
  1. cursor 0 tools enabledは「MCPは見えているがツール取得に失敗している状態」と考える
  2. mcp.jsonのcommandとargsを分けるだけで改善する場合がある
  3. npxがCursor側から見えていないと0 tools enabledになりやすい
  4. Node.jsをNVMやVoltaで管理している環境ではフルパス指定が近道になる
  5. MCP Inspectorで単体起動できるか見ると原因を絞りやすい
  6. Cursor本体の再起動で設定の読み込み直しが必要になることがある

cursor 0 tools enabledは「MCPは見えているがツール取得に失敗している状態」と考える

【AI】【業務効率化】【職場】cursor 0 tools enabledは「MCPは見えているがツール取得に失敗している状態」と考える

CursorのMCP設定画面にサーバー名が出ているのに「0 tools enabled」と表示される場合、まず見たいのはサーバー登録そのものが失敗したのか、登録後のツール取得で止まっているのかです。

GitHubやCursorフォーラムで確認できた事例では、MCPサーバーの項目は表示されているのに、ツール数が0件になっていました。つまり「Cursorに設定は読まれているが、実際に使えるツール一覧を取得できていない」状態として扱うと、原因を探しやすくなります。

この時点でいきなり再インストールするより、設定ファイル、実行コマンド、Node.js、npx、環境変数の順で見る方が、手戻りは少なめです。特にWindowsでは、コマンドプロンプトでは動くのにCursorからは動かない、という話も見られます。

📌 症状の見え方

表示・症状 まず疑う場所
MCPサーバー名は出るが0 tools enabled ツール一覧の取得失敗
No tools found MCPサーバーの起動またはListToolsの失敗
no tools or prompts サーバー起動後に能力情報を受け取れていない可能性
spawn npx ENOENT Cursorからnpxが見えていない可能性
Cursor再起動後も変わらない mcp.json、PATH、認証情報、実行方式の見直し

ここで大事なのは、「0 tools enabled」という表示だけで原因を1つに決めないことです。サーバー側が対応していない可能性もありますが、調べた範囲ではローカル環境のPATHやnpxの呼び出し方が話題に上がるケースが多くありました。

たとえばCursorフォーラムでは、spawn npx ENOENTというログが出ている例がありました。これは一般的には「npxを起動しようとしたが見つからない」という方向で見るエラーです。Cursorの画面だけを見ていても分かりにくいため、ログや単体起動テストまで見るのが現実的です。

🧭 最初の判断メモ

判断したいこと 見る場所
Cursorが設定を読んでいるか Cursor Settings > MCP
サーバーが起動しているか MCPログ、Cursor DevTools、単体起動
toolsが返っているか MCP Inspector
commandが見えているか where npx、where node
設定反映済みか Cursor完全終了後の再起動

公開情報の中では、Cursorフォーラムに「MCPService」「No connected servers found」「spawn npx ENOENT」などのログ例が掲載されていました。ログが読める場合は、画面表示よりもログを優先して見る方が早いです。

参考URL: https://forum.cursor.com/t/mcp-servers-no-tools-found/49094

「0 tools enabled」と出た時は、まず焦って設定を全部消すより、Cursorは何を実行しようとして、どこで止まったのかを見るのが入口です。ここが分かると、次の確認に進みやすくなります。

mcp.jsonのcommandとargsを分けるだけで改善する場合がある

【AI】【業務効率化】【職場】mcp.jsonのcommandとargsを分けるだけで改善する場合がある

MCPの設定でかなり見落としやすいのが、commandとargsの書き方です。commandに全部まとめて書くと、人間には分かりやすく見えても、Cursor側では別の意味で解釈されることがあります。

たとえば、次のように書きたくなる人は多いはずです。

{
  "command": "npx -y @playwright/mcp@latest"
}

ただ、MCP設定では一般的に、実行するコマンド本体と引数を分けて書きます。Zennの記事でも、この点が静的チェックの項目として整理されていました。

🧩 commandとargsの考え方

項目 役割 例
command 実行するプログラム本体 npx
args commandに渡す引数 ["-y", "@playwright/mcp@latest"]
env 環境変数 APIキー、TRANSPORTなど
mcpServers MCPサーバー定義のまとまり playwrightなど

修正後のイメージは、次のような形です。

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    }
  }
}

もちろん、これは例です。実際には使うMCPサーバーごとにパッケージ名や必要な環境変数が変わります。提供元のREADMEや公式ドキュメントに設定例がある場合は、そちらを優先してください。

✅ mcp.jsonで見るポイント

チェック項目 見る内容
JSON構文 カンマ、かっこ、引用符が崩れていないか
command コマンド本体だけになっているか
args 引数が配列になっているか
env APIキーやTRANSPORT指定が必要か
重複定義 同じMCPサーバーを別名で複数入れていないか

特にWindowsでは、パスの区切り文字にも注意が必要です。JSON内では\をそのまま書くとエスケープ文字として扱われるため、C:\\Users\\...のように書く必要が出ます。

このあたりは地味ですが、かなり大事です。「MCPサーバーが悪い」と考える前に、まずmcp.jsonを整えるだけで状況が変わるかもしれません。

参考として、Zennの記事では「no tools or prompts」系の切り分けとして、mcp.jsonの静的チェック、MCP Inspectorでの単体起動、成功した設定の書き戻しという流れが紹介されていました。

参考URL: https://zenn.dev/nayu_ai/articles/87ca47bfbe3d86

mcp.jsonは一度崩れると原因が見えにくいので、修正前にコピーを残しておくと安心です。大きく触る前に、1つのMCPサーバーだけに絞って動作を見るのもおすすめです。

npxがCursor側から見えていないと0 tools enabledになりやすい

【AI】【業務効率化】【職場】npxがCursor側から見えていないと0 tools enabledになりやすい

「ターミナルではnpxが動くのに、Cursorでは0 tools enabledになる」というケースでは、Cursorが起動する環境からnpxが見えていない可能性があります。

Cursorフォーラムには、MCPのログとしてspawn npx ENOENTが出ている例がありました。ENOENTは一般的には「指定されたファイルやコマンドが見つからない」方向のエラーとして見ます。つまり、Cursorがnpxを起動しようとして失敗している可能性があります。

ここでややこしいのは、普段使っているターミナルとCursorの内部実行環境が同じとは限らないことです。Macならzshやbash、WindowsならPowerShellやcmd、さらにNVMやVoltaなどのNode管理ツールが絡みます。

🧪 npx確認の基本

確認したいこと Windows macOS / Linux
npxの場所 where npx which npx
nodeの場所 where node which node
npmの場所 where npm which npm
バージョン node -v node -v
npmバージョン npm -v npm -v

コマンドが見つからない場合は、Node.jsのインストールやPATH設定を見直す必要があります。ここは環境によって違うため、この記事だけで一律の答えは出しにくい部分です。

一方で、GitHub Discussionでは「npxではうまくいかなかったが、nodeのフルパスとserver.jsを指定したら動いた」という趣旨の報告もありました。NVMなどでNode.jsを管理している場合、Cursorの起動環境にその設定が読み込まれないことがあるようです。

🧭 npx周りで起きやすいこと

状況 起きているかもしれないこと
ターミナルでは動く ログインシェルではPATHが通っている
Cursorでは0 tools Cursor側ではPATHが通っていない
npx ENOENT npxコマンドが見つかっていない可能性
npx実行時にモジュール不足 npxの一時キャッシュや依存関係の問題かもしれない
bunxに変えたら表示された例 npx経由の問題を回避できた可能性

ただし、bunxに変える方法は、誰にでもすすめられる標準解とは言い切れません。調べた範囲では、特定の環境で助かった例として出ていました。まずはnpxのパス確認、次にフルパス指定、最後に別の実行方式を検討する順番が自然です。

参考URL: https://github.com/eyaltoledano/claude-task-master/discussions/690

Windowsの場合、npx.cmdのフルパスを使う方が通りやすいこともあります。たとえばC:\\Users\\ユーザー名\\AppData\\Roaming\\npm\\npx.cmdのような形です。実際の場所は環境で違うため、where npxで確認してください。

「0 tools enabled」はMCPサーバー側の問題に見えますが、実際にはCursorがnpxを起動できていないだけというケースもあり得ます。ここを先に見ると、余計な再設定を減らせます。

Node.jsをNVMやVoltaで管理している環境ではフルパス指定が近道になる

【AI】【業務効率化】【職場】Node.jsをNVMやVoltaで管理している環境ではフルパス指定が近道になる

NVM、Volta、asdfなどでNode.jsを管理している場合、MCP設定では少し注意が必要です。普段のターミナルではNode.jsが使えていても、Cursorが同じ初期化ファイルを読み込むとは限りません。

GitHub Discussionでは、Cursorがbash系の環境を使うため、zshやbashの設定が想定通り読み込まれず、npxが使えなかったという内容がありました。その結果、nodeのフルパスとMCPサーバーの実体ファイルを指定する形で解決した例が紹介されています。

この考え方は、Windowsでも参考になります。npx経由でうまくいかない場合、グローバルインストールした実体コマンドや.cmdファイルを直接指定する方が安定することがあります。

🛠 フルパス指定が向いているケース

ケース フルパス指定を検討する理由
NVMを使っている Cursor側でNVM初期化が読まれない可能性
Voltaを使っている npxやnodeの解決が環境依存になりやすい
Windowsでnpxが不安定 .cmdの直接指定が効く場合がある
MCP Inspectorでは動く 成功したcommandをそのまま戻しやすい
チーム内で一部だけ動かない 個人PCのPATH差分を疑いやすい

たとえば、Macの例では次のような発想です。

{
  "mcpServers": {
    "taskmaster-ai": {
      "command": "/Users/name/.nvm/versions/node/v20.10.0/bin/node",
      "args": [
        "/Users/name/.nvm/versions/node/v20.10.0/lib/node_modules/task-master-ai/mcp-server/server.js"
      ]
    }
  }
}

Windowsなら、where nodeやwhere npxで出たパスを確認して、必要に応じて.cmdファイルを指定します。JSON内の\は\\にする点も忘れないようにしたいところです。

📌 Windowsでのパス例の考え方

種類 例
node本体 C:\\Program Files\\nodejs\\node.exe
npmグローバルコマンド C:\\Users\\name\\AppData\\Roaming\\npm\\xxx.cmd
npx C:\\Users\\name\\AppData\\Roaming\\npm\\npx.cmd
npmキャッシュ C:\\Users\\name\\AppData\\Local\\npm-cache
Cursor設定 ~/.cursor/mcp.json相当の場所

ただし、パスを固定すると、Node.jsのバージョンを変えた時に設定が古くなることがあります。チームで共有するmcp.jsonに個人PCのパスを入れる場合は、共有してよい内容かも確認が必要です。

このあたりは「きれいな設定」より「まず動く設定」を優先した方がいい場面もあります。特に仕事で急ぎの作業をしているなら、MCP Inspectorで動いたフルパスを一度Cursorに戻して、後から整える進め方が現実的です。

MCP Inspectorで単体起動できるか見ると原因を絞りやすい

【AI】【業務効率化】【職場】MCP Inspectorで単体起動できるか見ると原因を絞りやすい

「Cursorの中でだけ見ていても原因が分からない」という時に便利なのが、MCP Inspectorです。MCPサーバーをCursorから切り離して、単体で起動できるかを確認できます。

Zennの記事では、MCP Inspectorを使ってサーバーを単体起動し、Capabilitiesにtoolsやpromptsが出るか確認する流れが紹介されていました。これはかなり実用的です。Cursor側の問題なのか、MCPサーバー設定そのものの問題なのかを分けられるからです。

起動例としては、一般的に次のようなコマンドが紹介されています。

npx -y @modelcontextprotocol/inspector

Inspector上でChild process (stdio)を選び、commandとargumentsを入れて試します。ここで動くなら、その設定をCursorのmcp.jsonへ戻す、という考え方です。

🔍 MCP Inspectorで見ること

見る項目 意味
起動できるか commandとargsが最低限合っているか
toolsが見えるか MCPサーバーがツール定義を返しているか
promptsが見えるか プロンプト機能を提供しているか
エラー内容 PATH、JSON、依存関係、認証の切り分け
envの必要性 APIキーやTRANSPORT指定が必要か

ここでtoolsが表示されない場合、CursorではなくMCPサーバーの起動条件を疑います。APIキーが必要なサーバーならenvが足りないかもしれません。stdio指定が必要なサーバーなら、TRANSPORT=stdioなどの設定が必要になることもあります。

一方、Inspectorでは動くのにCursorでは0 tools enabledなら、Cursor側の設定反映、PATH、ツール単位の有効化、再起動などを見ます。こうして分けるだけで、かなり迷いにくくなります。

🧭 Inspector結果別の次アクション

Inspectorの結果 次に見ること
toolsが出る その設定をmcp.jsonに戻す
command not found commandのパスを確認する
ENOENT npx/nodeの場所を確認する
JSON系エラー 余計な標準出力やラッパーを疑う
認証エラー APIキー、OAuth、権限を確認する

MCP Inspectorは、最初は少し難しく見えるかもしれません。ただ、Cursorの画面だけで何度も再起動するより、原因の見え方はかなりはっきりします。

特に「0 tools enabled」で長く止まっている場合は、Cursorで動かす前にInspectorで1回だけ単体確認する。これだけでも、作業の迷子感はかなり減ります。

Cursor本体の再起動で設定の読み込み直しが必要になることがある

【AI】【業務効率化】【職場】Cursor本体の再起動で設定の読み込み直しが必要になることがある

mcp.jsonを直したあと、Cursorの画面がすぐ更新されないことがあります。調べた情報の中でも、設定を保存したあとにCursorを完全終了して再起動する流れが紹介されていました。

ここでいう再起動は、ウィンドウを閉じるだけでは足りない場合があります。バックグラウンドにCursorプロセスが残っていると、古い設定のまま動いている可能性もあります。

特にWindowsでは、タスクバーやプロセスが残っていないか確認した方がよい場面もあります。再起動後にMCP設定画面を開き、サーバーがどう表示されるかを見ます。

🔄 再起動前後で見ること

タイミング 確認内容
再起動前 mcp.jsonを保存したか
再起動時 Cursorを完全終了したか
再起動後 MCPサーバーが表示されるか
表示後 tools enabledの件数が変わったか
変わらない時 ログやInspectorへ進む

Cursor v1.0以降では、MCP設定まわりが便利になったという記事もありました。DeepLinkやOAuth、ツール単位の有効・無効設定などが紹介されています。ただ、便利になったぶん、設定画面上でどの機能が有効なのかも見ておきたいところです。

参考URL: https://qiita.com/waigoma/items/8c87024c464dfb11af26

「0 tools enabled」と出たままでも、実はサーバー設定は読み込まれていて、ツール単位で無効化されている可能性もあります。Cursor SettingsのMCP Toolsで、サーバー名の下にあるツール一覧を展開して確認します。

🧩 Cursor側で確認したいUI項目

項目 見る理由
MCPサーバーの状態 起動済みか、認証待ちか
tools enabled 有効ツール数があるか
ツール一覧 個別に無効化されていないか
Needs login OAuthなどの認証が必要か
エラー表示 設定や起動失敗のヒントになる

再起動は単純な作業ですが、MCPの設定確認では意外と大事です。設定を直したのに反映されない時は、まず完全終了と再起動を挟んでから、次の原因を見ていきましょう。

【AI】【業務効率化】【職場】Cursor本体の再起動で設定の読み込み直しが必要になることがある
忘れる前に！【ふるさと納税】今年もお得に！
ふるさと納税のポイント付与は2025年10月に廃止になりました。
Amazon
楽天市場
Yahooショッピング
メルカリ

cursor 0 tools enabledを直すための設定パターンと注意点

【AI】【業務効率化】【職場】Cursor本体の再起動で設定の読み込み直しが必要になることがある
  1. Cursor v1.0以降はMCP Toolsの個別有効化も確認する
  2. Windowsではnpx.cmdやnode.exeのフルパス指定が候補になる
  3. OAuth対応MCPはログイン未完了だとツールが使えないことがある
  4. サーバー側がListToolsに対応していない可能性も見る
  5. Cursor CLIのmcp list-toolsで状態確認できる場合がある
  6. チーム利用ではmcp.jsonを共有する前に個人パスと秘密情報を分ける
  7. 総括：cursor 0 tools enabledのまとめ

Cursor v1.0以降はMCP Toolsの個別有効化も確認する

【AI】【業務効率化】【職場】Cursor v1.0以降はMCP Toolsの個別有効化も確認する

Cursor v1.0のMCPまわりでは、DeepLinkやOAuth対応だけでなく、MCP Toolsをツール単位で有効・無効にできる機能が紹介されています。これにより、ツール数の上限に近い環境でも、必要なものだけを使いやすくなったようです。

ただし、便利な反面、ツールが無効になっていると「入れたのに使えない」と感じる原因にもなります。MCPサーバー自体が表示されているなら、その中のツール一覧まで展開して確認したいところです。

Qiitaの記事では、Cursor Settings > MCP Tools内で「x tools enabled」を展開し、ツールをクリックして有効・無効を切り替えられると紹介されていました。

参考URL: https://qiita.com/waigoma/items/8c87024c464dfb11af26

🧰 MCP Tools画面で見る項目

見る場所 確認内容
Cursor Settings MCP設定があるか
MCP Tools サーバー一覧が出ているか
x tools enabled ツール数が0かどうか
展開後のツール一覧 個別に無効化されていないか
ツール説明 使いたい機能と合っているか

「0 tools enabled」と表示されている場合、単純にツール取得に失敗しているケースの方が多そうですが、UI上の有効化状態も確認しておく価値があります。特に、複数のMCPサーバーを入れている人は見落としやすいです。

Cursorは公式サイトでも、エージェント、CLI、さまざまなツール連携を前面に出しています。MCPはその中でも外部ツールとの接続部分に関わるため、設定画面の見方を知っておくと、今後のトラブル対応もしやすくなります。

📌 0 tools enabledの確認順

順番 確認すること
1 MCPサーバーが登録されているか
2 サーバー状態にエラーがないか
3 tools enabledが0かどうか
4 ツール一覧を展開できるか
5 個別ツールがオフになっていないか
6 ログやInspectorで能力取得を確認する

また、ツールが多いMCPサーバーでは、使わないツールをオフにする運用も考えられます。ただし、最初のセットアップ時は、原因を減らすためにまず標準設定で動作を確認した方が分かりやすいです。

いきなり細かくオン・オフするより、サーバーが正しくtoolsを返すことを確認してから、必要なツールだけに絞る。この順番が扱いやすいです。

Windowsではnpx.cmdやnode.exeのフルパス指定が候補になる

【AI】【業務効率化】【職場】Windowsではnpx.cmdやnode.exeのフルパス指定が候補になる

WindowsでCursorのMCPが「0 tools enabled」になる場合、npxではなくnpx.cmdやnode.exeのフルパス指定を試す価値があります。これは、Cursorがコマンドをどう解決するかによって結果が変わる可能性があるためです。

GitHubのIssueでは、Windows 11環境でFigma Context MCPが「0 tools enabled」になる報告がありました。npxを使った設定で、コマンド自体はcmdで動くのにCursorではツールが表示されない、という内容です。

参考URL: https://github.com/GLips/Figma-Context-MCP/issues/189

このような場合、まずwhere npxで実際のパスを確認します。複数出ることもあるため、どれが使われているのかも見ておきたいところです。

🪟 Windowsでよく見るパス確認

コマンド 目的
where node Node.js本体の場所を見る
where npm npmの場所を見る
where npx npxの場所を見る
node -v Node.jsのバージョンを見る
npm -v npmのバージョンを見る

フルパスを使う場合、mcp.jsonでは次のような考え方になります。

{
  "mcpServers": {
    "example": {
      "command": "C:\\Users\\name\\AppData\\Roaming\\npm\\npx.cmd",
      "args": ["-y", "example-mcp-package"]
    }
  }
}

あるいは、グローバルインストールしたMCPサーバーの.cmdを直接指定する方法もあります。Zennの記事では、npxラッパーを介さず実体コマンドを直接実行する方法が安定策として紹介されていました。

🧩 npx経由と直接指定の違い

方法 メリット 注意点
npx経由 設定が短い Cursorからnpxが見えないことがある
npx.cmdフルパス Windowsで解決しやすい場合がある ユーザー名入りパスになりやすい
グローバルコマンド直接 起動が安定しやすい 事前インストールが必要
node.exe + server.js 実体を直接動かせる パスが長く、更新に弱い
bunx 一部報告では回避策になった 標準解とは限らない

ここで注意したいのは、Windowsのパスに日本語やスペースが含まれる場合です。JSONの文字列として正しく書かれているか、余計な引用符が混ざっていないかを確認してください。

また、チームで共有するmcp.jsonに個人のフルパスを入れると、他の人の環境では動かないことがあります。共有用と個人用を分けるか、READMEに「各自でパスを置き換える」と明記した方が安全です。

Windowsでは「cmdで動く」だけでは足りず、Cursorから同じように動くかがポイントになります。MCP Inspectorでフルパス指定を試し、成功した設定をCursorに戻す流れが使いやすいです。

OAuth対応MCPはログイン未完了だとツールが使えないことがある

【AI】【業務効率化】【職場】OAuth対応MCPはログイン未完了だとツールが使えないことがある

Cursor v1.0以降の情報では、OAuth対応のMCPサーバーを使いやすくする流れが紹介されています。OAuthとは、ざっくり言うと、APIトークンを手で貼り付ける代わりに、ブラウザでログインして権限を与える仕組みです。

Qiitaの記事では、DeepLinkからMCPを追加し、OAuth対応サーバーでは「Needs login」と表示され、ログイン後に使えるようになる流れが紹介されていました。

この場合、「0 tools enabled」や「使えない」と見えても、実は認証が終わっていないだけかもしれません。Notionのような外部サービス連携では、権限付与が必要になることがあります。

🔐 OAuth系MCPで見ること

表示 意味として考えたいこと
Needs login ログインが必要
requires_authentication 認証待ち
ready 認証・起動が済んでいる可能性
0 tools 認証前でツールが出ていない可能性もある
権限画面が出る 許可範囲を確認して進める

OAuth対応MCPの場合は、単にmcp.jsonを書くだけでは終わらないことがあります。Cursorの画面からログインに進み、ブラウザで権限を与え、Cursorに戻る流れを最後まで完了させます。

ただし、認証が必要なMCPサーバーでも、すべてがOAuth対応とは限りません。APIキーをenvに入れるタイプもあります。その場合は、環境変数名やキーの入れ方が正しいかを見る必要があります。

🧾 認証方式の違い

方式 作業内容 注意点
OAuth ブラウザでログインして許可 Needs loginを見落とさない
APIキー envにキーを設定 キー名、引用符、改行に注意
ローカル認証 サービス側の設定ファイルを参照 パスや権限に注意
認証不要 そのまま起動 commandやargsが主な確認点
チーム共有 各自で認証 秘密情報をmcp.jsonに直書きしない

MCPは便利ですが、外部サービスに接続する以上、権限の範囲は必ず確認したいところです。特に仕事用アカウントを使う場合は、どのデータにアクセスできる設定なのかを見てから進めてください。

「0 tools enabled」と認証待ちは見た目だけでは区別しにくいことがあります。設定画面にNeeds loginやrequires_authenticationに近い表示がないか確認しましょう。

サーバー側がListToolsに対応していない可能性も見る

【AI】【業務効率化】【職場】サーバー側がListToolsに対応していない可能性も見る

MCPサーバーによっては、Cursorが期待するツール一覧を返せない可能性もあります。フォーラムでは、Cursorが特定のメソッド、たとえばListToolsのようなものを期待しているのではないか、という趣旨の投稿もありました。

この点は、提供された情報だけではすべてのMCPサーバーについて確認できません。ですが、考え方としては大事です。Cursor側の設定が合っていても、サーバー側がCursorで使える形のtoolsを提供していなければ、ツールとしては表示されない可能性があります。

特に、MCP対応をうたっていても、提供している機能がresources中心、prompts中心、または実験的な実装の場合、Cursorの画面で期待通りに見えないことがあり得ます。

🧩 サーバー側で見るポイント

見る内容 理由
READMEのCursor対応 Cursorでの設定例があるか
transport stdioかSSEか
toolsの有無 Cursorで呼べる機能があるか
必要なenv APIキーやTRANSPORT指定があるか
Issueの報告 同じエラーが出ていないか

Nxのブログでは、Nx ConsoleがCursor向けにMCPを設定し、Nx関連のツールを提供する流れが紹介されていました。そこでは、利用可能なToolsとしてnx_workspaceやnx_project_detailsなどの例が挙げられています。

参考URL: https://nx.dev/blog/nx-made-cursor-smarter

このように、Cursorで使えるMCPは、サーバーがどんなToolsを提供しているかが重要です。もしREADMEにツール一覧が書かれているなら、そこに何があるか確認してください。

🧭 READMEで確認したい表現

表現 見方
Available Tools Cursorに出る可能性があるツール一覧
stdio command型MCP設定で使う可能性
SSE ローカルサーバー型の接続かもしれない
Cursor Cursor用設定例があるか
Claude Desktop Cursorとは設定が違う場合がある

MCPサーバーが正常に起動しても、toolsを1つも返さないなら、Cursorでは「0 tools」と見えるかもしれません。これは設定ミスではなく、サーバーの仕様や対応状況の問題かもしれないため、IssueやREADMEを見て判断します。

「有名なMCPだから必ずCursorで使える」とは限りません。Cursor対応の設定例があるか、他の人が同じバージョンで動かしているかまで見ると、余計な深追いを減らせます。

Cursor CLIのmcp list-toolsで状態確認できる場合がある

【AI】【業務効率化】【職場】Cursor CLIのmcp list-toolsで状態確認できる場合がある

Cursor CLIを使える環境なら、MCPサーバーの状態をCLIから確認できる場合があります。DevelopersIOの記事では、cursor agent mcp listやcursor agent mcp list-toolsの例が紹介されていました。

Cursor CLIは、ターミナルからCursorのエージェント機能やMCP統合を扱うための選択肢として紹介されています。IDE側で見えにくい時に、CLIで状態を確認できるなら便利です。

参考URL: https://dev.classmethod.jp/articles/cursor-cli-terminal-ai-agent-guide/

たとえば、記事内では次のような用途が紹介されていました。

cursor agent mcp list
cursor agent mcp list-tools file-system

これにより、MCPサーバーがreadyなのか、認証が必要なのか、どんなツールを持っているのかを確認できるようです。ただし、利用できるコマンドや表示はCursor CLIのバージョンによって変わる可能性があります。

💻 Cursor CLIで見たいこと

コマンド例 確認できること
cursor --version Cursor CLIのバージョン
cursor --status 診断情報
cursor agent mcp list MCPサーバーの状態
cursor agent mcp list-tools 名前 特定サーバーのツール一覧
cursor agent --list-models 利用可能モデル

CLIが使える場合、IDEのUIよりも結果をコピーしやすいメリットがあります。チーム内で「自分の環境だけ動かない」と相談する時にも、状態を共有しやすくなります。

ただし、Cursor CLIそのものの認証が必要な場合もあります。記事ではcursor agent loginの流れも紹介されていました。ログインしていない状態では、期待する情報が取れない可能性があります。

📌 CLI確認が向いているケース

ケース 理由
IDEの表示が分かりにくい 状態をテキストで見られる
チームに相談したい 出力を共有しやすい
MCPが複数ある 一覧で整理しやすい
認証状態を見たい ready/requires_authenticationを確認しやすい
自動化したい スクリプト向きの確認ができる

Cursor CLIは、普段Cursor IDEを使っている人ほど相性がよさそうです。MCP設定もIDE側と共有できると紹介されているため、トラブル確認の補助として覚えておくと役立ちます。

ただ、この記事の主目的は「0 tools enabled」の解決なので、CLIは必須ではありません。まずmcp.json、PATH、Inspectorを見て、それでも不明な時にCLI確認を使うくらいで十分です。

チーム利用ではmcp.jsonを共有する前に個人パスと秘密情報を分ける

【AI】【業務効率化】【職場】チーム利用ではmcp.jsonを共有する前に個人パスと秘密情報を分ける

MCP設定がうまく動いたら、次に考えたいのがチーム共有です。CursorのMCP設定は便利ですが、mcp.jsonには個人PCのパスやAPIキーが入りやすいため、そのまま共有すると問題になることがあります。

Nxのブログでは、.cursor/mcp.jsonをチームで共有するか、ローカル設定として扱うかに触れていました。共有すれば設定をそろえやすい一方、個人環境の差分は注意が必要です。

参考URL: https://nx.dev/blog/nx-made-cursor-smarter

特にフルパス指定を使って「0 tools enabled」を解決した場合、その設定は自分のPCでは動いても、他の人のPCでは動かない可能性があります。ユーザー名、Node.jsの場所、OS、パッケージ管理ツールが違うからです。

🔐 共有前に分けたいもの

種類 共有してよいか
MCPサーバー名 共有しやすい
パッケージ名 共有しやすい
個人PCのフルパス そのまま共有しにくい
APIキー 共有しない方がよい
OAuth認証情報 各自でログイン
ローカル作業ディレクトリ 環境差分に注意

チーム用には、なるべく汎用的な設定例をREADMEに置き、個人ごとのフルパスは各自で設定する形が扱いやすいです。どうしてもフルパスが必要な場合は、「この部分は自分の環境に置き換える」と明記します。

🧾 共有しやすい書き方の考え方

方針 内容
READMEに設定例を書く 直接秘密情報を入れない
env名だけ書く 値は各自で設定
OS別に例を分ける WindowsとMacで混乱しにくい
動作確認コマンドを添える Inspectorやwhere/whichを案内
失敗例も残す 0 tools enabled時の対応が早くなる

また、GitHubにmcp.jsonを含める場合は、秘密情報が入っていないか必ず確認してください。APIキーやトークンが入ったままコミットするのは避けるべきです。

CursorのMCPは、個人利用なら多少雑でも動けばよい場面があります。ただ、仕事で複数人が使うなら、動く設定と共有してよい設定を分けることが大事です。

「0 tools enabled」を直した後は、そこで終わりにせず、再発しにくい形にしておくと次が楽になります。特に新人メンバーや別PCで同じ環境を作る時に効いてきます。

総括：cursor 0 tools enabledのまとめ

【AI】【業務効率化】【職場】総括：cursor 0 tools enabledのまとめ

最後に記事のポイントをまとめます。

  1. cursor 0 tools enabledは、MCPサーバー登録後にツール一覧を取得できていない状態として見るのが入口である。
  2. 最初に確認するのはmcp.jsonのJSON構文、command、args、envである。
  3. commandにnpx -y パッケージ名をまとめて書くより、commandとargsを分ける形が基本である。
  4. spawn npx ENOENTが出る場合、Cursorからnpxが見えていない可能性がある。
  5. Windowsではnpx.cmdやnode.exeのフルパス指定が候補である。
  6. NVM、Volta、asdfなどを使う環境では、Cursor側にNode.jsのPATHが通らないことがある。
  7. MCP Inspectorで単体起動し、toolsが表示されるか確認すると原因を絞りやすい。
  8. Inspectorで成功したcommand、args、envをmcp.jsonへ戻す流れが実用的である。
  9. Cursor v1.0以降ではMCP Toolsの個別有効化も確認対象である。
  10. OAuth対応MCPではNeeds loginやrequires_authenticationの表示を確認する必要がある。
  11. サーバー側がCursor向けのToolsを提供していない場合、0 toolsに見える可能性がある。
  12. Cursor CLIが使える環境では、mcp listやlist-toolsで状態確認できる場合がある。
  13. チーム共有時は個人PCのフルパスやAPIキーをmcp.jsonに入れたまま共有しないことが重要である。
  14. 直らない時は、画面表示だけで判断せず、ログ、Inspector、CLIの順で証拠を増やすのが現実的である。

関連記事

✓anthropic businessは何がすごい？中小企業まで狙うClaude法人戦略の全貌
✓上司が厳しいのは期待されてる証拠？期待される人とされない人の特徴
✓Manusのネットワークエラーで詰んだ人へ｜原因の切り分けと今すぐ試す直し方
✓司法書士補助者の年収はぶっちゃけいくら？リアルな給料と上げ方を徹底解説
✓manusウェブサイトの使用状況と請求が全部わかる！知らないと損するコスト管理の完全ガイド
✓本間昭光の年収がエグい？ヒット曲印税と代表作から現実的に深掘り
✓cursor 費用で損しない！無料・有料プラン・従量課金のリアルな選び方
✓セントラルエンジニアリングの年収は実際いくら？給与・賞与・評判を全部まとめてみた
✓保育料金は年収でこんなに変わる！世帯別・自治体別の実態を徹底調査
✓n8nの日付で9時間ズレる沼から抜ける実践ガイド
記事作成にあたり参考にさせて頂いたサイト
【AI】【業務効率化】【職場】総括：cursor 0 tools enabledのまとめ

この記事を書いた人: ミナト

働き方情報の案内役

仕事選びや副業を始める前に、見ておきたい条件や注意点をまとめています。

運営者情報を見る

各サイト運営者様へ
有益な情報をご公開いただき、誠にありがとうございます。
感謝の意を込め、このリンクはSEO効果がある形で設置させていただいております。
※リンクには nofollow 属性を付与しておりませんので、一定のSEO効果が見込まれるなど、サイト運営者様にとってもメリットとなれば幸いです。
当サイトは、インターネット上に散在する有益な情報を収集し、要約・編集してわかりやすくお届けすることを目的としたメディアです。
引用や参照の方法に不備、あるいはご不快に感じられる点がございましたら、お問い合わせフォームよりご連絡ください。
今後とも、どうぞよろしくお願いいたします。

AI 業務効率化 職場
ABOUT ME
カシワギ
『エグゼクティブワーク』編集長のカシワギです。 普段はITベンチャーで執行役員の40代男です。 元コンサルタントですが、今はテクノロジー企業で日々奮闘中。 仕事では厳しい顔をしていますが、家では小学生の子供2人のやんちゃなパパ。 休日はゴルフに行ったり、妻とワインを楽しんだり。
BLOG：https://min-biz.net/
当サイトについて
当サイトでは、インターネット上に散らばるさまざまな情報を収集し、AIを活用しながら要約・編集を行い、独自の切り口で見解を交えながらわかりやすい形でお届けしています。 情報の整理・編集にあたっては、読者やオリジナル記事の筆者へご迷惑をおかけしないよう、細心の注意を払って運営しておりますが、万が一、掲載内容に問題がある場合や修正・削除のご要望がございましたら、どうぞお気軽にお問い合わせください。 迅速に対応をさせていただきます。 その際には、該当記事の URLやタイトルをあわせてお知らせいただけますと、より速やかに対応 することができますのでそちらもご協力いただけますと大変幸いでございます。 今後とも当サイトをよろしくお願いいたします。