「他にどんなMCPがあるんですか」と聞かれることが増えた
以前Playwright MCP入門の記事を書きました。AIにブラウザを触らせてテストを書いてもらう、という内容です。あの記事を読んだ方から一番よく聞かれるようになったのが「MCPって便利なのはわかったんですが、他にどんなMCPサーバーがあるんですか」という質問でした。
これ、実は私自身もPlaywright MCPを触るまでは同じ疑問を持っていました。MCPというとブラウザ操作の文脈で紹介されることが多いのですが、それはMCPという仕組みが持つ用途の1つに過ぎません。今回は2026年時点の主要どころを、数字の裏取りをしたうえで整理してみます。
まず規模感を正直に書いておく
MCPサーバーがどのくらいの規模になっているのか、数字を調べてみました。ただ正直に言うと、媒体によって数字の粒度がかなり揺れます。公式のMCPレジストリAPIでは2026年5月時点で「latest（最新版のみ）」のサーバーが9,652件、バージョン違いを含めた全レコードでは28,959件とカウントされていました。一方でAnthropicが2025年12月に出したエコシステム更新では「公開されているアクティブなMCPサーバーは1万件超」という言い方をしています。数え方が違うので単純比較はできないのですが、少なくとも「公開だけで1万件前後」という規模感は複数の情報源で一致していました。
SDK（Python/TypeScript）の月間ダウンロード数は約9,700万と紹介されている記事が複数あります。私が調べた範囲ではこの数字の一次ソースまでは辿れなかったので、「〜と言われている」程度の裏取りにとどめておきます。
もう1つ確実な事実として、2025年12月にAnthropicはMCPをLinux Foundation傘下のAgentic AI Foundation（AAIF）に寄贈しています。AnthropicとBlock、OpenAIが共同で立ち上げた組織で、他社も参加しているとのことです。1社が仕様を握っている状態から、業界横断の標準に切り替わったタイミングが、ちょうど去年の年末だったことになります。
「定番サーバー」の顔ぶれは去年から結構入れ替わっている
filesystem・GitHub・Postgres・Slack・Notionあたりが定番、とよく紹介されているのを見かけます。ここも実際に公式リポジトリを確認してみたところ、正直、思っていたより状況が変わっていました。
Anthropicが最初に用意した参照実装はmodelcontextprotocol/serversというリポジトリに全部まとまっていたのですが、2025年のうちに元々あった20個のうち13個がservers-archivedというリポジトリに移されています。GitHub・Slack・Postgres・Google Drive・Brave Search・Sentryなどがそこに含まれていました。「参照実装としての役目は終えた」という位置づけのようです。
じゃあ今それらを使いたい人はどうするかというと、各サービス自身が公式のMCPサーバーを持つ形に移行しています。SlackはSlack自身がmcp.slack.comでホスト型のMCPサーバーを提供していますし、Notionもmcp.notion.comのホスト型に加えてmakenotion/notion-mcp-serverというオープンソース版を公開しています。GitHubも自社のgithub/github-mcp-serverを公式に持っています。Postgresについては元の参照実装はアーカイブ済みで、コミュニティ製のサーバーを選ぶ形になっているようです（この辺りは私も網羅的に検証できていないので、実務で使う前に最新のREADMEを確認することをおすすめします）。
一方でfilesystem（ローカルファイルの読み書き）は今も現役の参照実装として維持されています。Fetch・Git・Memory・Sequential Thinking・Timeあたりと合わせて、MCPの仕様策定チーム自身がメンテナンスを続けている少数精鋭のサーバー群、という位置づけです。
つまり「定番」の中身は、2026年時点だと大きく2種類に分かれます。1つはAnthropicが今も面倒を見ているシンプルな参照実装（filesystemなど）。もう1つは各サービスベンダーが自社で持つようになった業務系サーバー（GitHub・Slack・Notion・Postgres系）です。どちらも「MCPサーバー」とひとまとめに紹介されがちですが、メンテナンス元も更新頻度もかなり違う、というのが調べてみての実感でした。
Playwright MCPはこの中でどこに位置するのか
ここでようやく本題です。Playwright MCPはブラウザを操作するための専用サーバーで、Microsoftが自社のPlaywrightプロジェクトの一部として持っています。位置づけとしては後者、つまりベンダー自身が持つ業務系サーバーのグループに入ります。以前の記事で書いたとおり、Playwright 1.62からは本体に同梱されるようになっていて、GitHubやNotionのように独立した会社の製品というより、Playwrightという1つのツールに組み込まれた機能という位置づけに近くなっています。
ここが最初に整理できていないと混乱しやすいポイントだと思っています。「AIにブラウザを触らせる」という体験だけを見ると、MCPそのものがブラウザ操作の技術のように感じてしまいますが、実際にはMCPという共通のプロトコルの上に、ブラウザ操作用のサーバー（Playwright MCP）・ファイル操作用のサーバー（filesystem）・チャット連携用のサーバー（Slack）などがそれぞれ乗っている、という構造です。Playwright MCPはその中の「ブラウザ操作」という1ジャンルを担当しているだけで、開発フロー全体をカバーしているわけではありません。
実際に複数登録するとどうなるか
試しにfilesystemとPlaywright MCPを同時に登録した.mcp.jsonを見てみましょう。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["playwright", "mcp"]
},
"filesystem": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/project"]
}
}
}
Claude Codeがこのファイルを読み込むと、両方のサーバーをツールとして使えるようになります。「ローカルのテストコードを書き換えて、そのままブラウザで動作確認する」という一連の作業を、エージェントが1つの会話の中で両方のツールを行き来しながらこなしてくれます。1つのサーバーだけを見ていると気付きにくいのですが、複数のMCPサーバーを組み合わせて初めて「開発フロー全体をAIに任せる」という発想に近づく、というのが触ってみての感覚です。
増やすほど便利、だけではない
ここは正直に注意しておきたいのですが、MCPサーバーを増やせば増やすほど便利になるかというと、そう単純でもありません。以前の記事で書いたとおり、ブラウザ操作系のMCPはページ内のテキストをそのままエージェントに読み込ませる構造上、プロンプトインジェクションのリスクを抱えています。同じことはSlackやNotionのように外部からテキストが流れ込んでくるMCPサーバーにも当てはまります。信頼できないテキストが読み込まれる経路がある以上、「便利だから全部繋いでおく」という発想はリスクも一緒に増やしている、と考えておいたほうが安全です。
もう1つ、実務で地味に効いてくるのがトークンの消費です。登録するMCPサーバーが増えるほど、ツール定義がコンテキストに乗る分だけ会話のトークンを食います。Agent Teamsの記事でも触れましたが、私はpro契約でtoken節約を意識しているので、常時使わないMCPサーバーはプロジェクトごとに.mcp.jsonを分けて、必要なときだけ有効にするようにしています。全部入れておいて損はない、というものでもありません。
結局どれから入れればいいのか
個人的な結論としては、まず自分の開発フローで「AIに触らせたい実物」を1つ決めて、そこから対応するMCPサーバーを1個だけ入れるのがいいと思っています。ブラウザ操作をAIに任せたいならPlaywright MCP、ローカルのファイルをまとめて触らせたいならfilesystem、というように用途から逆算する形です。いきなり「定番だから」という理由でGitHub・Slack・Notion・Postgresを一気に繋ぐと、増えたツールをエージェントがうまく使い分けられなかったり、前述のトークン消費が想像以上に膨らんだりします。
私自身、最初にPlaywright MCPを触ったときは「これがMCPの全部」だと思い込んでいました。実際には、ブラウザという1ジャンルの入口を触っていただけで、MCPというプロトコル自体はもっと広い範囲をカバーしています。1つのサーバーで感動した後は、その感動を他の作業にも広げられないか、と考えてみるとMCPの使い方の幅がぐっと広がるはずです。
まとめ
2026年時点で、MCPサーバーは公開だけで1万件前後、Linux Foundation傘下のAAIFが仕様を管理する規模の標準になっています。ただし「定番」と紹介されるサーバーの中身は、Anthropicが今も面倒を見ている少数の参照実装と、GitHub・Slack・Notionのように各社が自社で持つようになった業務系サーバーに分かれていて、去年から顔ぶれが結構入れ替わっていました。Playwright MCPはこの中の「ブラウザ操作」という1ジャンルを担当しているだけで、開発フロー全体をカバーしているわけではありません。
これから2個目・3個目のMCPサーバーを検討している方は、「定番だから」ではなく「自分のどの作業をAIに任せたいか」から逆算して選んでみてください。プロンプトインジェクションとトークン消費の話も、増やす前に一度目を通しておくことをおすすめします。
コメント