initialize と tools/list を投げて挙動を調査したnpx.cmd の扱いと UTF-8の文字化け が重要だったMCPは Model Context Protocol の略で、ざっくり言うと「AIアシスタントが外部ツールと会話するための共通規格」です。
たとえば、ファイル操作、Slack送信、Googleサービス連携、Stripe操作みたいな機能を、AIが安全に呼び出せるようにする仕組みだと思えばOKです。
この記事が面白いのは、そのMCP serverを “カタログやREADMEで眺める” のではなく、実際に起動して会話させてみた ところです。
ここがかなり良い。机上の空論じゃなくて、「現実にどう壊れているか」を見に行っている。こういう調査は、だいたい面白いです。
著者は npm に公開されている 922個のMCP server に対して、次の流れで自動テストを走らせました。
npx -y <package> でサーバーを起動initialize を送るtools/list を送る
tools/list は、MCPクライアントが「このサーバーは何ができるの？」を知るための正式な問い合わせです。
READMEを読んで推測するのではなく、プロトコルとしての“本当の機能一覧” を取ってきているわけです。これは筋がいい。
しかも並列8本、1サーバー120秒のタイムアウトで、全体は約25分。
かなり実用的な速度で回していて、「雑に触った」ではなく「きちんと計測した」という印象です。
ざっくりした成績はこうです。
つまり、半分以上はうまくいかなかった ということです。
ここだけ見ると「MCPってまだ荒れてるな…」という感想になりますが、実は失敗理由を掘るともっと面白いです。
著者の結論はかなり率直で、**“MCPそのものが悪いというより、npmパッケージとしての品質や起動時の設計が問題”** だと言っています。
これ、かなり重要だと思います。プロトコルが優秀でも、周辺実装が雑だと使えません。現場あるあるです。
最頻出の失敗はこれです。
[stderr] connecting to upstream...
[stderr] (no further output)
[timeout after 120s]
要するに、サーバーが立ち上がった直後に 外部APIや上流サービスへ接続 しにいって、その返答を待つうちに固まるパターンです。
著者はこの失敗だけで 261個、全体の28% を占めたと報告しています。
これはかなり痛い。
MCP server を呼ぶ側からすると、まず知りたいのは「このツールは何ができるか」なのに、起動時に認証や通信で詰まると、何も見えません。
著者は対策として、外部接続は最初の tool call まで遅らせる（lazy connect）べき だと述べています。
個人的にもこれはかなり納得感があります。初期化時は軽く、実作業の瞬間だけ本気、のほうがUXがいいです。
面白いのは、単に「失敗した」で終わらせていないところです。
著者は stderr、終了コード、JSON-RPCエラーを見て、失敗を15種類に分類しています。
主なものはこんな感じです。
initialize に返答しないnpx -y 自体が失敗main や bin の設定が壊れているtools/list で止まるここで特に重要なのが、認証情報不足のサーバーは「0ツール」ではない という指摘です。
READMEだけ見て「使えない」と判断すると、そのサーバーの本当の能力を見落とす。
つまり、**“見えない” と “存在しない” は違う** という話です。AI周辺ツールの世界では、この勘違いがかなり起きそうだと思います。
著者によると、needs_* 系、つまり認証情報や設定が足りずに止まるサーバーは 109個。
全体の 約12% にあたります。
これ、地味にすごい数字です。
カタログや自動収集の世界では、認証が必要なものはしばしば「ツールなし」と誤判定されます。けれど実際には、5個、12個、40個のツールを持っているのに、鍵がないと姿を見せない だけなんです。
この指摘は、MCP server の索引や検索サービスを作る人にとって重要でしょう。
READMEを読むだけでは不十分で、実際に適切な環境変数や認証を与えて試す設計 が必要になります。
この記事のもう一つの見どころは、Windows特有の罠 です。
地味だけど、現場ではめちゃくちゃ大事。
npx はそのまま spawn できないことがあるWindowsでは npx が実体として npx.cmd になっていることがあり、Node.js の child_process.spawn でそのまま呼ぶと失敗することがあります。
where npx で見つかるのに、spawn では ENOENT になる。これ、初見だとかなり腹が立つやつです。
著者は cmd /c npx -y <package> の形にする必要があると書いています。
WindowsでMCP clientを書いているなら、ここはほぼ必修科目でしょう。
Windowsの標準コードページはUTF-8ではないため、ツール説明に ウムラウト、ダッシュ、引用符 みたいな非ASCII文字があると、文字化けしてJSONパースに失敗することがあります。
著者は3個のサーバーでこの問題に遭遇したそうです。
もしUTF-8指定をしていなければ、誤って error 扱いになっていた可能性がある。
こういう「文字コードで死ぬ」問題、昔からあるのに今でも現役なのが本当に人間くさいです。
著者はかなり実務的なアドバイスも出しています。
初期化中にAPIへつなぎにいくと、ツール一覧取得が止まります。
lazy connect、つまり最初のツール呼び出しまで接続を待つ設計がよさそうです。
tools/list だけでも応答できる方が、クライアント側は扱いやすいです。
54個ものサーバーが「引数がないなら使い方を表示して終了」になっていたのは、かなりもったいない。
missing X と明示してくれるサーバーは分類しやすい一方、曖昧なエラーを出すものは needs_env_var に埋もれてしまいます。
これはユーザー体験の問題でもあります。エラーは親切に書いたほうがいい。ほんとに。
broken_install に分類された11個は、存在しないファイルを指していたり、main が壊れていたりしました。
これは完全に配布前チェック不足です。
npm公開って「置けば終わり」ではないんだな、と改めて思います。
著者はこの調査結果をデータセットとして公開しています。
automatelab/mcp-servers-tool-catalogAutomateLab-tech/mcp-tool-catalog
さらに、Pythonで読み込む例も載っています。
こういう再現可能な公開はかなり良いです。記事を読んで終わりではなく、自分でも追試できる のは強い。
正直、この調査はかなり好きです。
理由はシンプルで、「AI時代のツール」は、思想よりも運用で壊れる ことを見事に可視化しているからです。
MCPは新しい仕組みですが、失敗の中身を見ると、驚くほど昔ながらです。
つまり、技術の名前が新しくても、問題はわりと昔からある。
ここが面白いし、同時にちょっと切ないところでもあります。
一方で、こうして protocol-level に実際の挙動を測る ことで、MCPエコシステムの成熟度をかなり正確に見られるのはすごく価値があります。
READMEの良し悪しではなく、本当にクライアントが触れる状態か を測る。これは今後いろんな分野で真似されそうだと思います。
この記事が教えてくれるのは、MCP server の世界では「公開されている」ことと「実際に使える」ことは別だ、ということです。
922個のうち359個しかすぐ使えなかった、という数字はなかなか衝撃ですが、同時に改善の余地がはっきり見えたとも言えます。
特に重要なのは次の3つです。
MCP server を作る人にも、使う人にも、かなり実用的な記事だと思います。
「AIのためのツール連携」は華やかに見えて、実際は地道な配布・起動・設定の積み重ね。そこをちゃんと観測した、良い調査でした。