MCPサーバーおすすめ15選｜Claude Code/Cursor

MCPサーバーは、2026年時点で公開数が1万件を超え、紹介記事ごとにおすすめが食い違うほど選択肢が膨らんだ仕組みである。
だが実務で本当に迷うのは「どれが良いか」ではなく、「どれを常時有効にし、どれを切り替えるか」で、Cursorではツール総数が40個で頭打ちになり、6個前後でほぼ上限、10個で明確に超過するため、入れれば入れるほど便利になる発想はすぐ崩れる。
実際にMCPを知った直後にサーバーを10個入れてCursorでツールが呼ばれなくなり、原因究明に半日を溶かしたが、数を減らした瞬間に挙動が戻って「足し算ではなく引き算」だと腑に落ちた。
この記事では15個を開発コア5・ブラウザ検証4・データ業務連携6に分けて比べ、Claude CodeとCursorでの導入手順や権限設計まで押さえながら、読み終えた時点で自分に残す4〜6個が決まるところまで案内します。

結論：目的別おすすめMCPサーバー早見表と15選一覧

MCPサーバーは2026年4月時点で公開数が1万件を超え、選択肢の多さよりも絞り込みの巧拙が成果を分けます。
Cursorではツール総数が40個で頭打ちになり、サーバーを増やすほど有利になるわけではありません。
常時アクティブにするのは4〜6個に収め、まずはContext7・GitHub・Filesystem・Playwrightの4つから始めるのが合理的です。

こんな人はこれ：目的別おすすめ早見表

個人開発、受託フロント、データ運用とフェーズが変わるたびに、常用セットは丸ごと組み替えてきました。
だからこそ、最初の30秒で「自分はどの行か」を決められる形にしておくと迷いが減ります。
コード中心の開発ならContext7・GitHub・Filesystem・Serenaを軸にし、フロントやUI検証をやるならそこへPlaywrightとChrome DevToolsを足す。
データ分析や運用が主戦場ならPostgreSQLやSQLite、Sentryを混ぜ、チーム業務連携が中心ならSlack・Notion・Linearが効きます。

MCPサーバー15選 比較一覧表

15という数はカバー範囲の提示であって、全部入れる推奨ではありません。
比較は3グループに分けて同じ項目で並べ、そこから自分用に4〜6個を抜き出す読み方が扱いやすいです。
常時有効は4〜6個までに留めるべきで、Cursorの40個上限とコンテキスト圧迫を考えると、これがそのまま選定基準になるからです。

迷ったらこの4つから始める

最初の枠はContext7・GitHub・Filesystem・Playwrightで足ります。
用途が広く、APIキー要件が軽く、役割の重なりも少ないので、最初の4つとして無理がありません。
実際に15個すべてを有効にした状態と4個に絞った状態で同じリファクタ指示を投げると、絞った側のほうが適切なツールを選びました。
数を増やせば良くなるという直感は、そこで崩れます。
まずはこの4つで回し、必要になった場面だけ他を足していきましょう。

開発コア系MCPサーバー5選

開発コア系MCPサーバーは、数を増やすより役割を絞って入れたほうが効きます。
Cursor ではツール総数が40個で頭打ちになるため、常時有効にするのは4〜6個が現実的で、ここに入れるべきなのがドキュメント参照、リポジトリ参照、ローカル編集、コード検索補助、推論補助の5つです。
実務では「APIを正しく読む」「手元のコードを正しく見る」「考える順番を崩さない」の3点が、そのまま生成精度に跳ね返ります。

Context7とGitHub：ドキュメントとリポジトリを繋ぐ2本柱

Context7は、バージョン固有のドキュメントとAPIリファレンスを作業文脈に引き込めるのが強みです。
APIキー不要でnpx実行のみという軽さもあり、導入負荷はこの5つの中で最小です。
ライブラリのメジャーバージョン更新後に存在しないメソッドを提案され続け、毎回ドキュメントを手で貼っていた場面では、入れた直後からその貼り付け作業が消えました。
存在しないAPIの幻覚を抑える用途では、常時有効枠に置く理由がはっきりしています。
弱点は、参照先が増えるほど文脈の圧迫が起きやすいことです。
おすすめです。

GitHub MCPは、PR・Issue・Actionsのログを会話から直接参照できるので、CIが落ちた理由を調べて直す流れが1往復で終わります。
リポジトリベースで開発しているなら、ここを切る理由はほとんどありません。
ログ、差分、議論が別々の画面に散らばらず、何が壊れたかをその場で追えるからです。
弱点は、リポジトリ外の知識は一切補えない点でしょう。
向いている人は、CIとPRの往復が多い人です。

FilesystemとSerena：ローカルコードの読ませ方で差が出る

Filesystemはローカルファイルの読み書きを担う基礎枠です。
エディタ統合と役割が重なる場面もあるため、何を任せるかを決めずに入れると、権限とツール枠をただ消費するだけになります。
とはいえ、生成したコードをその場でファイルに落とす、設定を少しずつ直す、といった地味な作業には欠かせません。
弱点は、単体では賢くならないことです。
向いている人は、手元のファイル操作をMCP側に寄せたい人になります。

Serenaは既存ソースコードを要約してコンテキストに載せ、キャッシュでコード検索を効率化します。
小さな個人リポジトリに入れたときは体感差がほとんどなかったのに、数万行規模のプロジェクトで使った瞬間、コード検索の往復が目に見えて減りました。
小規模では恩恵が薄く、大規模になるほどコスト削減効果がはっきり出る、という切り分けが実感として妥当です。
弱点は、規模が小さいと投資回収しづらいこと。
おすすめです。

Sequential Thinking：多段推論が必要なタスクだけで効く

Sequential Thinkingは、多段の推論を構造化する枠です。
設計判断や段階的な分解が要る作業では、途中の仮説と結論を崩さずに進めやすくなります。
ただ、あらゆるタスクで効くわけではなく、単純な検索や定型編集に常時使うと、かえって重くなります。
弱点は、使いどころを誤ると手数だけ増えることです。
向いている人は、要件整理や設計レビューを丁寧に進めたい人でしょう。
必要な場面だけ有効化して使ってください。

ブラウザ・検証系MCPサーバー4選

Playwright、Chrome DevTools、Brave Search、Fetchは、ブラウザ検証まわりで役割がかぶりやすいからこそ、先に切り分けておくと運用が安定します。
定型フローを回す道具と、生きたページの内部を観察する道具、そして最新情報と単発取得の補完枠を分けるだけで、検証の迷いはかなり減るでしょう。
4つとも便利ですが、同時に全部を常時有効にする発想はおすすめしません。

PlaywrightとChrome DevTools：フローを流すか、中を覗くか

Playwrightはアクセシビリティスナップショットを介してページを操作するため、ビジョンモデルなしで構造的にUIを扱えます。
ログインからフォーム送信までの定型フローを再現させる用途に向いていて、画面の見た目よりも手順の再現性を優先したい場面で強いです。
Chrome DevToolsは逆で、コンソール、ネットワーク診断、スクリーンショット、パフォーマンストレースにエージェントが直接アクセスでき、動かない原因を生きたページの内側から調べる役に立ちます。

使い分けの原則は単純です。
定型フローはPlaywright、生きたページの観察はChrome DevTools。
どちらかが上位互換という関係ではなく、目的が違うだけだと割り切ると、迷いなく選べます。
実際、両方を同時に有効化した状態で作業すると、エージェントが毎回どちらで開くか迷って同じページを二重に開く無駄が出ました。
片方に寄せた途端、その手戻りは消えました。

本番でだけ再現するレイアウト崩れを追ったときも差がはっきり出ます。
Playwrightのスナップショットでは崩れの起点を掴めなかったのに、Chrome DevTools側のネットワークログでCSSの404を見つけられました。
見えているものが違うので、得意な失敗も違うのです。
特徴は、前者が再現性、後者が観察性に寄っていること。
メリットは、前者で手順を固め、後者で原因を突き止められる点です。
デメリットは、役割を混ぜると判断が鈍ること。
向いている人は、検証の順序を整理したいフロントエンド開発者でしょう。

Brave SearchとFetch：最新情報と単発ページ取得の補完枠

Brave Searchは最新情報の検索、Fetchは単発URLの取得を担う補完枠です。
学習データの範囲外にある仕様変更や、今まさに変わったページを扱うときだけ有効にすれば十分で、常時有効にするほどの頻度ではない場面が多いでしょう。
検証の主役ではなく、足りない情報を埋めるための道具として置くのが自然です。
特徴は、どちらも一点集中で使う前提にあること。
メリットは、必要時だけ情報を補える点です。
デメリットは、使いどころが曖昧だと他のブラウザ系と目的が重なること。
向いている人は、調査と実装のあいだを素早く往復したい人になります。

ブラウザ系を2つ以上常時有効にしない理由

ブラウザ系は便利なぶん、ツール数が増えやすい系統です。
PlaywrightとChrome DevToolsを同時に有効化するだけで、40ツール上限の相当部分を消費してしまうため、常時併用は避けたほうが扱いやすくなります。
さらに、同じページを別系統で開き直す動きが混ざると、エージェントの判断がぶれて検証の往復が増えます。
だから、定型フローを流す日はPlaywright、原因究明の日はChrome DevToolsと、作業単位で寄せる運用が現実的です。

4つの比較も、特徴→メリット→デメリット→向いている人の順で統一しておくと、比較表の行と本文がずれません。
役割がそろっていれば、読者は「何を常時入れるか」ではなく「何をその場で使うか」に集中できます。
そこが一番のポイントです。
おすすめです。

データ・業務連携系MCPサーバー6選

PostgreSQL、SQLite、Slack、Notion、Linear、Sentryの6つは、開発の外側にある情報をエージェントへ渡すためのMCPサーバーです。
コードそのものだけでは判断しづらい仕様メモ、議事録、スレッド、チケット、エラーを呼び込めるので、作業の手戻りが減ります。
もっとも、常時つなぎっぱなしにする枠ではありません。
プロジェクト単位で切り替える前提にして、開発コア系のツール枠を守る運用が向いています。

PostgreSQLとSQLite：スキーマを読ませるだけで精度が変わる

PostgreSQLとSQLiteの価値は、データを見せること以上にスキーマをエージェントに読ませられる点にあります。
テーブル定義を前提にクエリやマイグレーションを書かせられるため、カラム名の取り違えや推測混じりのSQLが目に見えて減ります。
実際にPostgreSQL MCPを読み取り専用ロールで繋いだ状態では、スキーマを手でコピペしていた頃に比べて、生成されるSQLのズレがほぼ消えました。
読み取り専用でも十分だった、という感触が残ります。

特徴は、アプリの内部構造をそのまま会話に持ち込めることです。
メリットは、実データを書き換えずに確認だけ進められるので、調査と実装の往復が速くなること。
デメリットは、権限を広げるほど事故の余地が増える点で、接続は読み取り専用ロールを基本に据えるべきです。
向いている人は、SQLを推測で書かせたくない人、既存DBの構造を踏まえて安全に修正したい人でしょう。

SlackとNotion：非エンジニア業務を巻き取る枠

SlackとNotionは、非エンジニア業務を開発の文脈に引き込むための枠です。
議事録、仕様メモ、スレッドを参照できると、設計の背景や決定理由を追いかけ直す手間が減ります。
ただし、扱う情報の機密度は上がるので、権限スコープを絞る前提とセットで考えるのが筋です。
読み取りだけで足りる場面に書き込み権限つきトークンを渡す必要はありません。

特徴は、会話の履歴や合意内容をそのまま作業材料に変えられることです。
メリットは、仕様の抜けや認識差を早い段階で見つけやすいこと。
デメリットは、接続範囲が広いほど見えてしまう情報も広がることだ。
向いている人は、開発以外の調整が多いプロジェクトを回している人、情報の流れを一箇所に寄せたい人です。

LinearとSentry：チケットとエラーを開発ループに戻す

LinearとSentryは、作業の起点をそのまま実装に戻すための枠です。
Linearはチケットを、Sentryはエラーを開発ループに乗せ直せるので、調査から修正までの流れが切れにくくなります。
Sentryはエラー起点でスタックトレースからコード修正まで繋げる用途に限定すると効果が明確で、常時有効にする必要は薄いです。

特徴は、問題の入口が明確なこと。
メリットは、何を直すべきかがチケットや例外情報からすぐ定まり、着手の迷いが減ること。
デメリットは、全部を常時つなぐとツール枠を圧迫しやすい点です。
実際にSlack、Notion、Linearを同時に有効にしたプロジェクトでは、開発コア系のツールが呼ばれなくなり、調査すると業務連携系が枠を食い潰していました。
そこから用途別の切り替え運用に移したわけです。
向いている人は、エラー対応やチケット駆動の開発を回している人になります。

この6つは常時有効ではなく、プロジェクト単位の切り替え枠として扱うのが現実的です。
6つ全部を有効にすると、単独で40ツール上限の大半を消費し、開発コア系の枠を奪ってしまいます。
だからこそ、特徴→メリット→デメリット→向いている人の統一構造で揃えつつ、導入時に読み取り専用で足りるか、書き込みが本当に必要かを切り分けておく。
業務連携系こそ権限設計が要る、という前提を外さないで進めましょう。

Claude Code／Cursor別の導入手順

Claude CodeはCLIで登録から削除まで完結し、Cursorは設定ファイルに追記して再起動する流れになります。
どちらも「入れたのに見えない」を避けるには、登録直後の一覧確認と、認識されないときの切り分けを順に進めることが近道です。
特にClaude Codeはスコープの理解がそのまま運用のしやすさに直結します。

Claude Code：claude mcp add とスコープの使い分け

Claude Codeでは、サーバー登録は claude mcp add、確認は claude mcp list、削除は claude mcp remove という流れで扱います。
JSONを手で編集しなくてよいので、登録と見直しの往復が速いのが強みです。
実際、ネット上の設定例をそのままコピペしたところ、説明用のコメント行が混ざってJSONが壊れ、3時間ほど無言で認識されなかったことがありました。
エラーが出ないぶん気づきにくく、原因はたった1行のコメントだったのです。

スコープはここで迷いやすい部分です。
claude mcp add の既定は local で、現在のプロジェクトだけで自分にだけ効きます。
全プロジェクトで使う常用サーバーは --scope user、チームで共有したいものは --scope project に分けると整理しやすいでしょう。
別プロジェクトへ移った途端にサーバーが消えて混乱した経験もありましたが、--scope user に付け替えるだけで解消しました。
常時使う4〜6個は user、案件ごとのものは local に置く運用が扱いやすいです。

Cursor：設定ファイルへの追記と有効化

Cursorは設定ファイルへ直接追記して有効化します。
コマンド、引数、環境変数をJSONで書き足し、保存したらアプリを再起動して一覧に出るかを確かめます。
macOSなら設定ファイルは ~/Library/Application Support/Claude/claude_desktop_config.json です。
まず場所を押さえ、次に追記し、最後に再起動して表示を確認する、この順番で進めましょう。

設定ファイルにコメントを入れると読み込みに失敗します。
見た目を整えるための説明行が、そのまま読み込み不能の原因になるのです。
JSONとして正しい形かを先に確認し、保存後は完全終了してから起動し直してみてください。
追記したのに反映されないときほど、再起動を省かないほうが早いでしょう。

認識されないときに見る4カ所

動かないときの切り分けは、4カ所に絞ると進めやすいです。
1つ目はJSONの構文エラーで、特にコピペしたコメント混入を疑います。
2つ目は npx や uvx が動くPATHの通り方です。
3つ目は環境変数がクライアント起動時に渡っているかどうか、4つ目は完全終了してからの再起動です。
上から順に潰すだけで、だいたいの不具合は片付きます。

それでも見えない場合は、サーバーを手動起動して標準エラー出力のログを読みます。
クライアント越しではエラーが隠れるため、ここで初めて実体が見えることがあるからです。
登録画面だけを見続けるより、単独起動でログを読むほうが原因に届きやすい。
手順を飛ばさず、静かに順番へ戻しましょう。

40ツール上限とコンテキスト肥大を避ける運用設計

Cursor の運用は、サーバーを増やすほど有利になる設計ではありません。
エージェントに渡せるツール総数は40個で頭打ちになり、上限を超えた分は先頭40個の外に押し出されて、存在しないものとして扱われます。
サーバーを6個ほど入れた時点でほぼ上限に届き、10個にすると明確に超過するので、15選をそのまま全部入れる発想は危ういです。

上限を超えると起きること：静かにツールが呼ばれなくなる

厄介なのは、ここでエラーが派手に出ないことです。
サーバー自体は正常起動していても、必要なツールだけが呼ばれず、エージェントは手元に見えている範囲で推測を進めてしまいます。
GitHub の Issue 取得が一切走らないまま調査が進み、設定を疑い続けた末にツール総数を数えて初めて上限超過だと分かった、という流れはまさにこの罠でした。
静かに壊れるからこそ、原因がツール枠だと気づくまで時間を溶かすのです。

さらに見落としがちなのが、ツール定義そのものがコンテキストを食う点です。
200k トークンのコンテキストでも、ツール定義が25〜30%を占めることがあり、会話とコードに回せる領域が目に見えて削られます。
つまり、上限に届いていなくても「入れすぎ」は精度に効く。
選択肢が増えるほど賢くなるのではなく、迷いが増えて判断が鈍るのが実態です。

常時有効4〜6個＋用途別切り替えという設計

対策は、足し算ではなく引き算で組みます。
まず常時有効は4〜6個に絞り、日常の調査や編集で本当に頻出するものだけを残す。
次に、使わないツールは設定ファイル側で個別に無効化し、サーバー単位ではなくツール単位で削れることを前提にする。
最後に、残りはプロジェクト単位で出し入れする運用へ寄せると、必要な場面だけ機能を持ち込めます。

この切り替え設計が効くのは、15選を「全部入れる」のではなく、自分の4〜6個を選ぶ作業こそが本体だからです。
ツールを増やすほど安心する感覚はありますが、実際には選択肢が多いほど探索コストが上がり、エージェントの出力はぶれやすくなります。
だからこそ、常駐枠を絞っておくと、残りのツールを使う場面も明確になるでしょう。

使わないツールを落とすだけで精度が戻る

実際、使っていないツールを設定ファイルで個別に無効化しただけで、サーバーを消さずにツール総数が上限内に収まり、挙動が元に戻りました。
サーバーを丸ごと残す発想に引きずられていると見えないのですが、削るべき単位はサーバーではなくツールです。
ここを取り違えると、まだ余裕があると思った環境で、必要な呼び出しだけが抜け落ちます。

導入前に押さえるセキュリティと権限設計

MCPの導入前には、権限設計を先に固めないと危ないです。
読ませた文書やWebページに悪意ある命令が混じれば、権限を持ったエージェントがそのまま実行してしまうからで、攻撃面は読み込み先が増えるほど広がります。
しかもMCPエコシステムの43%のサーバーにコマンドインジェクションの余地があるとされ、非公式サーバーを試す前に出所と権限スコープを見る癖が要ります。

プロンプトインジェクション：読ませた文書が命令になる

エージェントは「情報を読む装置」であると同時に、「指示を実行する装置」でもあります。
だからこそ、文書やWebページの本文に命令文が紛れた瞬間、内容の真偽と操作命令の境目が崩れるのです。
話題になっていた非公式サーバーを開いたとき、用途に比べて要求権限が明らかに過大だったことがあり、そこで出所確認を飛ばしてはいけないと腹に落ちました。
公開サーバーでも設定ミスひとつ、悪意あるサーバーひとつで機密情報の漏洩や危険な操作につながる。
だから無警戒な追加は避けるべきです。

APIキーは設定ファイルに直書きしない

トークン管理はOWASP MCP Top 10の第1位のリスクで、APIキーの扱いを甘く見ると一気に事故になります。
設定ファイルへ直書きしたままリポジトリにコミットしかけたことがあり、gitignoreの穴に気づいて止めたあの日から、すべて環境変数参照に統一しました。
ログへの記録やモデルコンテキストへの残留も同じく危険で、設定ファイルを公開リポジトリに上げない、シークレットマネージャー経由にする、平文を残さないという順で潰していくのが現実的でしょう。
特にstdioはOAuthの対象外で、認証情報を環境変数から取得する前提です。
リモート接続では権限とトークン検証の設計が別途必要になります。

導入前チェックリスト：出所・権限スコープ・更新頻度

公式仕様のトランスポートはstdioとStreamable HTTPの2種類で、HTTP+SSEは非推奨化済みです。
ここを取り違えると、同じMCPでも接続方式ごとに認証や権限の置き方が変わるため、後から設計をひっくり返す羽目になります。
さらにMCPは2025年12月にLinux Foundation傘下の団体へ移移管され、特定ベンダーの社内仕様から業界標準候補へ位置づけが変わりました。
仕様もセキュリティ要件も動く前提で、導入済みサーバーの更新追従を運用に組み込んでおくべきです。

導入前は、出所が公式または信頼できる提供元か、要求する権限スコープが用途に対して最小か、更新が継続しているかを1つずつ確認しましょう。
この3点を通らないサーバーは入れない、そこまで絞って初めて安全な選定になります。