slug: best-mcp-servers-for-cursor-2026 summary: Cursor を本当に拡張する 12 個の MCP サーバーと、その設定方法、実際のユースケース、そしてツール接続だけでは能力持続性の問題が解けない理由をまとめます。 tags: cursor,mcp,mcp-server,developer-tools,ai-agent,productivity
お久しぶりです。Lena です。最近ずっと感じているのは、本当に役に立つエージェントは、賢いというより、つながり方がうまいということです。
もともと、これを書くつもりはありませんでした。でも、Cursor が MCP サーバーあり / なしでどう振る舞うかを数週間見ているうちに、メモを取り始めていたんです。この記事は、そのメモが形になったものです。
Cursor で MCP サーバーが担う役割
標準の状態では、Cursor の AI エージェント はあなたのコードベースしか知りません。それだけです。Postgres のテーブルは見えないし、GitHub の issue が何件あるかも知らないし、ブラウザも開けません。孤立したままでも動ける。でも、孤立したままです。
MCP で Cursor のエージェント能力を拡張する仕組み
MCP、つまり Model Context Protocol は、Anthropic が 2024 年 11 月に公開したオープンスタンダードです。考え方は十分シンプルです。外部サービスごとに AI ツールが個別実装を抱えるのではなく、共通のプロトコルでつなぐ。1 つのサーバーを、対応クライアントならどれでも使える。Cursor の公式 MCP ドキュメント も、これを「Cursor のためのプラグインシステム」と表現していて分かりやすいです。標準化されたインターフェースを通じて、エージェントを外部データソースへ接続できる、ということです。
実際に追加すると何が起きるか。Cursor は MCP サーバーを子プロセスとして起動するか、ローカルの stdio transport で接続します。あるいは HTTP 越しにつなぎます。サーバー側は、自分が提供するツールを Cursor へ通知します。エージェントはそれらを利用可能ツールとして認識し、必要だと判断したものを呼び出します。結果は会話へ戻ってきます。
Cursor は現時点で、接続したすべてのサーバーを合わせて最大 40 ツールまで をサポートしています。これを超えると、エージェントは正しいツールを選ぶのが下手になります。この点は覚えておいたほうがいいです。
本当に役立つ MCP サーバーと、見せかけだけのものの違い
ここは、まだ私も考え続けています。追加した瞬間に効いてくるサーバーもあります。こちらが指示しなくてもエージェントが呼び、応答の質そのものが変わる。一方で、ただそこにあるだけのサーバーもある。ほとんど呼ばれない。あるいは一度だけ呼ばれて、そのまま忘れられる。
私が見てきた限り、実際によく使われるサーバーには、はっきりした狭い役割があります。「何でもできる」ではなく、「エージェント単体では答えられない 1 種類の問いに答える」。ファイル操作、SQL クエリ、Web 検索、GitHub の状態。ツールの目的が具体的なほど、エージェントはそれを安定して使いにいくように見えます。
Cursor に MCP サーバーをインストールする方法
セットアップ手順
セットアップ手順は、2025 年後半に少し変わりました。2026 年初頭の時点では、やり方は 3 つあります。
方法 1 — ワンクリックインストール: いまは多くのサーバーがドキュメントページに "Add to Cursor" ボタンを用意しています。クリックすると、サーバー名と transport があらかじめ入ったダイアログが Cursor 側で開きます。
方法 2 — 設定 UI: Cursor Settings を開きます（Mac は Cmd+,、Windows は Ctrl+,）。Features > MCP へ進み、+ Add New MCP Server をクリックします。名前、transport 種別（ローカルなら stdio、リモートなら streamable HTTP）、そして command または URL を入力します。
方法 3 — 設定ファイルを直接編集: プロジェクト単位ならプロジェクトルートに .cursor/mcp.json、グローバルなら ~/.cursor/mcp.json を作成します。形式は次のとおりです。
{
"mcpServers": {
"server-name": {
"command": "npx",
"args": ["-y", "@package/mcp-server"],
"env": {
"API_KEY": "your-key"
}
}
}
}
私がつまずいた点を 1 つ。"mcpServers" というルートキーが欠けていると、Cursor はファイル全体を黙って無視します。 エラーは出ません。ただ、サーバーが表示されないだけです。あと、npx には必ず -y を付けてください。付けないと、確認待ちのままプロセスが固まります。
2026 年の Cursor 向けベスト MCP サーバー 12 選
ここで挙げるのは、実在していて、メンテナンスされているサーバーだけです。現時点で動くことを確認できないものは入れていません。
- Filesystem —
@modelcontextprotocol/server-filesystem
Cursor の標準スコープ外にあるファイルの読み書き、検索、管理ができます。アクセス可能なディレクトリは自分で定義します。より広いプロジェクト構成をまたいでファイルを触る必要があるときに便利です。これは Anthropic の公式 reference servers の 1 つで、メンテされていて安定しています。
- Brave Search —
@modelcontextprotocol/server-brave-search
Cursor 内でそのまま Web 検索できます。 エージェントは、ドキュメントを調べたり、パッケージがまだ存在するか確認したり、エラーメッセージを検索したりできます。こちらで何かを貼り付ける必要はありません。Brave の独立した検索インデックスを使います。Brave API key が必要ですが、free tier があります。
- PostgreSQL —
@modelcontextprotocol/server-postgres
データベース URL を向ければ、エージェントはスキーマを調べ、SQL を実行し、テーブル構造を平易な言葉で説明できます。私はこれを、知らないコードベースを理解するときに本当に役立つと感じています。「このテーブルには実際に何が入っているのか」を、スキーマ定義を貼り付けずに聞けるからです。
- GitHub (Official) — hosted at
api.githubcopilot.com/mcp/
GitHub の公式 MCP サーバー を使うと、エージェントはリポジトリを読み、issue を開き、PR をレビューし、ブランチ管理までできます。コンテキストスイッチが減ります。必要なのは、Streamable HTTP をサポートする Cursor v0.48.0+ と Personal Access Token です。なお、古い npm package の @modelcontextprotocol/server-github は 2025 年 4 月に deprecated になりました。 使うなら、公式の hosted server か Docker image にしてください。
- Playwright (Microsoft) —
@playwright/mcp@latest
Microsoft の Playwright MCP は、エージェントに本物のブラウザを与えます。ページ遷移、フォーム入力、スクリーンショット取得、コンテンツ抽出までできます。しかもスクリーンショットではなく Playwright の accessibility tree を使うので、より速く、より安定しています。UI の検証やテストフローに向いています。
- Slack —
@modelcontextprotocol/server-slack
チャンネルの読み取り、メッセージ投稿、会話履歴の検索ができます。チームのやり取りに文脈がある場合に便利です。「先週この API について何を決めたっけ」を、自分で Slack を掘り返さずに答えられるようになります。
- Supabase MCP
公式 Supabase サーバーで、20 を超えるツールを持っています。テーブル設計、migration、SQL クエリ、database branching、project management まで扱えます。Postgres、認証、ストレージがまとまっているので、バックエンドを Supabase に置いているフルスタック開発者にはとくに便利です。
- Firecrawl —
firecrawl-mcp
URL を Markdown に変換します。エージェントは、ドキュメントページ、競合サイト、公開 URL をきれいなテキストとして取得して読めます。RAG パイプライン、コードベース外のドキュメント読解、競合調査に向いています。Firecrawl API key が必要ですが、free tier があります。
- Context7 —
@upstash/context7-mcp
ライブラリやフレームワークの最新かつバージョン固有のドキュメントを、エージェントのコンテキストへ直接持ち込みます。エージェントが詳しく知らないライブラリを扱うとき、古い学習データに頼るのではなく、今の実ドキュメントを引けるのが強みです。
- Memory —
@modelcontextprotocol/server-memory
knowledge graph 構造を使ったセッション間の永続メモリです。 これは少し面白い存在です。エージェントは会話をまたいで情報を保存し、取り出せます。実際どれくらい安定して使われるのかは、まだ確信が持てていません。何かを覚えているようにも見えるのですが、そのパターンが一貫しているとまでは確認できていません。注視する価値はあります。
- Puppeteer —
@modelcontextprotocol/server-puppeteer
Playwright に近いブラウザ自動化ですが、こちらは Puppeteer ベースです。手動サイトテストや、Claude に導かせながら Web ページを操作したいときに向いています。よりシンプルなスクレイピングでは、Playwright よりこちらを好む開発者もいます。
- Docker MCP
マルチコンテナ環境のオーケストレーション、サービスのデバッグ、デプロイ検証ができます。普段の開発ワークフローで Docker をよく使うなら便利です。エージェントが、端末へ切り替えずにコンテナの状態を確認できます。
どの MCP サーバーでも解決できないこと: 能力の持続性
ここは、私が繰り返し考えていることですが、まだ完全には整理できていません。
なぜ Cursor のエージェントは、うまくいった方法を忘れるのか
MCP サーバーは、エージェントへ外部ツールへのアクセスを与えます。これは本当に有用です。ただ、それでも別の問題は解決しません。エージェントは前回うまくいった方法を覚えていません。 どのセッションも新規スタートです。昨日成功したデバッグパターンは継承されない。2 週間前にある種のエラーを直したやり方も、消えてしまいます。
Cursor 向けの優れた MCP サーバーは、接続レイヤーをうまく扱います。MCP specification 自体 が定義しているのは、エージェントがツールへどう接続するかであって、成功した戦略を時間とともに蓄積し、共有する方法ではありません。
これは MCP への批判ではありません。単に、別の問題だということです。MCP が扱うのは access です。私が見ている限り、まだ欠けているのは、エージェントの 経験 を再利用可能にするレイヤーです。1 回のセッションでうまくいったやり方が、単発のツール呼び出しの中だけでなく、何かを作るライフサイクル全体をまたいで持ち越されるようなレイヤーです。
実際にそれがどんな形になるのか、まだ分かりません。もう少し見ていこうと思います。
FAQ
- Cursor に MCP サーバーを追加するにはどうすればいいですか。
方法は 3 つです。サーバーの docs ページにあるワンクリックの "Add to Cursor" ボタンを使う、Cursor Settings > Features > MCP > + Add New MCP Server から追加する、あるいは .cursor/mcp.json を手で編集する。チームで設定を共有するなら、設定ファイル方式のほうが向いています。JSON 構造はバージョンによって変わるので、最新の形式は Cursor の MCP ドキュメント を確認してください。
- 2026 年時点で、Cursor 向けのベスト MCP サーバーはどれですか。
うーん、単一の答えはないと思います。データベース中心なら Postgres サーバーがエージェントの動きを大きく変えます。Web アクセスが必要なら Brave Search か Firecrawl。バージョン管理なら公式 GitHub サーバー。いちばん役立つサーバーは、結局のところ、あなたのワークフローのどこにいまギャップがあるか、エージェントが本当は使いたいのにアクセスできないのはどのツールかで決まります。
- Cursor 向け MCP サーバーは無料ですか。
完全無料かつローカルで動くものもあります（Filesystem、Playwright、Memory）。一方で、API key が必要だけれど free tier があるものもあります（Brave Search、Firecrawl）。GitHub サーバーには Personal Access Token が必要です。Supabase には Supabase 側の料金体系があります。MCP 自体に費用はありません。open protocol です。
2026 年初頭の時点で、エコシステムは 5,000 を超えるサーバーまで広がっています。私はその大半を試さないでしょう。ここで挙げたのは、エージェントが技術的に「できる」ことを増やしただけでなく、こちらが指示しなくても実際の振る舞いを変えたものだけです。
この顔ぶれが年の途中でどう変わるのか、たぶんこれからも見ていくと思います。
注記: MCP サーバーの package 名やインストール方法は更新に伴って変わります。導入前に必ず公式ソースで確認してください。この記事内のすべてのリンクは 2026 年 3 月時点でアクセス可能であることを確認しています。
