MCPサーバーとは｜仕組み・一覧・おすすめ・作り方・設定を2026年最新で解説

「MCPサーバーとは何か」を一言でいえば、AIアプリケーションに対してツール・データ・定型プロンプトを標準化された方式で提供するプログラムだ。Model Context Protocol（MCP）はAnthropicが2024年11月に公開したオープン標準で、Claude CodeやCursorといったAIツールが外部システムと繋がるための共通規格になっている。本記事は「MCPサーバー」というキーワードで探す人が知りたいとは・一覧・おすすめ・作り方・設定・セキュリティを、2026年時点の公式仕様ベースで一気通貫に解説する本山（ピラー）ガイドだ。

MCP公式は、この仕組みを「AIアプリケーションのためのUSB-Cポート」と表現する。USB-Cがあらゆる機器を共通端子で繋ぐように、MCPはAIアプリと外部システムを共通の手順で繋ぐ。一度サーバーを作れば、対応するどのクライアントからも同じように呼び出せる——この「一度作ればどこでも繋がる」性質が、MCPサーバーが急速に普及した最大の理由だ。

30秒で理解する

時間がない読者のために、本記事の要点を先に示す。詳細は各セクションで深掘りする。

MCPサーバーは難解な分散システムではない。本質は「AIに使わせたい機能を、決められたフォーマットで宣言するだけ」のシンプルな仕組みだ。以下、その全体像を順に見ていく。

MCPサーバーとは何か

MCPサーバーとは、MCP（Model Context Protocol）という標準に従って、AIアプリケーションへ文脈や操作手段を提供するプログラムである。ここで重要なのは、MCPが「プロトコル（通信規格）」であり、MCPサーバーが「そのプロトコルを話す具体的な実装」だという区別だ。HTTPという規格に対してWebサーバーが実装であるのと同じ関係にある。

Anthropicが2024年11月にMCPを公開して以降、対応の輪は急速に広がった。2026年時点で、Claude Code・Claude Desktop・Cursor・Cline・Windsurf・VS Code（Copilot Chat）・Continueなど主要なAI開発環境がMCPクライアントとして対応している。公式リファレンス実装をまとめた modelcontextprotocol/servers リポジトリはGitHub Star 8万6千超を集め、Anthropic単独の仕様から事実上の業界標準へと位置づけが変わった。

MCP公式は、MCPの守備範囲を明確に区切っている。MCPは「文脈をやり取りするためのプロトコルのみ」を定義し、AIアプリがLLMをどう使うか・与えられた文脈をどう管理するかには踏み込まない。つまりMCPサーバーが行うのは「機能を標準フォーマットで差し出す」ところまでで、その機能をいつ・どう使うかの判断はホスト側のAIに委ねられる。

なぜMCPサーバーが必要なのか

MCP登場以前、AIに外部ツールを使わせるには、ツールごと・モデルごとに独自の連携コードを書く必要があった。N個のAIアプリとM個のツールを繋ぐには、最悪N×M通りの実装が要る。MCPはこの「M×N問題」を「M＋N問題」に変える。ツール提供側はMCPサーバーを1つ作ればよく、AIアプリ側はMCPクライアントを1つ実装すれば、両者は自動的に繋がる。冒頭の全体像図で示した右側の世界がこれにあたる。

この標準化の恩恵は、AIエージェントの実用化と密接に結びついている。チャットで返答するだけのAIから、外部を調べ・操作して仕事をこなすAIへ——その移行を支えているのがツール接続の標準化だ。エージェントの全体像については AIエージェントとは？仕組み・種類・代表的OSSフレームワークを初心者向けに解説【2026年版】 で体系的に整理している。MCPサーバーは、そのエージェントに「手足」を与える層だと捉えるとわかりやすい。

企業システムの中でのMCPサーバー

MCPは個人開発のツールに留まらず、企業のAI基盤にも組み込まれ始めている。たとえばMicrosoftは、自社のAIスタックをWork/Web/Foundry/Fabricの4層で整理し、その各層をMCPやRAGで接続する構想を示している。詳しくは Microsoft IQの4層を読み解く——Work/Web/Foundry/FabricとMCP・RAGの関係 を参照してほしい。開発ツール側でもMCP対応は標準装備になりつつあり、Pydantic作者が語る「MCPの正しい使い方」は 「MCP is all you need」Pydantic作者が語るMCPの正しい使い方とsampling完全解説 にまとめた。MCPサーバーは、こうした各社のAI戦略を横断して繋ぐ「共通配線」として機能している。

MCPサーバーのアーキテクチャ

MCPサーバーの設計を理解する鍵は、「3つの登場人物」と「2つの層」だ。公式仕様はこの2軸でアーキテクチャを定義している。

まず登場人物から見ていく。MCPはクライアント・サーバー型の構成を取り、次の3者が登場する。

ここで間違えやすいのが、ホストとクライアントの関係だ。1つのホストは、接続するサーバーの数だけクライアントを生成する。たとえばVS Codeがファイルシステムサーバーとデータベースサーバーの2つに繋ぐなら、VS Code内部には2つのクライアントオブジェクトが生まれ、それぞれが片方のサーバーと専用接続を結ぶ。サーバーが「ローカル」か「リモート」かは、どこで動くかとどのトランスポートを使うかの違いに過ぎず、MCPサーバーという呼び名は実行場所を問わない。

この関係を図にすると次のようになる。

次に「2つの層」だ。MCPはデータ層とトランスポート層に分かれている。

データ層は内側、トランスポート層は外側にある。重要なのは、トランスポート層が通信の詳細を抽象化しているため、stdioでもHTTPでも同じJSON-RPC 2.0メッセージがそのまま流れる点だ。サーバーを書く側はトランスポートの違いをほとんど意識せず、ツールのロジックだけに集中できる。

サーバーが提供する3つの基本要素

MCPサーバーがクライアントに差し出せるものは、公式仕様で3つの基本要素（primitives）に定義されている。これがMCPサーバーの「中身」だ。

加えて、サーバー側だけでなくクライアント側が提供できる要素もある。Sampling（サーバーがクライアント経由でLLM補完を要求）、Elicitation（サーバーが利用者に追加入力を求める）、Logging（サーバーがクライアントへログを送る）の3つだ。これにより、サーバー作者は自分のサーバーにLLM SDKを同梱せずとも、ホストのモデルを間接的に利用できる。

接続のライフサイクルとJSON-RPC

MCPはステートフルなプロトコルで、接続開始時に「能力交換（capability negotiation）」を行う。クライアントが initialize リクエストを送り、お互いがサポートする機能とプロトコルバージョン（例：2025-06-18）を確認し合う。バージョンが噛み合わなければ接続を打ち切る。この握手の後、クライアントは tools/list で利用可能なツールを発見し、tools/call で実行する。一連の流れをシーケンスで示すと次のようになる。

実際のやり取りはすべてJSON-RPC 2.0で表現される。たとえばツール実行のリクエストはこうなる。

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "tools/call",
  "params": {
    "name": "weather_current",
    "arguments": { "location": "Tokyo", "units": "metric" }
  }
}

サーバーは結果を content 配列で返す。テキスト・画像・リソースなど複数形式を混在させられるのが特徴だ。ツールが増減したときはサーバーから notifications/tools/list_changed 通知が飛び、クライアントは一覧を取り直す。この動的な更新の仕組みにより、状況に応じてツールが増減する環境でも整合性が保たれる。プロトコル内部の詳細は MCPとは何か？AIに手足を与えるプロトコルの仕組みと実践ガイド2026 でさらに掘り下げている。

MCPサーバー一覧【公式リファレンス＋人気サードパーティ】

「MCPサーバー 一覧」で探す人が知りたいのは、結局どんなサーバーがあり、何ができるのかだ。ここでは公式リファレンスと、各社公式・コミュニティの人気サーバーをカテゴリ別に整理する。エコシステムは拡大が速いため、以下は「代表例の地図」として使い、導入前には必ず公式リポジトリやMCP Registryで現状を確認してほしい。

まず、modelcontextprotocol/servers リポジトリで現在も保守されている公式リファレンスサーバーを押さえておきたい。これらは「お手本」として最小構成で書かれており、自作の参考にもなる。

公式リファレンスは意図的に小さく保たれており、Brave Search・GitHub・GitLab・Google Drive・PostgreSQL・Slackなど、かつてリポジトリ内にあったサーバーの多くは「アーカイブ」化された。現在これらに相当する実用サーバーは、各社公式やコミュニティが提供し、公式の「MCP Registry」から探す形に移行している。以下、実用サーバーをカテゴリ別に並べる。当サイトで個別解説しているものは、名称からリンクしている。

開発補助のMCPサーバー

情報取得・Web検索のMCPサーバー

SaaS連携・コミュニケーションのMCPサーバー

業務ツール・自動化のMCPサーバー

データ分析・DB・金融のMCPサーバー

セキュリティ分野では、MCP for Security（Nmap・SQLmap・Nucleiなど22ツールを自然言語で操作）が代表格だ。複数サーバーをまとめて管理したくなったら MCP Manager や Claude Desktop のコネクタ機能が役に立つ。以上を合わせると、公式7本＋主要サードパーティ40本超で、実務で名前を見るサーバーはおおむね網羅できる。

用途別おすすめMCPサーバー

「MCPサーバー おすすめ」で迷うなら、用途がはっきりしたものから1〜2個だけ試すのが正解だ。全部入れると権限もコンテキストも膨らみ、AIがツール選択に迷って精度が落ちる。ここでは5つの用途別に、まず入れたい定番を挙げる。選定基準は「AI開発で頻度が高い作業か」「提供元が確認できるか」「stdioで手元に閉じられるか」の3点だ。

開発補助：コードとブラウザをAIに触らせる

コーディング支援は、MCPの効果が最も出やすい領域だ。次の3つはClaude CodeやCursorとの相性が良い。

・Serena MCP：LSP（言語サーバー）でコードをシンボル単位に扱い、ファイル全文を読ませずに済むためClaude Codeのトークン消費を大きく削る。大規模リポジトリで効く
・Chrome DevTools MCP：AIがChromeをDevTools Protocol経由で操作し、パフォーマンス計測・DOM検査・ネットワーク確認まで行える。claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest の1コマンドで追加できる
・Figma MCP：Dev Modeの変数・レイアウトを構造データで渡し、デザインからコードを起こす精度を上げる

情報取得：最新情報とWebをAIに与える

LLMの知識カットオフを補い、AIに「今のWeb」を見せる用途だ。

・Fetch（公式）：単一URLを取得してテキスト化する最小構成。まずこれで十分なケースが多い
・Firecrawl MCP：サイト全体のクロール・構造化抽出まで踏み込む。調査タスクで威力を発揮する
・Context7：ライブラリの最新ドキュメントを文脈に注入し、古いAPIを提案する事故を減らす

SaaS連携：日々使う業務ツールと繋ぐ

チャット・タスク管理・通知など、既存のSaaSをAIの操作対象にする。

・LINE Bot MCP（LINE公式）：ClaudeがLINE Messaging APIを直接操作。通知・応答の自動化に
・Notion / Linear（各社公式）：ドキュメントとIssueをAIから読み書き。開発・運用のハブになる
・Google Analytics MCP（Google公式）：GA4のレポートを「先月の流入は？」と聞くだけで取得

業務ツール・自動化：ワークフローをAIで組む

繰り返し作業をエージェントに任せる領域。ノーコード基盤との接続が鍵になる。

・n8n MCP：自然言語でn8nワークフローを構築し、数百のSaaS連携をAI起点で回す
・Zapier MCP（Zapier公式）：既存のZap資産をそのままAIから起動できる
・sv-excel-agent：LLMがExcelを直接編集。定型帳票の更新を任せられる

データ分析：DBと分析基盤に問い合わせる

「SQLを書かずにデータに聞く」用途。読み取り専用ロールで繋ぐのが安全だ。

・PostgreSQL / Supabase MCP：スキーマを理解した上で自然言語からクエリを生成・実行
・TradingView MCP：チャートとテクニカル指標の取得を自動化
・awesome-finance-mcp：金融特化のサーバーをまとめて探せるカタログ

MCPサーバーの作り方【Python・TypeScript・Rust】

「MCPサーバー 作り方」で来た読者のために、3言語で最小実装を示す。MCPサーバーは「読むより作るほうが早い」典型で、公式SDKはPython・TypeScript・Kotlin・C#・Java・Swiftに加え、コミュニティ製のRust実装（rmcp）も揃う。題材はどれも「都市名を渡すと天気を返すツール1つ」だけのサーバーで統一する。

Python SDKでの最小実装

Pythonでは FastMCP を使うと、関数にデコレータを付けるだけでツールになる。型ヒントとdocstringが、そのまま入力スキーマとツール説明に変換される。初学者はここから始めるのが最短だ。

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather")

@mcp.tool()
def get_forecast(city: str) -> str:
    """指定した都市の天気予報を返す"""
    return f"{city}の天気：晴れ、24℃"

if __name__ == "__main__":
    mcp.run()

pip install mcp の後、このファイルを実行すればstdioでサーバーが立ち上がる。複数ツールやリソース・プロンプトを足したい場合も、同じ要領でデコレータや登録呼び出しを増やすだけだ。

TypeScript SDKでの最小実装

TypeScriptでは高レベルAPIの McpServer を使う。ツールの入力スキーマはzodで宣言し、registerTool で登録、StdioServerTransport で起動するだけだ。

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "weather", version: "1.0.0" });

server.registerTool(
  "get_forecast",
  {
    title: "天気予報を取得",
    description: "指定した都市の天気予報を返す",
    inputSchema: { city: z.string().describe("都市名（例: Tokyo）") },
  },
  async ({ city }) => ({
    content: [{ type: "text", text: `${city}の天気：晴れ、24℃` }],
  })
);

const transport = new StdioServerTransport();
await server.connect(transport);

npm install @modelcontextprotocol/sdk zod で依存を入れ、TypeScriptをビルドすれば、もう立派なMCPサーバーだ。inputSchema に書いたdescriptionは、そのままAIがツールを使うかどうかの判断材料になる。ここを丁寧に書くほどAIの使い勝手が上がる。

Rustでの最小実装

パフォーマンスや配布のしやすさ（単一バイナリ）を重視するなら、公式が保守するRust SDK rmcp が選択肢になる。非同期ランタイムのtokio上で動き、マクロでツールを宣言する。

use rmcp::{tool, tool_router, ServerHandler, ServiceExt, transport::stdio};

#[derive(Clone)]
struct Weather;

#[tool_router]
impl Weather {
    #[tool(description = "指定した都市の天気予報を返す")]
    async fn get_forecast(&self, city: String) -> String {
        format!("{city}の天気：晴れ、24℃")
    }
}

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let service = Weather.serve(stdio()).await?;
    service.waiting().await?;
    Ok(())
}

cargo add rmcp tokio anyhow で依存を追加し、cargo run で起動する。ビルドすれば依存のない実行ファイルが1つできるので、配布や本番デプロイが楽なのがRust版の強みだ。3言語とも「ツールを宣言する→stdioで起動する」という骨格は変わらず、あとは言語の書き味の違いにすぎない。

動作確認とデバッグ

書いたサーバーは、公式のMCP Inspectorで単体テストできる。クライアントに繋ぐ前にInspectorで tools/list と tools/call を叩き、ツールが正しく見えるか・期待どおり応答するかを確認しておくと、後の統合がぐっと楽になる。

# ローカルのPythonサーバーをInspectorで検証
npx @modelcontextprotocol/inspector python server.py

MCPサーバーの設定【Claude Code / Cursor / VSCode / Continue / Cline】

「MCPサーバー 設定」でつまずくのは、クライアントごとに書き方が微妙に違うからだ。ただし発想は共通で、「コマンドか設定ファイルでサーバーの起動方法を教える」だけ。ローカルは command＋args（stdio）、リモートは url（HTTP）に対応する、と覚えれば応用が利く。主要5クライアントの設定を並べる。

Claude Code

Claude Codeは claude mcp add コマンドで登録する。ローカルのstdioサーバーと、リモートのStreamable HTTPサーバーで書式が変わる。

# ローカル（stdio）サーバーを登録：-- の後ろが起動コマンド
claude mcp add weather -- node /path/to/build/index.js

# リモート（Streamable HTTP）サーバーを登録
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

# 登録済みサーバーの一覧を確認
claude mcp list

プロジェクト単位で共有したい場合は、リポジトリ直下の .mcp.json に設定を書いてチームで共有する。Claude Code全体の使い方は Claude Code 使い方完全ガイド2026 にまとめている。

Cursor

Cursorはプロジェクト直下 .cursor/mcp.json（またはユーザー設定）にJSONで書く。多くのクライアントが共通で採用する mcpServers キー形式だ。

{
  "mcpServers": {
    "weather": {
      "command": "node",
      "args": ["/path/to/build/index.js"]
    },
    "sentry": {
      "url": "https://mcp.sentry.dev/mcp"
    }
  }
}

CursorのUI日本語化や初期設定でつまずく場合は Cursor日本語設定・初期設定ガイド を参照してほしい。

VS Code（Copilot Chat）

VS Codeはワークスペース直下 .vscode/mcp.json に書く。キーが mcpServers ではなく servers で、type を明示する点がCursorと異なる。

{
  "servers": {
    "weather": {
      "type": "stdio",
      "command": "node",
      "args": ["/path/to/build/index.js"]
    }
  }
}

Continue

Continue（VS Code / JetBrains拡張）は、YAMLの mcpServers ブロックで宣言する。アシスタント設定ファイル（config.yaml）に並べて書ける。

mcpServers:
  - name: weather
    command: node
    args:
      - /path/to/build/index.js

Cline

Cline（VS Code拡張）は拡張機能のMCP設定ファイル（cline_mcp_settings.json）に、Cursorと同じ mcpServers 形式で記述する。GUIの「MCP Servers」パネルからも追加できるため、JSONを直接触らずに設定しやすい。

主要クライアントの設定を一覧で比較すると次のとおりだ。

複数のクライアントを併用していても、同じMCPサーバーをそれぞれに登録すれば、どこからでも同じツールが使える。これがMCPの「一度作ればどこでも繋がる」価値が最も実感できる場面だ。

MCPサーバーのセキュリティ

MCPサーバーは「AIに外部操作の手段を与える」仕組みである以上、便利さと表裏一体でリスクも持ち込む。導入・自作のどちらでも、最低限の脅威モデルは理解しておきたい。主なリスクを整理すると次のようになる。

最大の論点は、間接プロンプトインジェクションだ。MCPサーバーが返すツール出力（Webページの内容、ファイル、検索結果など）の中に攻撃指示が紛れていると、それを読んだAIが意図しない操作を実行してしまう。利用者が善意で「このページを調べて」と頼んだだけでも攻撃が成立する点が厄介だ。仕組みと防御策は プロンプトインジェクションとは？攻撃手口・実例・防御策をLLM開発者向けに徹底解説｜OWASP LLM01 で詳述している。脅威モデルを図にすると次のとおりだ。

実際、公開されたMCPサーバーを狙い撃ちする走査はすでに観測されている。詳しくは 公開 MCP サーバが標的に｜AI 開発者を狙い撃つ走査を SANS ISC が観測 を参照してほしい。トランスポート実装の欠陥を突く例としては MCP脆弱性！STDIOトランスポートの設計欠陥で20万台のサーバーがRCEの危険に、通信ハイジャックによるトークン窃取は Claude CodeのMCP通信ハイジャックでOAuthトークンが窃取される攻撃、開発者を狙う供給網ワームは Shai-Hulud派生「Hades」がMCP開発者を標的に にまとめている。

脅威モデルの全体像・代表的リスク・対策ツールの俯瞰は AIセキュリティとは？LLM時代の脅威モデル・代表的リスク・OSS対策ツールを体系解説する入門ガイド にまとめている。防御の基本は「最小権限・出力検証・信頼できる提供元」の3点に集約される。便利さを取りに行くほど、この基本を外さないことが効いてくる。

MCPサーバーのトラブルシューティング10選

MCPサーバーの導入・自作でつまずきやすいポイントを、症状・原因・対処の3点で整理する。多くは「仕組みの理解が浅いまま設定だけ真似た」ときに起きる。エラーに出会ったら、まずこの表で当たりをつけてほしい。

特に多いのが「descriptionの軽視」と「stdioへのログ混入」だ。前者はMCPサーバーのツールがAIにとって「説明文で選ばれる」ことを忘れている状態、後者はstdioが通信路そのものだという理解が抜けている状態で起きる。tools/list で返る説明文こそがAIとの接点であり、stdioは人間向けログを流す場所ではない——この2点を押さえるだけで、トラブルの大半は避けられる。

もう一つ意識したいのは「動いた＝安全」ではないことだ。前章のとおりMCPサーバーは攻撃面でもある。検証環境で動いたサーバーをそのまま本番のエージェントに繋ぐ前に、権限の範囲と出力の信頼性を一度見直す習慣をつけたい。

MCPサーバーの将来展望

MCPは公開からわずか1年強で事実上の標準になったが、仕様もエコシステムもまだ動いている。今後の方向性を3つの軸で押さえておくと、投資判断を誤りにくい。

第一に、トランスポートと認可の成熟だ。初期はローカルstdioが中心だったが、Streamable HTTPとOAuthの整備により、SaaS各社が公式のリモートMCPサーバーを提供する流れが加速している。今後は「誰がどのツールを呼べるか」を制御する認可・監査の層が厚くなる見込みで、企業導入ではここが要件になる。本番運用の設計原則は Model Context Protocolで本番エージェントを構築｜Anthropic公式の設計原則と認証・最適化パターン が詳しい。

第二に、MCP Registryによる発見性の向上だ。サーバーが乱立するほど「どれが安全で保守されているか」を見極めるコストが上がる。公式レジストリはこの発見・検証を一元化する試みで、提供元の確認やバージョン管理が進めば、前章で触れたサプライチェーンリスクの低減にもつながる。

第三に、エージェント同士の連携だ。MCPが「AIと外部ツール」を繋ぐ規格として定着した先には、複数のAIエージェントが役割分担して協調する構図が見えてくる。MCPはその配線の一部として機能し続ける可能性が高い。エージェント設計の潮流は AIエージェントとは？仕組み・種類・代表的OSSフレームワークを初心者向けに解説【2026年版】 で追える。

まとめ

MCPサーバーとは、AIアプリにツール・リソース・プロンプトを標準化された方式で提供するプログラムであり、その背後にあるMCP（Model Context Protocol）は「AIのためのUSB-C」とも言える共通規格だ。3つの登場人物（ホスト・クライアント・サーバー）、2つの層（データ層・トランスポート層）、3つの基本要素（Tools・Resources・Prompts）を押さえれば、仕組みの大枠はつかめる。

一覧では公式7本と主要サードパーティ40本超を用途別に見た。おすすめは「回数の多い作業から1〜2個」が鉄則で、開発ならSerena、調査ならFetch/Firecrawl、自動化ならn8nが入口になる。作り方はPython・TypeScript・Rustのどれでもツール1つから始められ、設定はClaude Code・Cursor・VS Code・Continue・Clineでコマンドか設定ファイル数行で済む。一方で、AIに外部操作の手段を与える以上、間接プロンプトインジェクションや過剰な権限といったリスクと向き合う必要がある。「最小権限・出力検証・信頼できる提供元」の3原則を守りつつ、まずは小さなサーバーを1つ作って動かしてみることが、MCPを理解する最短ルートだ。

参照ソース

・Model Context Protocol 公式サイト（What is MCP / Architecture）：https://modelcontextprotocol.io
・公式リファレンスサーバー集 modelcontextprotocol/servers：https://github.com/modelcontextprotocol/servers
・MCP公式アーキテクチャ解説（Participants / Layers / Primitives）：https://modelcontextprotocol.io/docs/learn/architecture
・MCP公式ドキュメント（Connect to Local/Remote Servers・SDK一覧）：https://modelcontextprotocol.io/docs
・MCP Registry（サーバー発見の公式レジストリ）：https://github.com/modelcontextprotocol/registry