【12.4万サーバーを解析】MCPツールの98.5%には代わりがある。同じツールでも並べ方だけで合格率が最大12ポイント違う。入れる前に確認すべき4項目と探し場所6選

MCPサーバーを5個以上つないでいるなら、今すぐ読んでほしい。

MCPサーバーを並べたマーケットは、世界にいくつあるか。William & Maryの研究者らが10月4日にarXivへ投稿した論文「MCPacific」は、そのうち17か所の掲載を丸ごと集め、ソースコードまで降りて数え直した。

• マーケットの掲載は合計41万4,733件
• 重複と無効を除いた実体は12万4,267サーバー
• そのソースから静的に抜き出したツール定義は132万8,233個

そして、ツールを機能ごとに分類し直して出てきた答えが、これだ。

Alternatives are the norm: 98.5% of tools have at least one functionally comparable alternative, and 74.1% have at least 20.

あなたが入れたそのツールには、ほぼ確実に代わりがある。4本に3本は、代わりが20個以上ある。

問題は、代わりどうしの中身がそろっていないことだ。同じ機能のグループの中に、静的解析の警告が出るツールと出ないツールが混ざっている。同じ機能のペアの41%は、コードの複雑さに2.5倍を超える差がある。

そしてもう1つ。使えるツールはまったく同じまま、エージェントへの見せ方を変えただけで、合格率が最大12ポイント動いた。

結論から言うと

1. 新しいMCPサーバーを入れる前に、同じ機能の候補を3つ並べて、保守・警告・複雑さで選ぶこと。
論文が細かく調べた10グループでは、警告の出たツールが各グループの11.1〜40.0%を占めたが、どのグループにも警告ゼロの代わりがあった。

2. 同じツールでも、並べ方で合格率が変わる。ランダムなツールを50個足すと、平らな一覧は61%から54%に落ち、階層で絞る方式は66%だった。
GPT-5.6-LunaでMCP-Atlasの100タスクを解かせた結果で、30個足した条件ではどちらも64%と差はゼロだった。

3. ただし、4つに1つの機能には代わりがない。しかも、あなたが毎日使っているサーバーは調査の外かもしれない。
分類された機能の24.80%はツールが1つしか見つからず、ソース非公開のサーバーとリモート専用のサーバーはそもそも数えられていない。

図: 候補ツールにランダムなツールを足したときの合格率（GPT-5.6-Luna、MCP-Atlasの100タスク）。論文の表6をもとに筆者が作図

数字はMCPacificの論文（arXiv:2610.05319。v1が2026年10月4日、v2が10月8日。いずれもUTC）による。論文はマーケットからデータを集めた日付を書いていないので、掲載数はすべて論文の取得時点の値だ。各マーケットの現在の表示件数と公式レジストリの検索結果は、筆者が2026年10月19日に確かめた。警告の数字はSemgrepが出した「潜在的な問題」で、脆弱性として確認されたものではない。エージェントの実験は100タスクで、採点役のGPT-5.4は被験モデルの1つでもある。筆者は論文の実験を再現していない。

数字で見るMCPエコシステム

項目	値
調べたマーケット	17か所（米国4、カナダ1、欧州3、中国6、地域の記載なし3）
掲載（生データ → 有効）	414,733件 → 368,754件
重複を除いた実体	124,267サーバー
抜き出したツール定義	1,328,233個（7言語、110,482プロジェクト）
機能の分類	18領域、葉の機能58,915個
開発以外の領域のツール	85%（ソフトウェア開発は15.0%）
代わりが1つ以上あるツール	98.5%（20個以上は74.1%）
代わりがない機能	24.80%
Semgrepの警告が出たツール	66,912個中1,044個（1.56%）
複雑さが2.5倍を超えて違う同機能ペア	41.03%（86,387ペア中）

ここに、論文の数字から筆者が計算した2つを足しておく。

• 有効な掲載368,754件を、ユニークな124,267サーバーで割ると約2.97。1つのサーバーが、平均でほぼ3か所のマーケットに載っている計算だ。
• 中国の6マーケット（mcpmarket.cn、MCP World、SCNet MCP、AIBase MCP、ModelScope、Tencent MCP）の有効な掲載を足すと206,035件で、有効な掲載全体の55.9%を占める。1か所で最大なのもmcpmarket.cnの134,905件で、2位のGlama（57,696件）の2倍を超える。

ここまでは「MCPサーバーは数えきれないほどある」という話。面白いのはその先だ。

同じ機能なのに、中身はこれだけ違う

12.4万サーバーをどう数えたか

MCPacificのパイプラインは5段だ。

1. 17マーケットの掲載を集め、アクセスできない・空・実行できるソースのないリポジトリを除く（414,733件 → 368,754件）
2. リポジトリのURLを正規化し、同じリポジトリを指す掲載を1つにまとめる（→ 124,267サーバー）
3. Python、TypeScript、JavaScript、Go、Rust、Java、C#の7言語について、構文木からツール登録のパターンを探し、各ツールの入口関数まで解決する（110,482プロジェクト、1,328,233ツール）
4. 5,000サーバー（75,365ツール）の開発用データで、GPT-5.6-Lunaに機能の分類木を設計させる。第1階層は18領域で、葉までの深さの中央値は5〜6
5. 残りのツールを、OpenAIのtext-embedding-3-smallで分類木の葉に割り当てる（対象1,056,806個のうち90.19%が葉に到達）

同じ葉にいるツールどうしが「代わり」だ。サンプル検査では、ツールの割り当ての87.00%が正しく、同じ葉のペアの85.00%が機能的に比較できると判定された。

分類してみると、MCPの重心はもう開発ツールにない。

MCP has outgrown software development: 85% of tools serve other domains.

葉に割り当てられた953,172ツールのうち、ソフトウェア開発は143,202個（15.0%）で最大の領域だ。それでもインフラ（11.3%）とビジネス（11.0%）がすぐ後ろに続き、金融、メディア、医療、教育にも広がっている。

警告・複雑さ・保守。同じ機能で3つの差が出る

観点	論文の測り方	結果
警告	7言語向けのSemgrepルール755個を、各ツールの入口関数にかける	66,912個中1,044個（1.56%）に計1,874件。89.22%が入力検証
同じ機能の中の差	警告の種類がすべてそろうように選んだ10グループ（79ツール）を精査	警告ありが各グループの11.1〜40.0%。全グループに警告ゼロの代わりがあった
複雑さ	Lizardで入口関数のCCN（循環的複雑度）を測り、同じ葉・同じ言語・別リポジトリのペアを比べる	86,387ペアの41.03%で2.5倍を超える差
保守	アーカイブされておらず、取得前180日以内にpushがあるか	60.38%のグループで、動いている候補と止まった候補が同居

警告の内訳は、入力検証89.22%、通信の保護2.56%、リソース管理1.33%、認証情報の露出1.23%、アクセス制御0.16%、認証0.11%、その他5.39%。ほぼ入力検証だ。

論文が挙げる具体例は、クロマチンのアクセシビリティ解析（ゲノム解析の一種）のグループだ。3つのツールが入力検証で警告を受け、そのうち2つは、検証していない入力をそのままサブプロセスの呼び出しに渡していた。それでも同じ機能の中に、警告の出ないツールがあった。論文の言い方はこうだ。

in every examined group, users could choose an alert-free tool with the same functionality.

選び方ひとつで、警告は避けられた。

1.56%という全体の数字は小さく見える。だが、警告の種類がそろうように選んだ10グループの中では、警告ありのツールが最大で4割を占めていた。全体の平均が低いことと、自分が選んだ1本が安全なことは別の話だ。

代わりがない24.80%の機能

一方で、分類された機能の24.80%は、ツールが1つしか見つからなかった（論文本文の件数表記は葉の総数と同じ58,915になっており、割合から逆算すると約1万4,600個。件数のほうは誤記とみられる）。論文が挙げる例は、暗号の証明（Cryptographic Proofs）や発音辞書の管理だ。

意外なのは、その1本を支えるリポジトリのほうが元気なことだ。90日以内にpushがあった割合は47.50%（代わりがある機能では39.26%）、組織が持つリポジトリの割合は18.83%（同14.61%）。論文は、代わりがないからといってリポジトリの支えが弱いわけではない、と結論づけている。ちなみに、スター数の中央値は2（同1）だった。

MCPサーバーのリポジトリは、スター1〜2が当たり前の世界だ。

並べ方だけで、合格率が最大12ポイント動いた

論文の最後の実験（RQ4）は、この分類木が実際のエージェントの役に立つかを測っている。

• ベンチマークはMCP-Atlas。実在する36のMCPサーバーと220のツールを使う1,000タスクのベンチマークで、答えが満たすべき事実（claim）をどれだけ満たしたかで採点する
• そのうち公開されている100タスクを使う。1タスクあたりの候補ツールは平均15.37個（最少7、最多30）
• 比べるのは見せ方だけだ。候補を平らな一覧のまま渡す方式と、分類木からそのタスク用の部分木を切り出し、根から関係しそうな枝だけをたどって選ばせる方式（MCPacific）。使えるツールは両方とも同じ
• 指標はPass@0.75（claimの75%以上を満たしたタスクの割合）で、採点役はGPT-5.4

MCPacific側の選び方を、論文はこう説明している。

Starting at the root, the model retains clearly or potentially relevant branches and expands only those branches.

擬似コードにすると、こうなる。

# 論文の説明を筆者が擬似コードにしたもの（未実行）
def reach_tools(task, node, llm):
    if node.is_leaf():
        # 葉に着いたら、そこのツールを候補にする
        return node.tools
    # 明らかに、またはたぶん関係する枝だけ残す
    kept = llm.keep_relevant(task, node.children)
    reached = []
    for child in kept:
        # 残した枝だけを下りる
        reached += reach_tools(task, child, llm)
    return reached

# 使えるツールだけで作った部分木を、根からたどる
subtree = taxonomy.subtree_for(enabled_tools)
candidates = reach_tools(task, subtree.root, llm)
# たどり着いたツールから実行計画を組む
plan = llm.choose_tool_plan(task, candidates)

まず、元の候補のままの結果。

モデル	平らな一覧	階層で絞る	差
GPT-5.6-Luna	61%	70%	+9
GPT-5.6-Terra	67%	68%	+1
GPT-5.5	66%	68%	+2
GPT-5.4	58%	66%	+8

4モデルすべてで上がったが、幅は1〜9ポイントとばらつく。

では、ここにランダムなツールを30個、50個と混ぜたらどうなるか。

先に予想してから、下の表を見てほしい。

あなたの予想もコメントで教えてほしい。

候補（GPT-5.6-Luna）	平らな一覧	階層で絞る	差
元の候補（平均15.37個）	61%	70%	+9
ランダムに30個追加（平均約45個）	64%	64%	0
ランダムに50個追加（平均約65個）	54%	66%	+12

50個足すと、平らな一覧は61%から54%へ7ポイント落ちた。階層で絞る方式も70%から66%に下がったが、落ち幅は4ポイントで止まり、差は12ポイントに開いた。論文はこれをFinding 10として、こうまとめている。

MCPacific is more robust when the candidate-tool space becomes crowded.

本当にそうか？ 30個足した条件では、平らな一覧はむしろ61%から64%に上がり、両者は64%で並んだ。満たしたclaimの平均（mean claim coverage）で見ると、この条件では階層で絞る方式のほうが0.67ポイント低い。100タスクの実験では1タスクが1ポイントにあたるので、数ポイントの差は数タスクの出入りで動く。

ここで筆者の単純計算を1つ。論文のデータでは、1プロジェクトあたりのツールは平均約12.0個（1,328,233 ÷ 110,482）だ。MCPサーバーを5個つなぐと約60個になり、50個追加の条件（平均約65個）に近づく。実際につなぐツールはランダムではないので、あくまでおおまかな目安だ。

正直に言えば、この実験は100タスクでばらつきの報告がなく、足したツールの出どころも書かれておらず、分類木を設計したモデルと最も伸びたモデルがどちらもGPT-5.6-Lunaなので、12ポイントは「傾向」として読むのが正しい。

入れる前に確認すべき4項目

1. エージェントに見えているツールを数える

つないでいるサーバーごとに、MCP InspectorのCLIドキュメントにある方法でツール一覧を取る（Node.js 22.19.0以上が必要）。

# stdioで動くサーバー
npx @modelcontextprotocol/inspector --cli node build/index.js --method tools/list --format json

# リモートのサーバー（Streamable HTTP）
npx @modelcontextprotocol/inspector --cli --transport http --server-url https://example.com/mcp --method tools/list --format json

全サーバーの合計が、論文の元の候補（平均15.37個）の3倍、4倍になっていないかを見ること。

2. 同じ機能の代わりを探す

公式MCP Registryは、APIドキュメントにあるsearch（サーバー名の部分一致）とversion=latestで、同じ機能の候補を一覧できる。

# 名前に filesystem を含むサーバーの最新版だけを取る
curl -s 'https://registry.modelcontextprotocol.io/v0.1/servers?search=filesystem&version=latest&limit=20'

続きは、レスポンスのmetadata.nextCursorをcursorパラメータに渡してページを送る。筆者が10月19日にlimit=5で試したときは、com.pulsemcp/remote-filesystemやio.github.bytedance/mcp-server-filesystemなど、作者の違う5件が返り、まだ続きがあった。

3. 保守を比べる

候補のリポジトリが分かったら、GitHub CLIのgh apiで、最終pushとアーカイブ状態を取る。論文の「保守されている」の定義（アーカイブされておらず、180日以内にpushがある）を、そのまま自分で当てはめられる。

gh api repos/OWNER/REPO --jq '{pushed_at, archived, stargazers_count}'

スター数は参考程度でいい。前の章で見たとおり、中央値が1〜2の世界だ。

4. 警告と複雑さを比べる

論文と同じ道具が、手元でも使える。警告はSemgrep（CLIリファレンス）、複雑さはLizardだ。

# 候補のリポジトリを手元に置いてから
semgrep scan --config p/default --json ./candidate-a > candidate-a.json

pip install lizard
lizard ./candidate-a

論文が使ったのはSemgrepのルール755個で、p/defaultとは同じではない。レジストリからルールを取ると、既定では匿名の利用統計が送られる（--metrics offで止められる）。Lizardは関数ごとにNLOC（コメントを除く行数）とCCNを出すので、ツールの入口関数どうしを並べて比べること。

知らないと損する5つの罠

罠1：マーケットの掲載数を「人気」だと思う

論文の17マーケットの掲載は414,733件あったが、ユニークなサーバーは124,267で、約3割しかない。マーケット別に見ると、有効性チェックを通った掲載はSmitheryで10,338件中2,906件（28.1%）、チェコのAgentForgeでは15,049件中57件（0.38%）だった。論文で最大のmcpmarket.cn（生データ137,327件）も、10月19日に筆者が見たトップページの見出しは「40,000+」だった。数え方がそろっていない。

マーケットの「○万件」は、同じサーバーの重複と、中身を確かめられない掲載を含んだ数字だ。

対策：比べる単位を、掲載ではなくリポジトリにすること。候補のURLを突き合わせ、同じものが別の名前で並んでいないか確かめる。

罠2：公式レジストリで「github」と検索する

公式レジストリのsearchは、ドキュメントによるとこういう仕様だ。

`search` - Case-insensitive substring search on server names (e.g., `filesystem`)

一方で、GitHubアカウントで名前空間を確認したサーバーは、名前がio.github.ユーザー名/で始まる（README）。筆者が10月19日にsearch=github&version=latest&limit=100で取ると、100件が返り、そのうち90件はio.github.で始まる名前だった。io.github.0xChron/polymarket-mcpやio.github.1nzpainter/painting-lessonsのように、GitHubと関係のないサーバーが大半だ。

筆者が取った結果は名前順に並んでいて、1ページ目はio.github.207studio/chalkieboard-icloud-mcpで終わった。GitHub向けのサーバーを探したいのに、名前空間が同じだけのサーバーに埋もれてしまう。

対策：searchには機能を表す語（filesystemやpostgresなど）を入れ、githubのように名前空間と重なる語は避けること。ドキュメント自身も、高度な検索や絞り込みはサブレジストリに任せると書いている。

罠3：「警告ゼロ」を「安全」と読む

論文自身が、警告を確定した問題ではなく、潜在的な問題として扱っている。

we interpret these alerts as potential, rather than confirmed, issues

しかもSemgrepも複雑さの計測も、各ツールの入口関数だけを見ている。警告の集計に使えた測定は66,912ツール分で、ソース非公開のサーバーとリモート専用のサーバーは最初から対象外だ。

あなたが使っているホスト型のリモートサーバーについては、この物差しでは何も分からない。

対策：警告は「候補どうしを比べる材料」として使うこと。ソースが見えないリモートサーバーは、要求する権限（OAuthのスコープなど）と提供元で判断する。

罠4：「同じカテゴリ」なら差し替えられると思う

同じ葉のペアのうち、機能的に比較できると判定されたのは85.00%だった。裏を返せば、15%は同じ棚にいても中身が違う。ツールの割り当て自体も、正しかったのはサンプルの87.00%だ。

カテゴリだけを見て乗り換えると、引数の形が違ってワークフローが止まりかねない。

対策：乗り換える前に、両方のtools/listを出して、入力スキーマ（引数の名前・型・必須項目）を並べて比べること。

罠5：「12ポイント」を自分の環境の数字だと思う

30個足した条件では差がゼロで、元の候補でもGPT-5.6-Terraは1ポイントしか伸びなかった。採点役のGPT-5.4が被験モデルを兼ねている点は、論文も妥当性への脅威として認めている。さらに筆者が付け加えるなら、分類木を設計したのは、最も伸びたGPT-5.6-Lunaそのものだ。

12ポイントを当てにして自分のツール構成を作り直しても、同じ伸びが出るとは限らない。

対策：ツールを絞る前と後で、自分の代表的なタスクを同じ数だけ流し、成功した数を比べること。

MCPサーバーの探し場所6選

探し場所	論文の取得時（生 → 有効）	有効の割合	10月19日の表示件数	1件ごとに見える手がかり
公式MCP Registry	調査の対象外	なし	総数の表示なし（プレビュー版）	名前空間の所有確認、status、公開・更新日時（API）
Glama	61,213 → 57,696	94.3%	104,869件	ライセンス・品質・保守のA〜D評価、最終更新日時
MCP Market	30,136 → 28,409	94.3%	49,888件	カテゴリ、提供元
Smithery	10,338 → 2,906	28.1%	27,365件以上	利用回数
PulseMCP	22,021 → 21,355	97.0%	21,678件	公式・リファレンス・コミュニティの区別、推定週間訪問者数、公開日
mcp.so	17,858 → 15,922	89.2%	総数の表示なし	追加日、Featuredの印

有効の割合は、有効÷生データで筆者が計算した。10月19日の件数は各サイトの表示で、数え方はサイトごとに違う。

表から読み取れること：

• Glamaの表示件数は、論文の取得時の約1.7倍。 論文は取得日を書いていないので、増えたペースまでは分からない。マーケットの件数は、いつの数字かとセットで読むこと。
• Smitheryは、論文の有効性チェックを通った掲載が28.1%しかない。 リポジトリをたどって実行できるソースを確かめられた掲載が、3割に満たなかったということだ。
• 公式MCP Registryは、論文の17か所に入っていない。 理由は論文に書かれていない。READMEが説明している確認は名前空間の所有で、セキュリティの審査については何も書かれていない。
• 保守を評価として出していたのは、6か所のうちGlamaだけだった。 どこで見つけても、最後は前の章の3と4、つまり手元のチェックが要る。

候補が決まったら、エージェントに見せるツールそのものを減らす。OpenAI Agents SDKなら、ドキュメントのTool filteringにこういう例がある（筆者は実行していない）。

from pathlib import Path
from agents.mcp import MCPServerStdio, create_static_tool_filter

samples_dir = Path("/path/to/files")
filesystem_server = MCPServerStdio(
    params={
        "command": "npx",
        "args": ["-y", "@modelcontextprotocol/server-filesystem", str(samples_dir)],
    },
    tool_filter=create_static_tool_filter(allowed_tool_names=["read_file", "write_file"]),
)

許可リストとブロックリストは併用でき、許可リストを先に当ててから、ブロックしたツールを除く。OpenAIのResponsesモデルに限れば、defer_loadingとToolSearchToolでツールを後から読み込ませる方法もある。どちらも論文の「階層で絞る」とは別のやり方で、エージェントが一度に見る候補の数そのものを減らす。

教訓：MCPサーバーは「入れる」ものではなく「選ぶ」もの

✗ 「公式レジストリに載っている＝審査済み」 → READMEにある確認は名前空間の所有だけ
✗ 「掲載が多いほど選択肢が多い」 → 41.5万件の掲載で、実体は12.4万サーバー
✗ 「同じ機能ならどれを選んでも同じ」 → 同じ機能のペアの41%で、複雑さが2.5倍を超えて違う
✗ 「ツールは多いほどエージェントは賢い」 → ランダムに50個足すと、平らな一覧は61%→54%
✗ 「代わりはいつでも見つかる」 → 機能の24.80%は、ツールが1つしかない

MCPが広がったこと自体は、いいニュースだ。ツールの85%が開発以外の領域にあり、98.5%に代わりがある。もう「対応するサーバーがあるかどうか」で悩む段階ではない。

ただ、選択肢が増えるほど、選ばない人だけが損をする。同じ機能の中に、警告のあるものとないもの、動いているものと止まったものが並んでいて、候補が混み合えばエージェントの合格率も揺れる。今日、つないでいるMCPサーバーを1つ選び、同じ機能の候補を3つ並べて、最終pushと警告の数を比べてみてほしい。

参考リンク

Understanding the Hierarchical Structure and Functional Landscape of the Model Context Protocol Ecosystem（MCPacific）- arXiv:2610.05319

同論文のHTML版（v2）- arXiv

MCP-Atlas: A Large-Scale Benchmark for Tool-Use Competency with Real MCP Servers - arXiv:2602.00933

MCP Registry（README）- GitHub

Official Registry API - modelcontextprotocol/registry

Generic Registry API - modelcontextprotocol/registry

MCP Inspector（README）- GitHub

MCP Inspector CLI smoke testing - GitHub

CLI reference - Semgrep Docs

Lizard（README）- GitHub

gh api - GitHub CLI Manual

Model context protocol (MCP) - OpenAI Agents SDK

Open-Source MCP Servers - Glama

MCP Servers - PulseMCP

Smithery

MCP Market

mcp.so

---

この記事が役に立ったら、いいねと保存を！ MCPサーバーをマーケットから片っ端から入れている同僚にも、シェアしてあげてほしい。

コメントで教えてほしい。

• あなたのエージェントには今、ツールが何個見えている？ 15個以内？ 50個以上？
• MCPサーバーを選ぶとき、一番見ているのは？ 公式かどうか、スター数、最終更新、それとも口コミ？
• 「並べ方で12ポイント」、信じる？ それとも誤差だと思う？