人気MCPサーバー36件をエージェントの使いやすさで評価した結果、3分の1がDまたはF評価だった

私は36の人気のMCPサーバーをリントスキャンしました。そのうち3分の1はエージェントが利用できていません。 2026-07-21 Agents MCPEngineering MCPサーバーは仕様に100%準拠していても、エージェントが利用できない場合があります。Model Context Protocolの仕様では、ツールの転送方法（JSON-RPCフレーミング、機能ネゴシエーション、スキーマ形状）が定められています。しかし、モデルが実際に提供されたものを利用できるかどうか、つまり、カタログから正しいツールを選択できるか、引数を正しく埋められるか、あるいはリクエストごとに8kトークンを費やしてスキーマを解析するかについては何も述べていません。 私は、本番環境のAIエージェントにファーストパーティおよびサードパーティのMCPコネクタを統合する仕事をしており、同じ失敗が繰り返し発生するのを目にしてきました。それは、すべてのコンプライアンスチェックをパスするサーバーでも、モデルが間違ったツールを呼び出したり、引数を幻覚したり、ツールを完全に無視したりするというものです。問題はプロトコルレイヤーにはなく、誰もリントしない部分、つまり説明、命名、スキーマ設計にありました。 そこで私は、MCPサーバーのためのLighthouseスタイルのスコアカードであるmcpgradeを作成しました。コマンドは1つ、APIキー不要、数秒でレポートが生成されます。 npx mcpgrade --stdio "npx -y your-mcp-server" そして、それを36の人気のサーバーに適用しました。結果はあまり良くありませんでした。 結果 ソート可能な完全なテーブルはこちらです: https://tengli.dev/mcp-leaderboard.html。 簡単なバージョン（静的分析、時点のスナップショット。サーバー名の横に（archived）とあるものは、メンテナンスされていないリファレンス実装ですが、広くインストールされコピーされているため含めました）： クラスのトップ（A）：brave-search (archived), exa, google-maps (archived), slack (archived), perplexity-ask, @shopify/dev-mcp, @apify/actors-mcp-server, airbnb, figma-developer-mcp, tavily, gitlab (archived), elastic, shrimp-task-manager、その他 — 36件中15件。 クラスのボトム（D/F）、11件 — しかもこれらは趣味のプロジェクトではありません：MongoDBの公式サーバー（66、66エラー）、Notionの公式サーバー（62）、Airtable（69、66エラー）、todoist-mcp-server（67、110エラー）、GitHubのアーカイブされたリファレンスサーバー（67、44エラー）、そして最下位のfirecrawl-mcp（57、134エラー）。 さらに2つのサーバー（Stripe、Supabase）はダミー認証情報ではスキャンできず、採点から除外されました。 発見1：エコシステムにはドキュメント化されていないパラメータの蔓延 D/F評価のほぼすべてのサーバーは、説明スコアがゼロである一方、スキーマ、命名、トークンスコアは良好です。支配的なルールはD004 — パラメータに説明がない、です。firecrawl: 134エラーのうち132はドキュメント化されていないパラメータです。url, formats, jsonOptions — モデルは名前と型しか得られません。todoist: 110。MongoDBとAirtable: それぞれ66。 根本原因は、ほぼすべてのソースコードに見られます。スキーマはzodまたはOpenAPI定義から生成されており、誰も.describe()を追加していません。型システムはurl: stringを認識します。モデルは、どのURLが、どのような形式で、どのような制約で使われるかを知る必要があります。あなたのスキーマジェネレーターは、ツールが持つ最も重要なシグナルを静かに剥ぎ取っています。 この記事から一つだけ持ち帰るとしたら、サーバーを開いて、説明のないパラメータの数を数え、それを修正してください。それはエージェントの信頼性にかける最もレバレッジの高い1時間です。 発見2：カタログのサイズではなく、ドキュメント化の規律が重要 — しかしサイズは規律を難しくする このデータに対する私の最初の分析では、「小さなカタログが勝つ」ということが示唆されました。95以上のスコアを持つサーバーのほとんどはツールが少なく、24〜26個のツールを持つサーバーはD/Fに集中していました。しかし、shrimp-task-managerは15個のツールでA/96を獲得しました — 丁寧にドキュメント化され、タイトに命名され、すべての説明が明確でした。したがって、正直なバージョンは、適切にドキュメント化された大きなカタログも可能ですが、それはまれです。追加するツールごとに、書くべき説明が1つ増え、衝突する可能性のある名前が1つ増え、タイトに保つべきスキーマが1つ増えます。規律はデフォルトではスケールしません。（サイズはどちらにしても負担になります。完全なカタログはすべてのリクエストにシリアライズされます。） 発見3：コンプライアンスとユーザビリティは異なる軸 最も更新されているサーバーが、最も使いやすいサーバーではありません。アーカイブされたSlackリファレンスサーバー — 誰もメンテナンスしていないコード — は、誰かがかつてすべてのツールとすべてのパラメータを手作業でドキュメント化したため、A/97を獲得しました。一方、積極的に開発されているいくつかの商用サーバーは、説明のないパラメータをそのまま出荷しています。エージェントのユーザビリティは、エンジニアリングの問題というよりも、ライティングの問題です。コンプライアンスチェッカーはそれを測定できません。それがmcpgradeが埋めるギャップです。（希望の持てる反論が1つあります。この記事を書いている間に、context7はパラメータの説明不足をすべて修正した新しいバージョンをリリースし、Cから完璧な静的スコアにジャンプしました。ギャップが可視化されれば、エコシステムは速く動くことができます。） 発見4：静的スコアを実際のモデルでチェックした。恐ろしい数字は拒否率だ。 静的リントは代理であり、私は--evalを構築しました。これは、現実的な単一ステップのタスク（各タスクはすべての必須パラメータの具体的な値を含んでいます）を合成し、モデルに完全なカタログを表示し、正しいツールを選択し、有効な引数を埋めるかどうかを測定します。キャリブレーションの詳細と方法論: docs/eval-calibration.md。コスト: 小規模モデルでサーバーあたり数セント。注目すべき2つの結果：静的な発見はライブの混乱を予測します。適切にドキュメント化されたサーバーでは、ツールの選択精度は100%でした。firecrawlでは84%に低下しました — そして、ミスは静的ルールがフラグを立てる命名の衝突に正確に着地しています: extract↔scrape, agent_status↔check_crawl_status, feedback↔search_feedback。 大きなあいまいなカタログは拒否を壊します。意図的に範囲外のタスクを与えると、モデルは小規模で適切にドキュメント化されたカタログでは100%の時間正しく拒否しましたが、firecrawlの26個のあいまいなツールでは50%の時間しか拒否しませんでした。半分の時間、「もっともらしい」ツールを見つけて呼び出しました。本番環境では、それは何もしないはずのときに何かをするエージェントです — おそらく最も危険な障害モードです。 「良い」とは何か トップスコアラーからのチェックリスト： 各ツールの説明は3つの質問に答える必要があります：何をするか、いつ使うか、何が返されるか。 各パラメータには、形式と1つの例値の説明が必要です。 固定値セットは、プロセではなく列挙型に配置されます。 必須は明示的に宣言されます — たとえそれが空であっても。 1つの命名規則、verb_objectスタイル、一般的な動詞なし、ニアツイン名なし。 エラーは、モデルが1ターンで自己修正できるように、不足している/無効なパラメータの名前を付けます。 あなたのサーバーで試してみてください npx mcpgrade --stdio "node ./my-server.js" # ローカル stdio npx mcpgrade https://my-server.example/mcp # ストリーム可能なHTTP npx mcpgrade <target> --fail-on error # CIゲート npx mcpgrade <target> --eval # ライブモデルテスト (BYOキー; 任意のOpenAI互換エンドポイントで動作) 24のルールがあり、それぞれに具体的な修正と、問題で議論することを歓迎する理由があります — ルールセットは意図的に意見が分かれるものであり、私は公開で議論したいと思っています。（mcp-lintやその他のMCP QAツールとの違い — サイドバイサイド出力付き: docs/comparison.md。） 上記のサーバーのいずれかをメンテナンスしていて、スコアを修正した場合は、再スキャン用の問題をオープンしてください — 喜んで再実行し、テーブルを更新します。あなたのサーバーへのPRは、私のルールセットとの議論よりも優れています。 私は大手テクノロジー企業で本番環境のAIエージェント統合を構築しています。mcpgradeは個人的なプロジェクトであり、数十のMCPコネクタを統合した際の経験から得られたものです。ランク付けされたサーバーとの提携はありません。← すべての執筆