CursorのMCP設定｜設定画面の場所とmcp.jsonの書き方

MCPを試そうとしてCursorの設定を開いたのに、それらしい項目が見当たらない。検索して出てきた記事のとおりに探しても、画面の名前が一致しない。最初のつまずきは、たいていここです。

理由の一つは、MCPの管理場所がちょうど移動の途中にあることです。公式ドキュメントは新しい置き場を前提に書かれている一方、手元のアプリはまだ以前の場所に項目が残っている、という状態が起こります。本記事では執筆時点（2026-08-01）の公式ドキュメントと、同日に実機で確認した画面の両方をもとに、設定の入口、mcp.json の書き方、追加したあとの確認までをまとめます。MCPそのものの用語や仕組みは MCPガイド 側が正本なので、本記事は入口の要約にとどめます。シリーズ入口は Cursor 開発ガイド です。

今日の結論

• アプリ版の入口は Cursor Settings の Tools & MCPs。公式ドキュメントが案内する Customize へ移動する途中で、画面上部にその告知バナーが出る
• 実体は .cursor/mcp.json と ~/.cursor/mcp.json の2ファイル。両方が読まれ、同名サーバーはプロジェクト側が優先される
• 未設定の環境では、この2ファイルはそもそも存在しない。空のテンプレートは用意されないので、自分で作る
• ローカル実行は command と args、リモートは url と headers。トークンは ${env:NAME} で外に出す
• MCPツールの実行は既定で承認が必要。承認の強さはMCP固有ではなく、ターミナルコマンドと共通の設定で決まる

MCPの設定はCursorのどこにあるか

ここは説明が割れやすい箇所なので、実機で確認した内容から書きます。筆者の環境はWindows版のCursor 3.14.7、Proプラン、確認日は2026-08-01です。

デスクトップアプリでMCPを追加する入口は Cursor Settings の左メニューにある Tools & MCPs（画像①）でした。開くと Installed MCP Servers の枠があり、まだ何も追加していなければ No MCP Tools と表示され、Add Custom MCP ボタン（④）が置かれています。この枠の説明文には「カスタムのMCPツールをここで追加するか、プロジェクト固有のツールは <project-root>/.cursor/mcp.json で設定する」という趣旨の案内が書かれており（③）、後述する設定ファイルの置き場が画面側からも確認できます。同じ画面には Wait for MCP Authentication というトグルもあり、オフにすると認証プロンプトを30秒でスキップする、と説明されています。

一方で公式ドキュメントは、MCPの管理場所を Customize ページとして案内しています。矛盾しているように見えますが、これは移行の途中だからです。実機の Tools & MCPs 画面の上部には「Tools & MCPs are moving to Customize」という告知と Open Customize ボタン（②）が表示されます。隣の Plugins 画面にも同じ形式の告知が出ていました。つまり、ドキュメントは移動後、アプリは移動前を映している時期にあたります。

検索して出てくる解説が自分の画面と合わないときは、どちらかが間違っているというより、この移行のどの時点を書いたものかを疑うと早く片付きます。バージョンによっては Customize 側が既定になっている可能性もあるため、迷ったらバナーの Open Customize から移動先を確認してください。

web版のダッシュボードを探しても見つからないのは、そもそも役割が違うためです。あちらの Plugins や Integrations はチーム共有やCloud Agent向けで、手元のエディタで使うMCPはアプリ側で設定します。

承認まわりだけは、MCPの画面ではなく別の場所にあります。

mcp.jsonの書き方とファイルの置き場所

UIから追加した場合も、手で書く場合も、設定の実体は次の2ファイルに落ちます。

<project>/.cursor/mcp.json   # プロジェクト固有。コミットしてチームで共有できる
~/.cursor/mcp.json           # グローバル。すべてのプロジェクトに効く

両方が読み込まれてマージされ、同じ名前のサーバーが両方にあるときはプロジェクト側が優先されます。仕事用リポジトリだけで使いたい接続はプロジェクト側、個人用の常用サーバーはグローバル側、と分けておくと衝突を考えずに済みます。

ここで一点、実際に確認しておきたいことがあります。筆者のWindows環境（Cursor 3.14.7）でMCPを未設定のまま調べたところ、.cursor/mcp.json も ~/.cursor/mcp.json も存在しませんでした。~/.cursor の下に agents や plugins などのフォルダは並んでいるのに、mcp.jsonだけ無い状態です。空のテンプレートが先に置かれるわけではないため、「ファイルが見つからない」のは故障ではなく初期状態。自分で新規作成するところから始めます。

ルートのキーは mcpServers です。ローカルでコマンドとして起動するサーバーは、次の形になります。

{
  "mcpServers": {
    "server-name": {
      "command": "npx",
      "args": ["-y", "mcp-server"],
      "env": {
        "API_KEY": "value"
      }
    }
  }
}

リモートのエンドポイントへつなぐ場合は、command の代わりに url を書きます。

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

ローカル実行で使えるフィールドは次のとおりです。

type には注意が必要です。公式のフィールド表では必須とされている一方、同じページのJSON例では省略されています。記載が一致していないため、どちらが推奨かはここでは断定しません。うまく動かないときに試す切り分けの一つ、と考えておくのが無難です。

command、args、env、url、headers では変数の展開が効きます。${env:NAME} で環境変数、${workspaceFolder} でプロジェクトルート、${userHome} でホームフォルダを参照できます。APIキーを直接書かずに済むので、プロジェクト側のmcp.jsonをコミットする予定があるなら最初から ${env:} で書いておくと安全です。なお、保存後はCursorを再起動するよう公式ヘルプが案内しています。自動で読み直されるかどうかについての記載は見つかりませんでした。

追加したあとの確認と、承認の考え方

サーバーを追加したら、実際にツールが見えているかを確認します。チャットパネル上部のツール一覧に、そのサーバーが提供するツール名が並ぶはずです。ツール名をクリックすれば個別にオン・オフでき、設定画面側のトグルを切ればサーバーごとロードされなくなります。ツールが多すぎて選択がぶれるときは、使わないサーバーを一時的に無効化するのが手っ取り早い対処です。

Agentは、依頼内容との関連性に応じてこれらのツールを自分で選んで使います。名前を指定して頼むこともできますし、やりたいことだけ書いても構いません。Plan Modeでも呼び出される点は覚えておいてください。モードごとの使い分けは Cursorモード使い分けガイド で扱っています。

実行前には、既定で承認を求められます。ツール名の横の矢印を開くと、どんな引数で呼ばれようとしているかを確認できます。

ここが誤解されやすいところですが、承認の強さはMCP専用の設定ではありません。MCPツールの呼び出しは、ターミナルコマンドと同じRun Modesに従います。

公式は「Auto-reviewはセキュリティ境界ではない」と明記しています。分類器が誤ることを前提にした設計なので、権限の広いサーバーを常時許可する運用は避けたほうが安全です。承認を毎回押すのが面倒なら、~/.cursor/permissions.json の mcpAllowlist に github:* のような サーバー名:ツール名 形式で書いて、範囲を絞って事前許可する方法があります。Agentにどこまで任せるかの線引きは Cursor Agentのスコープの決め方 も参考になります。

つまずいたときに見る場所とチェックリスト

うまく動かないときは、まずログです。Outputパネルを開き（Windowsは Ctrl+Shift+U、Macは Cmd+Shift+U）、ドロップダウンから MCP Logs を選ぶと、サーバーの初期化やツール呼び出し、エラーが流れます。

よくある詰まり方は3つに分かれます。

1. サーバーがそもそも出てこない: Installed MCP Servers のトグルが無効になっていないか、mcp.jsonを保存したあとにCursorを再起動したかを確認する
2. 環境変数を読んでくれない: シェルのプロファイルで設定した変数がCursorから見えているかを確認し、プロファイルを更新したなら再起動する
3. npm経由のサーバーが古い挙動をする: 設定画面の一覧から削除し、npm cache clean --force を実行してから追加し直す

サーバーがクラッシュしたりタイムアウトしたりした場合は、チャットにエラーが表示され、その呼び出しだけが失敗扱いになります。Cursor側が障害を切り離すため、ほかのMCPサーバーは巻き添えになりません。

設定の前後で、次を確認してください。

まとめ・次に読む

CursorのMCP設定でつまずく原因の多くは、機能の難しさではなく画面の場所です。Cursor Settings から Tools & MCPs を開き、実体である .cursor/mcp.json を自分で作り、ツール一覧に出たことを確認する。この3手が通れば、あとは接続先ごとの話になります。画面が記事と違って見えるときは、Customizeへの移行が進んだ後の版を触っている可能性を先に疑ってください。

• Hub: Cursor 開発ガイド｜初心者向けの始め方と読む順番
• MCPの用語と仕組み: Model Context Protocol（MCP）ガイド（Cursor向けの詳細版は準備中）
• ターミナル側の入口: Cursor CLIのインストールと基本操作
• 任せる範囲の決め方: Cursor Agentは記事一括公開と基盤横断変更に絞って使う

公式ドキュメント: Model Context Protocol / MCP integrations / Run Modes

本記事の画面名、設定ファイルのパス、JSONのキー、承認まわりの挙動は2026-08-01時点、Windows版Cursor 3.14.7で確認した内容です。MCPの管理場所はCustomizeへ移行している最中のため、バージョンや配信時期によって画面名が異なる可能性があります。MCPサーバーへ渡すトークンや権限の扱いは、接続先ごとの公式ドキュメントと利用規約を優先してください。本記事はセキュリティや動作を保証するものではありません。