CursorにおけるMCPサーバー：セットアップ、構成、およびセキュリティ（2026年版ガイド）

デフォルトでは、CursorのAIエージェントはあなたのコードベースのことしか知りません。それだけです。Postgresのテーブルを見ることも、GitHubでどのような課題が山積しているかを知ることも、Figmaからデザイン・トークンを取得することもできません。そのギャップを埋めるのがMCPサーバーです。これらは、Model Context Protocolという標準化されたプロトコルを通じて外部ツールをCursorに接続する軽量プログラムであり、エージェントはエディターから直接データベースを照会したり、課題を登録したり、APIデータを取得したりできるようになります。

簡単な経緯を説明します。Anthropicは2024年11月にMCPをオープンソース化しました。OpenAIは2025年5月までにこれを採用し、Google DeepMindは4月にGeminiのサポートを導入しました。その後、2025年12月には、AnthropicはBlockとOpenAIが共同設立したAgentic AI Foundation（Linux Foundation傘下）にそのすべてを寄贈しました。この動きは重要でした。MCPはAnthropicのプロジェクトから、真にベンダーニュートラルな標準へと変わったのです。

Cursorは、IDEの中でも主要なMCPクライアントの一つとして台頭してきました。しかし、適切にセットアップし、設定とセキュリティの両面から何が問題になりうるかを理解するには、Redditで見つけたJSONスニペットを貼り付けるだけでは不十分です。

Cursor内でMCPが実際にどのように機能するか

これが、 MCPとAPIの比較 がIDEエージェントにとって重要である理由です。APIは明示的な統合ロジックを必要としますが、 MCP は、Cursorが接続されたサーバーから利用可能なツールを動的にロードすることを可能にします。

MCPは3つの要素を定義しています。 ホスト はアプリケーション、つまりCursorです。 クライアント は、ホスト内で個々のサーバー接続を処理するコネクタです。 サーバー は、もう一方の端にある軽量プログラムで、ツールを JSON-RPC 2.0を介して公開します。

実際にどう使うかというと、Cursorを開きます。そのエージェントが、有効になっているMCPサーバーをスキャンし、公開されているツールを読み込み、現在取り組んでいるタスクの一部としてどのツールを呼び出すべきかを判断します。 Cursor 設定 > ツール & MCP にアクセスすると、読み込まれたすべてのサーバーがステータスインジケーター付きで表示されます。そのパネルから、個々のツールのオン/オフを切り替えることができます。

サーバーは3種類のものを公開できます。

• ツール は主要なもので、create_issueやrun_queryのような実行可能な関数です。Cursorは、MCP統合の初期からツールをサポートしてきました。
• リソース はコンテキストデータです。ファイルの内容、データベーススキーマ、設定の詳細などが含まれます。リソースのサポートはCursor v1.6（2025年9月）で追加されました。
• プロンプト は、サーバーが再利用可能なテンプレートや事前定義されたワークフローをクライアントに提供できるようにします。

MCPアーキテクチャとサーバープリミティブの詳細については、以下のガイドをご覧ください。 MCPとその仕組み。

トランスポートの種類: CursorがMCPサーバーと通信する方法

ここには3つの選択肢があります。どれを選ぶかは、ローカルサーバーかリモートかというシンプルな問いによって決まります。

私たちのおすすめは、ローカルでの実験にはstdio、それ以外すべてにはストリーマブルHTTPです。

MCPサーバーのセットアップ

簡単な方法: ワンクリックディープリンク

現在、多くのMCPサーバーのドキュメントページに「Add to Cursor」ボタンが設置されています。これをクリックすると、Cursorがサーバー名、トランスポート、URLがすでに記入されたダイアログを開きます。「インストール」をクリックするだけで、プロセスは完了です。

認証が必要なサーバーは、ブラウザベースのOAuthフローをトリガーし、Cursorがその結果として得られる認証情報を保存します。これらのディープリンクを追加したいサーバー開発者の方は、 Cursor MCP ドキュメント その方法を説明します。

手動セットアップ: ローカルサーバー向けstdio

開く Cursor 設定 > ツールとMCPをクリックし、 新しいMCPサーバー （これによりmcp.jsonが開きます）、または手動でファイルを作成します。プロジェクト固有の設定には、プロジェクト内の .cursor/mcp.json に、グローバル設定には ~/.cursor/mcp.json に配置してください。

Docker経由で実行されるGitHub MCPサーバーは次のようになります。

{
  "mcpServers": {
    "github": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "GITHUB_PERSONAL_ACCESS_TOKEN",
        "ghcr.io/github/github-mcp-server"
      ],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<YOUR_TOKEN>"
      }
    }
  }
}

フィールドの概要:

• 「command」 — Cursorがサーバーを起動するために実行するコマンドです。npx、docker、python、nodeなど、サーバーが想定するものを指定します。
• 「args」 — そのコマンドに渡される引数です。
• 「env」 — 実行時に渡される環境変数です。APIキーはここに配置してください。シェルプロファイルや、誤ってコミットされる可能性のある.envファイルではなく、ここにです。

手動セットアップ: リモートサーバー向けストリーミングHTTP

はるかにシンプルです。URLとオプションのヘッダーのみです。

{
  "mcpServers": {
    "remote-api": {
      "url": "https://mcp.example.com/mcp",
      "headers": {
        "Authorization": "Bearer <YOUR_API_KEY>"
      }
    }
  }
}

コマンドも引数もありません。CursorはHTTPエンドポイントに直接アクセスします。

プロジェクトレベル設定 対 グローバル設定

プロジェクト設定（リポジトリルートの .cursor/mcp.json）は、そのプロジェクトのみに影響します。グローバル設定（~/.cursor/mcp.json）は、どこにでも適用されます。両方のファイルで同じサーバーが定義されている場合、プロジェクトレベルが優先されます。

問題が発生した場合: CursorでのMCPのトラブルシューティング

40ツール制限

Cursorには、すべてのMCPサーバーを合わせても約40個のアクティブツールという上限があります。これを超えると、2つのことが起こります。警告が表示され、エージェントは一部のツールへのアクセスをサイレントに失います。それらを認識できなくなるのです。

なぜこの制限があるのでしょうか？各ツール定義はコンテキストトークンを消費します。そして、40以上のツール記述をプロンプトに詰め込むと、LLMが適切なツールを選択する能力が著しく低下します。

対処法： 設定で各サーバーを開き、積極的に使用していないツールをオフにしてください。一般的なルールとして、5〜10個の明確に定義されたツールを公開するサーバーの方が、30ものことをこなそうとする1つの巨大なサーバーよりも、より役立ちます。

「ツールが見つかりません」またはサイレントな失敗

あなたの MCPサーバー が起動しませんでした。Cursorはエラーも警告も何も表示しません。ただツールが表示されないことに気づくだけです。

十中八九、問題は以下のいずれかです。Node.jsまたはPythonがインストールされていない（またはPATHが通っていない）。設定内のパッケージバージョンが存在しない。または参照している環境変数が空であるか、完全に欠落している。

最速のデバッグ方法： mcp.jsonからコマンドをそのままコピーし、ターミナルで実行してください。例：npx -y @modelcontextprotocol/server-postgres postgresql://localhost/mydb。Cursorが隠していたエラーが画面に直接表示されます。

SSHとリモート環境

stdioトランスポートとリモート環境は相性が良くありません。サブプロセスはリモート側で起動しますが、Cursorはそれをローカルで期待します。その結果、追跡が非常に困難な断続的な接続障害が発生します。

Streamable HTTPを使用してください。 MCPサーバーをホストされたエンドポイントとしてデプロイし、CursorからそのURLを指定してください。これにより、デバッグの時間を大幅に節約できます。

午後を無駄にする小さな設定ミス

私たちは常に同じ3つの問題に遭遇しています。

• サーバー名 + ツール名が60文字を超えている。 Cursorはエラーをスローしますが、そのメッセージはあまり役に立ちません。
• 「mcpServers」ルートキーが欠落している。 エラーも警告もなし。Cursorはファイル全体を無視するだけです。完璧にフォーマットされたJSONを眺めながら、なぜ何も読み込まれないのか不思議に思うでしょう。
• npxで-yを付け忘れる。 プロセスは永遠にハングアップします。なぜか？npxがパッケージのインストール確認を待っているのに、"y"と入力するための対話型ターミナルがないからです。

Key Metrics for Evaluating Gateway

Criteria	What should you evaluate ?	Priority	TrueFoundry
Latency	Adds <10ms p95 overhead for time-to-first-token?	Must Have	✅ Supported
Data Residency	Keeps logs within your region (EU/US)?	Depends on use case	✅ Supported
Latency-Based Routing	Automatically reroutes based on real-time latency/failures?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported

MCP Gateway Evaluation Checklist

A practical guide used by platform & infra teams

MCPセキュリティ：見過ごせない重要な部分

MCPサーバーはあなたの認証情報でコードを実行します。このことをよく考えてみてください。データベースアクセス、GitHubトークン、APIキーなど、サーバーに与えるあらゆる権限を、サーバーは使用します。事実上、すべてのMCPサーバーは完全に信頼された統合です。サーバーが侵害されたり悪意のあるものであった場合、あなたが与えたすべての情報がそこにあることになります。

2025年はCursorにとって厳しい年でした。 MCPセキュリティ研究者たちは複数の重大なCVEを公開し、それぞれが根本的に異なる攻撃対象領域を露呈しました。

• CVE-2025-54136、「MCPoison」と名付けられたもの - Check Point Researchは、Cursorが設定ファイル内のMCPサーバーのキー名に信頼を固定しており、実際に実行されるコマンド自体には固定していないことを発見しました。具体的な影響：誰かが改ざんされた.cursor/mcp.jsonを共有リポジトリにプッシュし、正当なコマンドを悪意のあるものに置き換えることができました。キー名が変わっていなかったため、Cursorは承認を求めることなくそれを実行し続けました。Cursor 1.3（2025年7月）で修正済み。
• CVE-2025-54135、「CurXecute」と名付けられたもの - AIM Securityは驚くべきことをやってのけました。彼らは、Slackメッセージ内の汚染されたコンテンツが、Cursorのエージェントによって要約されると、MCP設定ファイルを書き換え、不正なサーバーを自動起動できることを示しました。Slackメッセージ。それが攻撃ベクトルです。Cursor 1.3.9で修正済み。
• CVE-2025-59944 - Lakeraは、macOSとWindowsを標的とした大文字小文字の区別を利用したトリックを発見しました。攻撃者は.cUrSoR/mcp.jsonに書き込むことで.cursor/mcp.jsonを上書きできました。ファイルシステムがこれらを同じパスとして扱ったためです。Cursor 1.7で修正済み。
• CVE-2025-64106 - Cyata Securityは、CursorのMCPインストールダイアログが偽装される可能性があることを発見しました。ユーザーには「Playwright」のような信頼された名前を表示しながら、舞台裏では全く異なる攻撃者制御のコマンドを実行していました。Cursorはバージョン2.0で修正をリリースしました。開示からわずか48時間での対応でした。

セキュリティのベストプラクティス

• 自動実行モードを無効にする。 エージェントに、すべてのツール呼び出しの前に明示的な承認を得るように強制します。はい、一つ残らずすべてです。その手間をかける価値はあります。
• 認証情報には常に最小権限を。 検索関連の操作には読み取り専用のGitHubトークンを、スキーマ参照には読み取り専用のデータベースユーザーを使用してください。書き込みアクセス権は、そのユースケースが絶対に必要としない限り、決して付与しないでください。
• パッケージのバージョンを固定する。 `npx -y mcp-server@1.2.3` を使用し、`@latest` は使用しないでください。侵害された`@latest`タグは、現実的なサプライチェーン攻撃のベクトルとなり、その危険性を身をもって知るような事態は避けたいものです。
• サードパーティ製サーバーのソースコードを読む。 未検証のnpmパッケージを本番環境で実行しないのであれば、未検証のMCPサーバーをIDEで実行すべきではありません。リスクプロファイルは同じです。
• Cursorは常に最新バージョンを使用する。 Cursorチームは、これらのCVEをすべて数日以内にパッチ適用しました。これは彼らの功績です。しかし、実際にアップデートしなければ、これらのパッチは意味がありません。
• Gitにおける`.cursor/mcp.json`の変更は、インフラの変更と同様に扱う。 TerraformファイルやGitHub Actionsのワークフローに適用するのと同じ厳格なレビューを行う。

これらのトピックに関する詳細は、エンタープライズ向けのガイドでご覧いただけます。 MCPのセキュリティ および アクセス制御パターン

‍

開発者からエンタープライズへのMCPのスケーリング

一人の開発者にとって、MCPは素晴らしいものです。一度設定すれば、生産性向上を享受し、次に進めます。しかし、20人、あるいは200人のチームにスケールアップするとどうでしょう？そこから問題が始まります。

APIキーは個々のラップトップに散らばってしまいます。組織全体でどのサーバーやツールがアクティブであるかについて、一元的なビューはありません。監査証跡もゼロです。そして、誰かが会社を辞めたり、チームを異動したりすると、無数のマシンに散らばった何十もの個別のCursor設定ファイルで認証情報をローテーションしなければならなくなります。

「 MCPゲートウェイ 」は、エージェントとMCPサーバーの間にレイヤーを設け、上記すべて（一元化された認証、ロールベースのアクセス、可観測性、ポリシー適用）を処理します。

TrueFoundryのMCPゲートウェイ それを正確に実現します。開発者はゲートウェイに対して一度認証するだけで済みます。その後は、ゲートウェイがすべてのダウンストリームのOAuthトークンと認証情報を管理します。管理者は、サーバーごとのアクセス制御と権限を、 RBACを通じて定義します。すべてのツール呼び出し、一つ残らず、完全なリクエストレベルのトレーシングとともにログに記録されます。

特に注目すべき機能が一つあります。 バーチャルMCPサーバーです。 ゲートウェイは、その背後にあるサーバーから、範囲を限定したツール群を公開できます。例えば、GitHubのイシューを読み取れるが、いかなる状況でもリポジトリを削除してはならないエージェントが必要だとします。それをLLMが無視する可能性のあるシステムプロンプトで強制するわけではありません。ゲートウェイがプロトコルレベルで強制します。エージェントの視点からは、「リポジトリ削除」ツールは単に存在しないのです。

LLMルーティングとコスト管理のためにTrueFoundryの AI Gateway をすでに利用している組織は、MCP Gatewayとのネイティブ統合を利用できます。 1つのコントロールプレーンで モデル、ツール、エージェントをカバーします。

Cursorは、一元化されたLLMルーティング、コスト追跡、キー管理のために、TrueFoundryのAI Gatewayに直接接続することもできます。

まとめ

MCPはCursorに、単なるソースファイルだけでなく、実際の外部ツールと連携する機能を提供します。個別のセットアップは数分で完了します。実際のエンジニアリング上の課題は後から現れます。それは、チーム規模でのガバナンス、認証情報管理、アクセス制御、そして可観測性です。

小さく始めましょう。サーバーは1つか2つから。利用可能な場合はディープリンクを使用してください。40ツールの制限を遵守してください。セキュリティパッチに先行するために常に最新の状態を保ってください。そして、チームや組織全体でMCPを展開する場合は、認証情報の拡散問題がセキュリティインシデントに発展して自然に解決される前に、MCP Gatewayの導入を検討してください。

詳しく見る TrueFoundryのMCPゲートウェイ または デモを予約する 実際に動作している様子を見る

‍

よくある質問

CursorにおけるMCPサーバーとは具体的に何ですか？

CursorのAIエージェントを、外部ツールやデータソースに接続する軽量なプログラムで、 Model Context Protocolを介して動作します。これは、エージェントがワークフロー中に発見して呼び出す関数（「ツール」と呼ばれる）を公開します。GitHub、Postgres、Figma、Slackなど、すべてMCPサーバーが利用可能です。

Cursorにどうすれば追加できますか？

3つの方法があります。サーバーのドキュメントページにあるワンクリックのディープリンクボタン（最も簡単）。または、 Cursor設定 > ツールとMCP > 新しいMCPサーバー UI。または、.cursor/mcp.json（プロジェクトスコープ）または ~/.cursor/mcp.json（グローバル）を手動で作成する方法です。

ツールの制限はありますか？

すべてのサーバーで約40個のアクティブなツールです。それを超えると、コンテキストが埋まってしまうため、エージェントは適切なツールを選択するのが苦手になります。使用していないものはオフにしてください。

CursorはMCPリソースと情報収集を処理しますか？

はい。リソースはv1.6（2025年9月）で提供され、スキーマやファイルの内容のようなコンテキストデータが含まれます。情報収集機能は v1.5 （2025年8月）で実装され、サーバーが実行中に構造化されたユーザー入力を要求できるようになりました。

CursorでMCPサーバーを使用するのは安全ですか？

設定によります。MCPサーバーは、提供された権限でコードを実行します。研究者たちは2025年に複数の重大な脆弱性を発見しましたが、すべて迅速にパッチが適用されました。Cursorを最新の状態に保ち、自動実行を無効にし、資格情報を制限し、パッケージのバージョンを固定し、サードパーティのサーバーを追加する前に監査してください。

大規模なチームはMCPサーバーをどのように管理しますか？

MCPゲートウェイを介して。TrueFoundryのゲートウェイは、認証を一元化し、RBACを適用し、すべてのツール呼び出しをログに記録します。管理者は、どのチームがどのサーバーにアクセスできるかを正確に制御できます。詳細については、当社のMCPゲートウェイ比較をご覧ください。