7月4日、ToolDirectory.AIが「The state of MCP servers in 2026」と題した記事を公開した。この記事では、2026年時点でMCPサーバーがAIエージェントの標準接続手段として定着した現状と、実際に使えるサーバーを見極めるための基準について詳しく紹介されている。以下に、その内容を紹介する。
「MCPが勝った」は既定事実。問題は「何に繋ぐか」だ
Model Context Protocol（MCP）は、Anthropicが2024年末にオープンソース化したプロトコルだ。AIエージェントが外部ツールやデータにアクセスする際、ツールごとに個別実装を作る必要がなくなり、共通インターフェース一つで済む、という仕組みである。
2026年時点でMCPの普及はほぼ確定した。OpenAIが2025年末にChatGPTへのMCPクライアント対応を実装し、Googleも2026年中頃にGemini向けのマネージドリモートMCPサーバーを提供開始した。 AnthropicとOpenAI、Google、Microsoftが同一プロトコルを支持する状況となり、事実上の標準が成立した形だ。
では今、何が問題か。サーバーの数は約2万（Glamaレジストリ単体での索引数）、MCPのSDKダウンロード数は月間約9,700万回に達している。 しかしこの数字は「プロトコルが普及した」という事実を示すだけであり、「何を使うべきか」については何も教えてくれない。
ノイズと実用の境界線：ファーストパーティかどうか
記事が繰り返し強調するのが「ファーストパーティ対コミュニティ」という区別だ。
- ファーストパーティ：製品の開発チーム自身がビルド・メンテナンスするサーバー。認証が適切に実装され、製品の変更に追従し、単一のコントリビューターが離脱しても消えない。
- コミュニティ製ラッパー：誰かが公開APIをラップして作ったもの。ベースのAPIが変わると静かに壊れ、クレデンシャルの扱いが不適切なケースもある。
2万件のサーバーのうち多くは後者——週末プロジェクト、そのフォーク、もはや動いていないデモ——だというのが記事の見立てだ。実際に本番で使えるものは「公式のファーストパーティサーバーを持つ実製品」の数に限られ、これは2万という数とは大きくかけ離れている。
実際に公式サーバーを持つ製品の地図
ToolDirectory.AIが「ベンダーの公式ドキュメントまたはリポジトリで確認済み」として列挙しているカテゴリを以下に整理する。
| カテゴリ | 該当製品（例） |
|---|---|
| Webスクレイピング・データ | Firecrawl, Bright Data, Apify |
| ブラウザ自動化 | Browserbase, Browserless, Steel, Stagehand |
| Web検索 | Exa, Tavily |
| DB・エージェントメモリ | MongoDB Atlas Vector Search, Redis, Mem0, Zep, Databricks |
| プロジェクト管理 | Linear, Asana, Jira, Notion, Monday.com, Airtable, Attio |
| デザイン・サイト構築 | Figma Make, Canva, Webflow |
| コード・DevOps | Netlify, Daytona, Replicate, Hugging Face, Context7, Retool |
| 自動化・iPaaS | Zapier, Pipedream, Make.com, n8n, Workato, Composio |
| 音声・オーディオ | Vapi, ElevenLabs |
この分類で見えてくるのは、製品が二つの陣営に分かれているという点だ。
第一の陣営は、エージェント向けインフラとして最初から設計されたもの（Firecrawl、Browserbase、Exa、Mem0など）。これらにとってMCPサーバーは玄関口そのものであり、それを提供するのは自明だ。
第二の陣営が記事の言う「本当のシグナル」だ。Linear、Notion、Atlassian（Jira）、Canva、MongoDB、Monday.comといった既存のSaaS企業が公式サーバーを追加した。記事はこう述べる——「時価総額100億ドル規模の業務プラットフォームがMCPサーバーを出荷したとき、MCPは開発者の好奇心の対象ではなく、真剣なソフトウェアの必要条件になった」。
選定基準：使えるサーバーを見極める4つの確認事項
記事はサーバー選びにあたって具体的なチェックリストを提示している。
ファーストパーティか確認する。 ベンダー自身のサイトやリポジトリにドキュメントが存在するか。著名な製品のコミュニティ製ラッパーより、小さくてもメンテされたファーストパーティサーバーの方が信頼できる。
認証方式を確認する。 本番グレードのサーバーはAPIキーまたはOAuthをサポートする。設定ファイルに長期トークンを貼り付けるような設計のものは避けるべきだ。2026年のトレンドはOAuthとスコープ付き権限を使ったリモートホスト型サーバーで、アクセス取り消しが部分的に行える。
メンテナンス状況を確認する。 企業のロードマップに紐づいたサーバーは製品変更に追従する。個人コントリビューターに依存しているサーバーはそうでない。古くなったサーバーは「サーバーがない」より悪い——エージェントが検知できない形で壊れるからだ。
必要な機能が揃っているか確認する。 ブランド名ではなく、そのサーバーが実際に必要なアクション（テーブルの読み取り、スクレイプの実行、ビルドのデプロイなど）を提供しているかを確認する。
「プランビング」はサーバーではない
Smithery、Glama、mcp.so、MCPTotalといったレジストリやゲートウェイも2026年に活発だが、記事はこれらをサーバーとは明確に区別する。「電話帳であって、そこに載っている事業者ではない」という表現が端的だ。レジストリに接続しても仕事はできない。レジストリを使って実際に必要なサーバーを探し、そのサーバーに繋ぐ。この二層を混同すると「数万件」という数字が一人歩きする。
今後の焦点
記事は2026年後半に向けて三点を挙げている。
- 標準化の成熟：認証（OAuthとIAMの監査ログなど）とリモートホスティングの信頼性を上げること。Googleの取り組みはその方向の先例だ。
- 発見性と信頼：数万のサーバーが存在する状況で、「本物で、メンテされていて、クレデンシャルを渡せるもの」を見つけるのはキュレーションの問題になる。
- 二つの数字の乖離：コミュニティラッパーの総数は増え続ける一方、実際に依存できるファーストパーティサーバーの数は緩やかにしか増えない。2026年の「MCPの実態」を表すのは後者の数字だ。
詳細はThe state of MCP servers in 2026を参照していただきたい。
