7月22日、Teng Liが「I lint-scanned 36 popular MCP servers. A third of them are failing your agent. · Teng Li」と題した記事を公開した。人気MCPサーバー36本をLintスキャンした結果、3分の1以上が実際のAIエージェントの動作を妨げていることが判明した——しかも問題を抱えているのはホビープロジェクトではなく、MongoDBやNotionといった大手の公式サーバーだ。

「仕様準拠」と「エージェントが使えるか」は別の話

MCP（Model Context Protocol）は、AIエージェントがツールを呼び出すための標準プロトコルだ。仕様はJSONスキーマやトランスポート層の設計を定めているが、「モデルが実際に正しいツールを選べるか」「引数を正しく埋められるか」については何も保証しない。

Teng Liは本業で大手テック企業のプロダクション向けAIエージェントにMCPコネクタを統合しており、その過程で「仕様準拠なのにモデルが誤ったツールを呼ぶ、引数を幻覚する、ツールを無視する」という問題を繰り返し目撃してきた。問題は常にプロトコル層ではなく、誰もLintしてこなかった部分——ツールの説明文、命名規則、スキーマ設計——にあった。

そこで彼が開発したのが mcpgrade だ。Lighthouseのようなスコアカード形式で、APIキー不要、1コマンドで結果が出る。

npx mcpgrade --stdio "npx -y your-mcp-server"

これを使って36本の人気MCPサーバーをスキャンした結果が、今回の記事の本題だ。

スキャン結果：3分の1がD/F評価

全スコア一覧はこちら。概要は以下のとおりだ。

優良（A評価）： brave-search、exa、google-maps、slack、perplexity-ask、@shopify/dev-mcp、figma-developer-mcp、tavily、elasticなど、36本中15本。

問題あり（D/F評価）：36本中11本。ホビープロジェクトではなく、大手の公式サーバーが並ぶ。

mcpgradeのスコアリングでは70未満がD以下（落第）に相当する。MongoDBの66、Notionの62、Airtableの69はいずれもこの基準を下回っており、「公式サーバー」であっても例外ではない。

なお、StripeとSupabaseはスキャン時にAPIキーや認証情報が必須のため、ダミー認証情報では接続自体が成立せず集計から除外された。両者はMCPサーバーとして注目度が高く、タイトルの「公式サーバー」文脈で名前が挙がりやすい存在だが、今回は品質評価の対象外となっている。

最大の問題：パラメータ説明文の欠如

D/F評価のサーバーに共通するのは、**descriptionsスコアがほぼゼロ**であることだ。支配的なルール違反は D004 — parameter has no description（パラメータに説明なし）の一点に集中している。

• firecrawl：134件のエラーのうち132件がパラメータ未記述。url、formats、jsonOptionsといったパラメータに名前と型しかなく、説明が一切ない
• todoist：110件
• MongoDBとAirtable：各66件

根本原因はほぼ全サーバーのソースコードに見える。zodやOpenAPIの定義からスキーマを自動生成する際に、誰も .describe() を書いていないのだ。型システムは url: string を知っている。しかしモデルが必要なのは「どのURLか、どのフォーマットか、どんな制約があるか」だ。スキーマジェネレータが、ツールにとって最も重要なシグナルを静かに削ぎ落としている。

Teng Liはこう断言する。「この記事から一つだけ持ち帰るなら：自分のサーバーを開いて、descriptionのないパラメータを数えて、直せ。エージェントの信頼性に対してこれ以上レバレッジの高い1時間はない。」

「仕様準拠」が高スコアを意味しない逆説

興味深い発見がある。アーカイブ済みのSlack公式サーバー（誰もメンテしていないコード）がA/97を記録した。かつて誰かがすべてのツールとパラメータを手で丁寧に記述したからだ。一方、現在も活発に開発が続く商用サーバーが、説明なしのパラメータを量産している。

また、カタログ規模と品質の関係については「小さいカタログが勝つ」という単純な話ではないことも示された。shrimp-task-manager は15ツールでA/96を記録しており、丁寧なドキュメント作成があればある程度の規模でも高品質を維持できる。ただし、ツールを追加するたびに書くべき説明文も増え、命名の衝突リスクも増す。規律はデフォルトではスケールしない。

実モデルで検証すると「拒否しない」が最も危険な失敗

静的スキャンの妥当性を検証するため、Teng Liは --eval オプションも実装した。実際のモデルに対してリアルなタスクを投げ、正しいツールを選べるかを測定する（1サーバーあたりわずか数セントの費用）。

結果：

• よく整備されたサーバーではツール選択精度100%。 firecrawlでは84%に低下し、ミスは静的ルールが指摘した命名衝突の箇所に集中した（extract↔scrape、agent_status↔check_crawl_statusなど）
• スコープ外のタスクを意図的に与えた場合、 小規模・整備済みカタログではモデルが100%正しく「できない」と拒否した。しかしfirecrawlの26ツールに対しては、50%の確率で「それらしいツール」を呼び出してしまった

後者が本番環境で意味するのは、「何もすべきでないときに何かをしてしまうエージェント」だ。Teng Liはこれを「おそらく最も危険な失敗モード」と表現している。

「良いサーバー」の条件

上位スコアのサーバーから導き出されたチェックリストをTeng Liは以下のようにまとめている。

• すべてのツール説明が「何をするか・いつ使うか・何を返すか」の3点を答えている
• すべてのパラメータに、フォーマットと例値を含む説明がある
• 固定値集合は enum で定義し、文章中に埋め込まない
• required は空の場合も明示的に宣言する
• 命名規則は1種類（動詞_目的語形式）、汎用的な動詞や類似した名前は避ける
• エラーメッセージは不足・不正なパラメータ名を明示し、モデルが1ターンで自己修正できるようにする

問題の可視化がエコシステムを動かす

この調査が示したのは、スコアの低さそのものだけではない。問題が数値として可視化されたとき、エコシステムがどれだけ速く動けるかという点だ。記事の執筆中に、context7が欠落パラメータの説明を全補完し、C評価からパーフェクトスコアに跳ね上がったという事例がすでに生じている。Lintスキャンという仕組みが存在するだけで、修正への動機と優先順位が生まれる——その実証例と言えるだろう。

詳細はI lint-scanned 36 popular MCP servers. A third of them are failing your agent. · Teng Liを参照していただきたい。