ツール一覧をエージェントにとって読みやすくするもの
LLM がどれだけ簡単に正しいツールを選べるかという観点で、数千の MCP ツール群を採点しました。同じ四つの間違いが何度も現れます。
エージェントがあなたのドキュメントを見ることはありません。見えるのはツール名の一覧、一行の説明、そしてパラメータの JSON スキーマだけです。ブリーフィングはそれで全部です。そこから正しいツールが分からなければ、エージェントは間違ったものを選ぶか、本来必要のない質問をユーザーに投げます。
私たちはカタログ内の読み取り可能なツール群をすべて評価し、点数をつけています。数千件を読むと、失敗には型が見えてきます。
1. 役割が重なるツール
同じ依頼にどちらも答えられそうなツールが二つあること。これが最も高くつく間違いです。エージェントには決め手がありません。search_docs と find_document があるなら、どちらかが「もう一方ではない何をするのか」を明示すべきです。
2. 意味のないパラメータ
型が string の query という名前のパラメータは、エージェントに何も伝えません。そこに入るのはキーワードか、質問か、ID か。大文字小文字を区別するのか。空ならどうなるのか。それが属するのはスキーマであって README ではありません。
3. 曖昧なツールに例がない
ほとんどのツールに例は要りません。しかし自由形式のオブジェクトやフィルタ式、ドメイン固有の識別子を受け取るツールには必ず必要です。私たちの評価では「利用例がない」は最も頻出する弱点のひとつであり、ほぼ常にサーバー全体ではなく特定の一つのツールを指しています。
4. 黙っている制約
レート制限、最大件数、実行タイムアウト、呼び出しに費用がかかるかどうか。制限を知らないエージェントは必ずそこにぶつかります。高得点のサーバーは、こうしたことを説明文にはっきり書いています。
要点
- 異なる役割を示す異なる名前。
- 各パラメータは「何を入れるか」という言葉で説明する。
- 人間なら質問するであろうツールには例を添える。
- 制約は、エージェントが実際に読む場所に書く。
どれもツールを増やすことを求めていません。多くはむしろ、より良く説明された、より少ないツールを求めています。
サーバーの評価を見る