おすすめMCPサーバー実践カタログ｜用途別の選び方とclaude mcp add導入手順【2026】

MCPサーバーは数が増え、公式リファレンスも再編されて「結局どれを入れて、どう選び、どう導入すればいいか」が分かりにくい。本記事は2026年6月23日時点の各社公式情報に基づき、特定サーバーやホストを推さず中立に整理する。MCPの仕組み・概念は「MCPとは（仕組み・できること）」に委譲し、ここでは用途別カタログと選び方、導入差分に絞る。

迷ったらまず公式リファレンスの Filesystem （手元ファイル）と Fetch （Web取得）から小さく始め、用途が固まったら開発＝Git／Memory・業務＝各SaaSのリモート公式サーバー・データ＝目的別サーバー、と広げるのが堅い。選定は「用途適合 × 接続方式（stdio／Streamable HTTP）× 信頼ティア（公式リファレンス／提供元公式／コミュニティ・未検証）」の3点で判断する。導入は Claude Code なら claude mcp add だが、ホストにより設定キーや対応トランスポートが異なる（2026-06-23時点）。

なお当社（YDAIコンサルティング AI編集部）は Claude 系ツールのヘビーユーザーであり、Anthropic のエコシステムで開発受託も行う立場にある。そのうえで、本記事はどのサーバーもホストも勝たせず中立に整理する。自社サービスへの送客は一切しない。

結論：用途別カタログ早見（統合早見表）

万能の1サーバーはなく、用途で選ぶ。下表は「用途→推奨サーバー→接続方式→導入の起点→信頼ティア」を1行で結ぶ本記事独自の統合早見表である。カタログ記事には導入コマンドがなく、設定記事にはカタログがない。この分断を1枚で埋めるのが本記事の核だ。

用途	推奨の起点（公式リファレンス土台）	接続方式	導入の起点（Claude Code 例）	信頼ティア
手元ファイル操作	Filesystem（許可ディレクトリを引数明示）	stdio	claude mcp add fs のあと -- で npx 起動コマンドを区切る	公式リファレンス
Web取得	Fetch	stdio	同様に -- 区切りで npx 起動（パッケージ名は公式参照）	公式リファレンス
開発（履歴／記憶／思考補助）	Git／Memory／Sequential Thinking	stdio	同様に npx 起点で追加	公式リファレンス
業務SaaS連携	各サービス提供元のリモート公式サーバー	Streamable HTTP	claude mcp add --transport http のあと名前とURL（認証は --header）	提供元公式（維持主体が移管／変動・要確認）

推奨サーバーは公式リファレンス（ステアリンググループ維持の参照実装）を土台にしている。GitHub／Slack などSaaS系は「提供元公式相当だが維持主体が移管／変動」と信頼ティアで明示する。サーバー個別の安全性は断定しない。サーバー名と件数は2026-06-23時点・出典は modelcontextprotocol/servers README である。

MCPとトランスポートの前提

MCPの概念（Host／Client／Server、Tools／Resources／Prompts の3機能）は「MCPとは」で解説しているため、本記事では再展開しない。導入を判断するうえで押さえたいのは、現行の接続方式（トランスポート）が正確に何かという点だ。

方式	用途	現況（2026-06-23時点）
stdio	手元のローカルツール／ファイル	標準（仕様はクライアントに可能な限りサポートを推奨＝SHOULD）
Streamable HTTP	リモートSaaS／サーバー	標準（単一エンドポイントで動作・任意でSSEストリーム）
HTTP+SSE（旧・2024-11-05版）	—	Streamable HTTP に置換され非推奨（後方互換で維持可だが新規採用しない）

つまり標準トランスポートは stdio と Streamable HTTP の2種だ。古い記事にある「stdio／SSE／HTTPの3本柱」という表記は、現在は不正確になっている。Streamable HTTP はローカル実行時に localhost へバインドし、Origin ヘッダを検証するのが必須要件である（DNSリバインディング対策・出典: MCP公式仕様 Transports）。

MCPサーバーの選び方5軸

サーバー選びは「用途適合 × 接続方式 × 信頼ティア」の3点で大枠が決まる。順に整理する。

用途適合（何をさせるか）

サーバーが公開する Tools／Resources／Prompts のうち「自分の用途に必要な操作・参照があるか」で一次選別する。開発ならファイルやGit、業務ならSaaS操作、データなら検索や取得、と用途を先に固定してからサーバーを選ぶと迷いが減る。公式リファレンスは教育・デモ目的の参照実装であり、プロダクション前提ではない点も用途適合の判断材料になる（出典: modelcontextprotocol/servers README）。

接続方式（stdio／Streamable HTTP）

手元のツールに繋ぐなら stdio、リモートのSaaSに繋ぐなら Streamable HTTP を選ぶ。仕様はクライアントに可能な限り stdio のサポートを推奨している（SHOULD）。Streamable HTTP は localhost バインドと Origin 検証が必須要件だ。旧式のSSEは仕様・Claude Code の双方で非推奨のため、新規構築では採用しない（出典: MCP公式仕様 Transports）。

信頼ティア（公式リファレンス／提供元公式／コミュニティ）

維持主体で3ティアに分ける。1つ目はステアリンググループが維持する公式リファレンス（少数）。2つ目は提供元公式のリモートサーバー（GitHub／Slack／Notion 等＝公式相当だが維持主体が移管／変動）。3つ目はコミュニティ製・未検証だ。ティアは「導入してよい順」ではなく「確認すべき度合い」を表す。掲載や公式相当であってもコードの安全性は別問題で、後述の安全チェックと必ずセットで考える（出典: modelcontextprotocol/servers README）。

導入の基本：claude mcp add と多ホスト差分

導入手順はホストごとに設定キーや対応トランスポートが異なる。本記事は各ホストを横断して同じ粒度で並べることに価値を置き、ホスト固有の詳しい手順は各専用記事へ委譲する。

Claude Code は claude mcp add が起点（詳しい手順は連携ガイドへ）

Claude Code では claude mcp add がサーバー追加の起点になる。リモートのHTTPサーバーとローカルの stdio サーバーに対応し、適用範囲は local（既定）／project（チーム共有）／user（全プロジェクト）のスコープで切り替えられる。具体的なコマンド構文（トランスポート指定・コマンド区切り・認証ヘッダ・OAuth）、5ステップの詳しい導入手順、エラー対処、project スコープの承認運用は、Claude Code 固有の領域として「Claude Code × MCP 連携 実践ガイド」へ委譲する。本記事では下表のとおり Claude Code を多ホスト差分の1行として横断比較に置く（出典: Claude Code 公式docs）。

他ホストの導入差分（ChatGPT／Gemini CLI／Copilot）

設定キーと対応トランスポートがホスト間で実際に異なる。これを並べて把握できることが、多ホスト横断の独自統合価値の核になる。

ホスト	設定キー	対応トランスポート	特記（2026-06-23時点・要再確認）
Claude Code	claude mcp add（CLI／.mcp.json）	stdio／Streamable HTTP（SSEは非推奨）	local（既定）／project／user スコープ・OAuth対応
ChatGPT developer mode	developer mode のUI・コネクタ	リモートのみ（SSE／Streamable HTTP）・stdio不可	書込フルコネクタはBusiness／Enterprise／Edu限定・個人プランはread／fetchのみ
Gemini CLI	settings.json の mcpServers	stdio／SSE／Streamable HTTP	command／url／env／timeout 等を指定・ヘッダ指定可
GitHub Copilot	.vscode/mcp.json の servers	VS Code 1.99以降のAgentモード	ルートキーが servers で他ホストの mcpServers と異なる・tools のみ対応

特に GitHub Copilot のルートキーは servers で、Claude Code や Gemini CLI の mcpServers とは異なる。ここは誤記しやすい要注意点だ。なお claude mcp add は本記事の主KWだが、導入手順をClaude Code偏重にせず各ホストを同粒度で並記している。各ホストのバージョン依存や対応状況は変動が速いため、最新は各社公式docsで確認してほしい（出典: 各社公式docs）。

導入前の安全チェック

サーバー選定で見落とされやすいのが安全性だ。「公式に載っている＝安全」という誤読を断つことが、このセクションの目的になる。

「公式Registry掲載＝安全」ではない

Registryやカタログへの掲載は、メタデータの公開でありコード審査ではない。掲載の有無とコードの安全性は別概念だ。仕様自体がプロンプトインジェクションやDNSリバインディング等の対策を、サーバー実装側に要求している（MUST／SHOULD）。ソースが検証されていることと、コードが安全であることは切り分けて考える必要がある（出典: MCP公式仕様 Transports Security Warning）。

仕様が要求する安全要件と最小権限

ツールは実質的に任意コード実行に相当する。Claude Code の公式docsも「接続前に各サーバーを信頼できるか確認する」「外部コンテンツを取得するサーバーはプロンプトインジェクションのリスクがある」と警告している。Streamable HTTP は Origin 検証と localhost バインドが要件だ。提供元の確かなサーバーを最小権限で使い、stdio の Filesystem は許可ディレクトリを引数で明示する（無制限アクセスではない）。権限設計の具体は「Claude Code×MCPの権限設定でよくある失敗5つと回避策」へ委譲する（出典: MCP公式仕様・Claude Code 公式docs警告・npm @modelcontextprotocol/server-filesystem）。

公式リファレンスとRegistryの現在地

カタログを正しく作るには、公式が今どこまで提供しているかの現在地を押さえる必要がある。ここは変動が速く、古い情報が残りやすい領域だ。

公式リファレンス7種とarchived再編

ステアリンググループが維持する公式リファレンスは、現役で Everything・Fetch・Filesystem・Git・Memory・Sequential Thinking・Time の7種だ。READMEはこれらを「教育・デモ目的の参照実装でプロダクション用ではない」と明記している。かつて含まれていた GitHub・GitLab・Google Drive・PostgreSQL・Puppeteer・Slack などは servers-archived へ移管済みで、Slack は現在 Zencoder が維持するなど主体が移っている。「公式のGitHubサーバーやSlackサーバーがある」という案内は、現在では不正確だ（出典: modelcontextprotocol/servers README）。

公式Registry（preview・GA未到達）と2026動向

公開サーバーの探索は MCP Registry へ誘導される設計で、リファレンスのリポジトリ自体はサーバー総数を数値で示していない。Registryは2025年9月8日にプレビュー公開され、データ永続性は保証されず破壊的変更やリセットの可能性があるとされ、一般提供（GA）には未到達だ（2025年10月にv0.1でAPIフリーズ）。バックは Anthropic・GitHub・PulseMCP・Microsoft である。掲載サーバー数や総数、各リポジトリのスター数は変動／未確認のため、本記事では断定せず公式参照とする（出典: MCP Registry preview 公式ブログ）。

まとめ

MCPサーバーは万能の1本を探すのではなく、用途で選ぶ。まず Filesystem と Fetch から小さく始め、用途が固まったら開発＝Git／Memory・業務＝提供元公式のリモートサーバー・データ＝目的別、と広げるのが堅い。判断軸は「用途適合 × 接続方式（stdio／Streamable HTTP）× 信頼ティア」の3点だ。掲載は安全の保証ではないため、提供元を確認し最小権限で使うことを忘れない。MCPの概念は「MCPとは」、Claude Code固有の詳しい手順は「Claude Code × MCP 連携 実践ガイド」へ。再編や対応状況は変動が速いので、導入前に各社公式で最新を確認してほしい。

---

MCP導入でつまずく前に押さえたい安全設計

どのサーバーを最小権限でどう繋ぐかは、事故を防ぐ最初の一歩です。AIエージェントが失敗するパターンと対策も、導入前のリスク把握に役立ちます。