「MCPサーバーとは何か」を一言でいえば、AIアプリケーションに対してツール・データ・定型プロンプトを標準化された方式で提供するプログラムだ。Model Context Protocol（MCP）はAnthropicが2024年11月に公開したオープン標準で、Claude CodeやCursorといったAIツールが外部システムと繋がるための共通規格になっている。本記事ではMCPサーバーの仕組み・アーキテクチャ・代表例・自作手順・導入方法・セキュリティまでを2026年6月時点の公式仕様ベースで一気通貫に解説する。

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

30秒で理解する

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

この記事の要点
  • ・MCPサーバーとは：AIアプリにツール・リソース・プロンプトを提供するプログラム。MCP（Model Context Protocol）という公式オープン標準に従う。
  • ・登場人物は3つ：ホスト（AIアプリ本体）／クライアント（接続を維持する部品）／サーバー（機能を提供する側）。
  • ・中身はJSON-RPC 2.0：初期化でお互いの能力を交換し、`tools/list` で発見、`tools/call` で実行する。
  • ・3つの基本要素：Tools（実行できる関数）／Resources（読み取るデータ）／Prompts（定型テンプレート）。
  • ・2つのトランスポート：ローカル向けstdioと、リモート向けStreamable HTTP。
  • ・自作は数十行から：TypeScriptの`McpServer`やPythonの`FastMCP`でツール1つから始められる。

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

MCPサーバーとは何か

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

Anthropicが2024年11月にMCPを公開して以降、対応の輪は急速に広がった。2026年6月時点で、Claude Code・Claude Desktop・Cursor・Cline・Windsurf・VS Code（Copilot Chat）など主要な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対応は標準装備になりつつある。GitHub Copilotがネイティブアプリ化して提供形態を刷新した動きは GitHub Copilotがネイティブアプリ化、デフォルトモデルもPolarisへ——Build 2026の主戦場 にまとめた。MCPサーバーは、こうした各社のAI戦略を横断して繋ぐ「共通配線」として機能している。

アーキテクチャ

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

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

MCPの3つの登場人物
・MCP Host（ホスト）：Claude CodeやVS CodeなどのAIアプリ本体。複数のクライアントを束ねて管理する。
・MCP Client（クライアント）：ホストの中に作られる部品。1つのサーバーと1対1の専用接続を維持する。
・MCP Server（サーバー）：ツールやデータを提供するプログラム。ローカルでもリモートでも動く。

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

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

flowchart LR subgraph HOST[MCP Host（AIアプリ）] C1[MCP Client 1] C2[MCP Client 2] C3[MCP Client 3] end C1 ---|専用接続 / stdio| S1[MCP Server A
ローカル：ファイルシステム] C2 ---|専用接続 / stdio| S2[MCP Server B
ローカル：データベース] C3 ---|専用接続 / HTTP| S3[MCP Server C
リモート：Sentry等] S1 --> R1[ローカルファイル] S2 --> R2[(DB)] S3 --> R3[外部SaaS / API]

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

MCPの2層構造
  • ・データ層（Data layer）：JSON-RPC 2.0ベースのプロトコル本体。ライフサイクル管理（初期化・能力交換）と、Tools/Resources/Promptsなどの基本要素を定義する。内側の層。
  • ・トランスポート層（Transport layer）：実際の通信路。接続の確立・メッセージの区切り・認証を担う。stdioとStreamable HTTPの2方式がある。外側の層。

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

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

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

基本要素 役割 主なメソッド 具体例
Tools（ツール） AIが呼び出して実行する関数 tools/list / tools/call ファイル操作、API呼び出し、DBクエリ
Resources（リソース） AIに読ませる文脈データ resources/list / resources/read ファイル内容、DBレコード、API応答
Prompts（プロンプト） 対話を組み立てる定型テンプレート prompts/list / prompts/get システムプロンプト、few-shot例

加えて、サーバー側だけでなくクライアント側が提供できる要素もある。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の仕組みを図解で理解する2026年版 でさらに掘り下げている。

代表的なMCPサーバー一覧

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

公式リファレンスサーバー（modelcontextprotocol/servers）
・Filesystem：アクセス制御付きのファイル操作。MCP入門で最初に触る定番。
・Git：リポジトリの読み取り・検索・操作。
・Fetch：Webコンテンツの取得とテキスト変換。
・Memory：ナレッジグラフ型の永続メモリ。会話をまたいで記憶を保持する。
・Sequential Thinking：思考を段階に分けて問題を解く補助。
・Time：時刻とタイムゾーンの変換。
・Everything：Tools/Resources/Promptsを網羅したテスト用サーバー。クライアント開発の検証に使う。

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

カテゴリ 代表的なサーバー 主な用途
ファイル / OS Filesystem、macOS Automator ローカルファイル操作、デスクトップ自動化
データベース PostgreSQL、SQLite系、各種DBアダプタ スキーマ参照、クエリ実行
検索 / Web Fetch、各種Web検索サーバー Web取得、検索結果の文脈投入
コミュニケーション Slack、LINE Bot系 メッセージ送受信、通知連携
開発ツール Git、GitHub連携、Sentry、CI/CD連携 リポジトリ操作、エラー監視、運用連携
業務 / 分析 BI・分析系、会計・財務データ系 レポート生成、データ分析の自動化

サーバーを選ぶときは、提供元が確認できること・必要な権限が過剰でないこと・トランスポート（ローカルか リモートか）が自分の用途に合うことの3点を見る。当サイトでも個別のMCPサーバーを多数取り上げているので、用途が決まっている場合はカテゴリ別の解説記事も併せて参照してほしい。

「サーバー一覧」を鵜呑みにしない
MCPエコシステムは拡大が速く、リファレンスから外れた・名前が変わった・保守が止まった、という変化が頻繁に起きる。古いまとめ記事のリンクが切れていることも多い。導入前に必ず公式リポジトリやMCP Registryで現状を確認するのが安全だ。

自作MCPサーバーの最小実装

MCPサーバーは「読むより作るほうが早い」典型だ。公式SDKはTypeScript・Python・Kotlin・C#・Java・Swiftなど複数言語で提供されており、ここでは利用者が多いTypeScriptとPythonで最小サンプルを示す。題材は「都市名を渡すと天気を返すツール1つ」だけのサーバーにする。

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の使い勝手が上がる。

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版と中身は等価で、どちらの言語でも「ツールを宣言する→起動する」という骨格は変わらない。複数ツールやリソース・プロンプトを足したい場合も、同じ要領でデコレータや登録呼び出しを増やすだけだ。

動作確認とデバッグ

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

自作の基本ステップ
  • ・SDKを導入し、サーバーに名前とバージョンを与える。
  • ・ツールを宣言する（名前・説明・入力スキーマ・処理本体）。説明文がAIの判断材料になる。
  • ・stdioトランスポートで起動する。
  • ・MCP Inspectorで単体検証してから、クライアントに登録する。

本記事の最小実装はあくまで骨格だ。ファイル操作・DB連携・外部API呼び出しといった実用パターンや、エラー処理・認証・本番運用まで踏み込んだ手順は MCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアル で実コード付きに解説している。まず本記事で全体像をつかみ、実装に進む段階で作り方ガイドへ移ると迷いが少ない。

Claude Code / Cursor / Cline での導入

作った（あるいは既存の）MCPサーバーは、各クライアントに登録して初めて使えるようになる。登録方法はクライアントごとに少しずつ異なるが、「コマンド or 設定ファイルでサーバーの起動方法を教える」という発想は共通だ。

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

登録後はClaude Codeがツールを自動認識し、必要に応じて呼び出す。プロジェクト単位で共有したい場合は、リポジトリ直下の .mcp.json に設定を書いてチームで共有する方法もある。

Cursor / Cline / VS Code

CursorやCline、VS CodeのCopilot ChatはJSON設定ファイルでサーバーを登録する。多くのクライアントが mcpServers というキーの下に、サーバー名・起動コマンド・引数を並べる共通フォーマットを採用している。

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

Cursorはプロジェクト直下 .cursor/mcp.json またはユーザー設定、Clineは拡張機能の設定ファイル、VS CodeはワークスペースやユーザーのMCP設定にこの形式で記述する。command＋args がローカルstdioサーバー、url がリモートサーバーに対応する点はおおむね共通だ。

導入時の確認ポイント
・絶対パス：ローカルサーバーの起動コマンドは絶対パスで書くと事故が少ない。
・環境変数：APIキーなどは設定ファイル内の env で渡し、ソースに直書きしない。
・スコープ：自分専用ならユーザー設定、チーム共有ならプロジェクト直下の設定ファイルに置く。
・再起動：設定変更後はクライアントの再読み込みでサーバーが認識される。

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

セキュリティ

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

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

MCPサーバー特有の3つの注意点
・過剰な権限：ファイル全削除やメール送信など強い操作を持つツールは、本当に必要な範囲に絞る。AIは与えられた権限を文脈次第で使ってしまう。
・信頼できない提供元：出所不明のサーバーは、ツール説明文に悪意を仕込む「ツールポイズニング」のリスクがある。提供元と中身を確認してから入れる。
・出力の無条件信頼：サーバーの応答をAIがそのまま指示として扱わないよう、信頼境界を分け、重要操作には人間の承認を挟む。

これらはMCPに限った話ではなく、AIエージェント全般の脅威と地続きだ。脅威モデルの全体像・代表的リスク・対策ツールの俯瞰は AIセキュリティとは？LLM時代の脅威モデル・代表的リスク・OSS対策ツールを体系解説する入門ガイド にまとめている。リモートMCPサーバーを使う場合は、認証トークンやセッションの扱いも重要になる。トークン窃取は単体の脆弱性ではなく、セッション・推論・課金まで含めて多層で防ぐべき問題であり、その考え方は トークン窃取を多層で止める——セッション・AI推論・課金まで含めた防御パターン が参考になる。

防御の基本は「最小権限・出力検証・信頼できる提供元」の3点に集約される。リモートサーバーへの接続ではOAuthなど標準の認証を使い、ローカルサーバーでも環境変数や設定ファイルでのキー管理を徹底する。便利さを取りに行くほど、この基本を外さないことが効いてくる。

よくある落とし穴

MCPサーバーの導入・自作でつまずきやすいポイントを、原因とあわせて整理する。多くは「仕組みの理解が浅いまま設定だけ真似た」ときに起きる。

つまずきポイントと対処
  • ・ツールが認識されない：起動コマンドのパス誤り・ビルド漏れ・設定後の再起動忘れが大半。まずMCP Inspectorで単体起動を確認する。
  • ・AIがツールを使ってくれない：ツールのdescriptionが曖昧だとAIが選ばない。「いつ・何に使うか」を具体的に書く。
  • ・stdioとHTTPの取り違え：ローカル実行ならstdio、リモートURLならStreamable HTTP。トランスポートが用途と合っていないと繋がらない。
  • ・権限不足 / 過剰：Filesystem系は許可ディレクトリの指定が必要。逆に広すぎる許可は事故のもと。
  • ・プロトコルバージョン不一致：クライアントとサーバーのSDKが古いと能力交換で弾かれる。両方を更新する。
  • ・キーの直書き：APIキーをソースや設定にハードコードして漏洩。環境変数で渡す。

特に多いのが「descriptionの軽視」だ。MCPサーバーのツールは、AIがdescriptionを読んで使うかどうかを判断する。人間向けのコメントではなく、AIに向けた仕様書だと考えて書くと、ツールが正しく呼ばれるようになる。tools/list で返る説明文こそがAIとの接点である、という意識を持ちたい。

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

FAQ（よくある質問）

MCPサーバーとMCPは何が違うのですか？
MCP（Model Context Protocol）は通信規格そのもの、MCPサーバーはその規格に従ってツールやデータを提供する具体的なプログラムです。HTTPという規格に対するWebサーバー、という関係に近いと考えるとわかりやすいです。
MCPサーバーを使うのにプログラミングは必要ですか？
既存のMCPサーバーを「使うだけ」なら、設定ファイルへの登録ができればプログラミングは不要です。一方、独自のツールを「自作する」場合はTypeScriptやPythonでの簡単な実装が必要になりますが、最小構成なら数十行で書けます。
MCPサーバーはどの言語で書くのが良いですか？
公式SDKが充実しているTypeScriptとPythonが入門の定番です。既存プロジェクトの言語に合わせるのが基本で、Kotlin・C#・Java・Swiftなどの公式SDKもあります。最小実装の手軽さではPythonのFastMCPが扱いやすいです。
ローカルサーバーとリモートサーバーはどう使い分けますか？
手元のファイルやローカルツールを操作するならstdioのローカルサーバー、SaaSやチームで共有する機能を提供するならStreamable HTTPのリモートサーバーが向きます。リモートはOAuthなどの認証に対応できる点も選定理由になります。
MCPサーバーは無料で使えますか？
公式リファレンスサーバーやOSSのMCPサーバーは無料で使えます。ただしサーバーが裏で呼び出す外部API（検索・SaaSなど）に料金が発生する場合があるため、接続先のコストは別途確認が必要です。
1つのAIアプリに複数のMCPサーバーを繋げますか？
繋げます。ホストはサーバーごとにクライアントを生成し、それぞれと専用接続を結びます。ファイル操作・DB・検索など複数サーバーを同時に登録し、AIが状況に応じて使い分ける構成が一般的です。
自作したMCPサーバーを公開・共有するには？
GitHubでソースを公開し、公式のMCP Registryに登録することで他のユーザーが発見できるようになります。チーム内共有ならリポジトリ直下の設定ファイル（.mcp.json など）に起動設定を入れて配布する方法が手軽です。

まとめ

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

自作はTypeScriptの McpServer やPythonの FastMCP を使えばツール1つから始められ、Claude Code・Cursor・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