mcpmetricsmcpmetrics
← 記事一覧
·4 分で読めます

ツール一覧をエージェントにとって読みやすくするもの

LLM がどれだけ簡単に正しいツールを選べるかという観点で、数千の MCP ツール群を採点しました。同じ四つの間違いが何度も現れます。

エージェントがあなたのドキュメントを見ることはありません。見えるのはツール名の一覧、一行の説明、そしてパラメータの JSON スキーマだけです。ブリーフィングはそれで全部です。そこから正しいツールが分からなければ、エージェントは間違ったものを選ぶか、本来必要のない質問をユーザーに投げます。

私たちはカタログ内の読み取り可能なツール群をすべて評価し、点数をつけています。数千件を読むと、失敗には型が見えてきます。

1. 役割が重なるツール

同じ依頼にどちらも答えられそうなツールが二つあること。これが最も高くつく間違いです。エージェントには決め手がありません。search_docs と find_document があるなら、どちらかが「もう一方ではない何をするのか」を明示すべきです。

2. 意味のないパラメータ

型が string の query という名前のパラメータは、エージェントに何も伝えません。そこに入るのはキーワードか、質問か、ID か。大文字小文字を区別するのか。空ならどうなるのか。それが属するのはスキーマであって README ではありません。

3. 曖昧なツールに例がない

ほとんどのツールに例は要りません。しかし自由形式のオブジェクトやフィルタ式、ドメイン固有の識別子を受け取るツールには必ず必要です。私たちの評価では「利用例がない」は最も頻出する弱点のひとつであり、ほぼ常にサーバー全体ではなく特定の一つのツールを指しています。

4. 黙っている制約

レート制限、最大件数、実行タイムアウト、呼び出しに費用がかかるかどうか。制限を知らないエージェントは必ずそこにぶつかります。高得点のサーバーは、こうしたことを説明文にはっきり書いています。

要点

  • 異なる役割を示す異なる名前。
  • 各パラメータは「何を入れるか」という言葉で説明する。
  • 人間なら質問するであろうツールには例を添える。
  • 制約は、エージェントが実際に読む場所に書く。

どれもツールを増やすことを求めていません。多くはむしろ、より良く説明された、より少ないツールを求めています。

サーバーの評価を見る
#mcp#ツール#エージェント

他の記事

ツール一覧をエージェントにとって読みやすくするもの | mcpmetrics