MCP Reference Servers と Model Context Protocol の比較
どちらもプロトコル / 相互運用に分類しています。数値はGitHub APIから取得したもので、評価は本サイトによるものです。
MCP Reference Serversファイルシステム・git・データベース等のMCPリファレンス実装公式MIT
Model Context ProtocolMCPの仕様そのもの。スキーマと、各SDKが実装する規定公式Apache-2.0 / CC-BY-4.0基本情報の比較
| 基本情報の比較 | MCP Reference Servers | Model Context Protocol |
|---|---|---|
| ライセンス | MIT | Apache-2.0 / CC-BY-4.0 |
| 言語 | TypeScript, Python | TypeScript |
| 提供形態 | ローカル実行 / セルフホスト | — |
| 成熟度 | 安定 | 安定 |
| スター | 89.6k | 9k |
| 直近7日間のスター増加数 | +14 ★ | — |
| フォーク | 11.5k | 1.7k |
| オープンIssue | 512 | 175 |
| 最終コミット | 2026年8月10日 | 2026年8月14日 |
| 開発状況 | 活発 | 活発 |
それぞれの位置づけ
MCP Reference Servers
Model Context Protocolを理解する最も確実な方法は、正しく実装されたサーバーを読むことであり、この集合がそれにあたります。実用的なコネクタとしても、自作する際に写経する雛形としても機能します。
詳細を見る →Model Context Protocol
MCPのクライアントとサーバーが準拠を測られる対象で、TypeScriptで定義したスキーマとそのJSON Schema版、そして適合実装が満たすべき要件を記した文章から成ります。2025年12月にAnthropicがLinux Foundation傘下のAgentic AI Foundationへ寄贈しており、ライセンスは移行の途中です。新規のコードと仕様本文はApache-2.0、ドキュメントはCC-BY-4.0、再ライセンスに同意していない寄稿分はMITのまま残っています。SDKの挙動が腑に落ちないときに読む場所であって、これ自体は依存関係ではなく文書のため、実装には各言語のSDKが別途必要です。
詳細を見る →できること
MCP Reference Servers
- ファイルとgitリポジトリを開放 — Filesystemサーバーは許可するディレクトリを引数で受け取り、Gitサーバーは--repositoryで対象を指定するため、範囲を限定したうえで読み取りや検索、履歴参照をクライアントに渡せます。
- インストールせずに起動 — TypeScript実装はnpx -y @modelcontextprotocol/server-memory、Python実装はuvx mcp-server-gitで直接起動でき、クライアント側はmcpServersに数行追記するだけです（Windowsではnpxをcmd /cで包む必要があります）。
- 永続メモリとWeb取得を足す — Memoryサーバーはセッションをまたぐ記憶を知識グラフとして保持し、FetchはWebページをLLM向けのテキストに変換、Timeはタイムゾーン変換を担当します。
- 自作クライアントの検証に使う — Everythingサーバーはprompts・resources・toolsをまとめて公開するリファレンス兼テスト用サーバーで、クライアント実装が3種類すべてを正しく扱えるか確認できます。
- 本番用サーバーは別で探す — ここにあるのはsteering groupが維持する7個のリファレンス実装だけで、READMEも本番向けではなく教育目的の例だと明記しています。公開済みのサーバーはMCP Registry、旧GitHubやSlack、PostgreSQL、SQLiteの実装はservers-archivedにあります。
Model Context Protocol
- 要約ではなくスキーマを読む — プロトコルは
schema/<revision>/schema.tsにTypeScriptで定義され、それを取り込めない処理系向けにJSON Schema版も公開されています。メッセージがどのフィールドを持つかという問いに対する正解は、各SDKのドキュメントではなくこのリポジトリ内のファイルです。 - 日付形式の改訂番号を把握する — 改訂番号は
YYYY-MM-DD形式の文字列で、後方互換性を壊す変更が入ったときにだけ進みます。互換性を保つ改善はバージョンを動かさずに反映されます。現行の改訂は2026-07-28で、2025-11-25以前は初期化時のハンドシェイクでバージョンを決める世代にあたります。 - セッション単位ではなくリクエスト単位で折衝する — 2026-07-28以降、バージョンは全リクエストの
_meta内にio.modelcontextprotocol/protocolVersionとして載り、Streamable HTTPではMCP-Protocol-Versionヘッダにも入ります。サーバーはリクエストごとに個別に受理・拒否し、拒否時は対応バージョンを列挙したUnsupportedProtocolVersionErrorを返します。対応バージョン、機能、識別情報を1往復でまとめて取得するserver/discoverも必須のRPCとして用意されています。 - コア機能を待たずに拡張を選ぶ — Tasksは長時間かかる処理に、状態の問い合わせと途中入力を伴う永続的なハンドルを与えます。MCP Appsは会話の中にグラフやフォーム、動画プレーヤーを直接描画します。認可まわりには、機械間認証と組織による集中管理の2つの拡張があります。拡張は既定で無効で、クライアントは各リクエストの
io.modelcontextprotocol/clientCapabilitiesで、サーバーはserver/discoverの応答で対応を宣言します。両端が対応して初めて使えます。 - 安全性の強制をプロトコルに期待しない — 仕様書自身が、MCPはプロトコルの層でセキュリティ原則を強制できないと明記しています。ツールの注釈は、サーバーが信頼できる場合を除いて信頼できないものとして扱うべきだとされ、同意の取得はホスト側の責任です。どの利用者がどのツールを呼べるかは、実装するか、ゲートウェイに任せるかのどちらかになります。
- 動くコードは別リポジトリにある — このリポジトリにあるのは仕様とドキュメントだけです。リファレンス実装のサーバー群、コミュニティ運営のレジストリ、Python・TypeScript・Go・C#・Rust・Java・Kotlin・PHP・Swift・Rubyの公式SDKは、いずれも同じ組織の別リポジトリで、リリース時期もそれぞれ独立しています。新しい改訂への対応は改訂の公開より後になるため、実際にどの改訂で話せるかは採用するSDK次第です。