追記（2026-10-09）: 書き直した説明文を実際のモデルで確かめた結果を「実際のモデルで確かめたら、短い説明文で足りていて、書き直しは逆効果だった」の節に足し、それに合わせて「エージェントには足りない」とした箇所とまとめを直しました。

Google の Chrome DevTools MCP と Microsoft の Playwright MCP について、各ツールの説明文を採点しました。平均点はそれぞれ 45.1 点と 41.9 点（100 点満点）です。Chrome DevTools MCP は 30 ツール中 24 個、Playwright MCP は 25 ツール中 23 個が「いつ使うか」を書いていません。「何を返すか」がないツールも、それぞれ 27 個と 21 個ありました。

採点に使ったのは、筆者が作っている MCP のツール説明文の静的リンター Forecall です。この記事では、結果と、低い説明文と高い説明文の違いを紹介します。最後に、説明文を 3 文書き足して点数がどう変わるかを試し、元の説明文と書き直した説明文を実際のモデルに使わせて比べました。

エージェントがツールを選ぶ手がかりは、名前と説明文と入力スキーマしかない

AI エージェントは、MCP サーバーから受け取ったツールの一覧（tools/list の結果）を読んで、どのツールをどの引数で呼ぶかを決めます。そのときに読めるのは、ツールの名前、説明文（description）、入力スキーマの 3 つだけです。

説明文が「名前を言い直しただけの一文」だと、モデルの手がかりは名前とスキーマだけになり、呼んだら何が返るかは呼んでみるまで分かりません。それで足りるかどうかは、実際のモデルで測らないと分かりません。この記事の後半で測りました。

採点の方法：tools/list を取り、6 つの観点で 100 点満点にする

2026 年 10 月 7 日に、次の 2 つの版を手元で起動し、tools/list の結果を JSON に保存しました。ツールは呼んでいません。

サーバー	パッケージと版	ツール数
Chrome DevTools MCP	`chrome-devtools-mcp@1.10.1`	30
Playwright MCP	`@playwright/mcp@0.0.83`	25

この JSON を Forecall の CLI（npx forecall lint）で採点しました。Forecall は 1 ツールごとに、次の 6 つの観点で点を付けます。

観点	満点	見ていること
目的	20	何をするツールかが、名前の言い直し以上に書かれているか
使いどころ	20	いつ使うか、似たツールとどう使い分けるか
引数	25	各引数に説明があり、型や必須が指定されているか
戻り値	15	何が返るか（出力スキーマか説明文）
制約と副作用	10	前提条件や副作用が書かれているか
例	10	使い方の例があるか

採点はルールベースで、説明文とスキーマの文字だけを見ます。実際のモデルがツールを正しく選べるかは測っていません。この限界は最後の節で改めて触れます。

結果：2 つとも平均は 40 点台で、弱いところも同じだった

	Chrome DevTools MCP	Playwright MCP
平均点	45.1	41.9
「いつ使うか」がない	24 / 30	23 / 25
「何を返すか」がない	27 / 30	21 / 25
説明文が名前の言い直し	6	14
取り違えやすいツールの組	0	0

どちらも、点を落としている理由の大半は「使いどころ」と「戻り値」です。 引数の説明はどちらもよく書かれていて、取り違えやすいと判定された組もありませんでした。ツールの名前がはっきり分かれているぶん、一覧としては混乱しにくい作りです。

違いが出たのは、説明文が名前の言い直しになっているツールの数でした。Playwright MCP は 25 個中 14 個がこの指摘を受けています。

低い説明文は、名前を言い直した一文で終わっている

最低点は、Chrome DevTools MCP が 31 点（drag、hover、upload_file）、Playwright MCP が 33 点（browser_handle_dialog、browser_navigate、browser_type など）でした。説明文はそれぞれ次のとおりです。

ツール	説明文
drag	Drag an element onto another element
hover	Hover over the provided element
browser_handle_dialog	Handle a dialog
browser_navigate	Navigate to a URL

どれも、どんな場面で呼ぶか、呼ぶ前に何が必要か、呼んだら何が返るかを書いていません。たとえば browser_handle_dialog は、ダイアログが出ているときにだけ意味があるツールです。しかし説明文からは、それが読み取れません。リンターが測っているのは、こうした書かれていない情報です。モデルが選び間違えることまでは示しません。実際、1 回で選ぶ場面では選び間違えなかったことが、後半の確認で分かりました。

高い説明文は、使いどころと例を書いている

一方で、同じサーバーの中にも点の高いツールがあります。Chrome DevTools MCP の最高点は fill_form の 72 点です。

Fill out multiple form elements (inputs, selects, checkboxes, radios) at once. ALWAYS prefer this tool over multiple individual 'fill' or 'click' calls when interacting with forms. It is significantly faster, more reliable, and reduces turn count. Example: Fill username, password, and check "Remember Me" in one call.

fill や click とどう使い分けるかを書き、具体例も付けています。足りないのは戻り値だけでした。

Playwright MCP の最高点は browser_find の 66 点です。何を検索し、何が返り、スナップショット全体を取るよりどう得なのかを、1 段落で説明しています。

drag の説明文に 3 文足したら、点数は 31 点から 74 点になった

drag の説明文を、スキーマに書かれている事実だけを使って書き直してみました。足したのは、使いどころ（と upload_file との使い分け）、呼ぶ前の準備、戻り値の 3 つです。

Drag one element and drop it onto another inside the page. Use it for drag-and-drop UIs such as sortable lists, kanban boards and sliders; to send files from the computer, use upload_file instead. Take a snapshot first and pass the uids of both elements as from_uid and to_uid. Returns a snapshot of the page after the drop when includeSnapshot is true.

観点	元の説明文	書き直し後
目的	6	17
使いどころ	0	20
引数	18	18
戻り値	0	7
制約と副作用	7	7
例	0	5
合計	31	74

43 点の差です。いちばん効いたのは使いどころの 1 文で、0 点が満点の 20 点になりました。

一方で、書き直し後には「破壊的な操作の可能性があるのに destructiveHint が付いていない」という指摘が新たに出ました。説明文の drop という語に反応したものです。drag はページを壊す操作ではないので、この指摘は外れです。ツールの annotations に destructiveHint: false を明示すると、この指摘は消えます（点数は 74 点のまま）。破壊的でないことをクライアントに伝える意味もあります。

ただし、点数が上がることと、モデルがうまく選べるようになることは別です。次の節で確かめました。

実際のモデルで確かめたら、短い説明文で足りていて、書き直しは逆効果だった

Chrome DevTools MCP のメンテナーから「短い説明文でエージェントが迷う具体例はあるか」と聞かれ、その例を作ろうとしました。chrome-devtools-mcp 1.10.1 の tools/list を、そのまま返すか、drag、hover、upload_file の 3 つを書き直して返す代わりのサーバーを用意しました。そのうえで、この 3 つのどれかが正解になる 1 回きりのタスクを 8 種類、モデルに解かせました（かんばんのカード、ホバーで開くメニュー、ツールチップ、「写真を追加」ボタン、画像をドロップできるアバターの枠など）。

元の説明文では、どのモデルも違うツールを選びませんでした。Claude Code の Fable 5.1、Sonnet 5.5、Haiku 4.5 で 24 回中 24 回、Codex CLI の gpt-6-astra で 11 回中 11 回、API を 1 回呼ぶ形の Claude Opus 5.5、Claude Sonnet 5.5、gpt-6-astra、gpt-6.1-sol で 32 回中 32 回、正しいツールを選んでいます。小さめの Codex のモデル 2 つが hover の代わりに click を選んだのは、タスクの文があいまいだった 1 種類だけでした。
書き直した説明文では、2 つのモデルが悪くなりました。gpt-5.6-luna は「Use it for drag-and-drop UIs」を「画像をドロップできる」枠に結びつけ、upload_file ではなく drag を 4 回中 2 回選びました（元の説明文では 4 回中 0 回）。gpt-6-astra は、書き直した upload_file の説明文で「写真を追加」のタスクに 10 回中 4 回、「使うツールが分からない」と答えました（元の説明文では 4 回中 0 回）。

1 回で選ぶ場面なら、1 行の説明文とスキーマ（from_uid と to_uid、filePaths）で足りていました。74 点の説明文は、むしろ 2 つのモデルの正答率を下げています。数字の表は Issue のコメントにあります。説明文にまだ書かれていない「呼んだら何が返るか」と「uid は直前のスナップショットから取る」ことは、何手も続く作業では効くかもしれません。今回の確認は、そこまでは調べていません。

自分の MCP サーバーで試す手順

自分のサーバーの tools/list の結果を JSON に保存して、次のように実行します。採点は手元だけで行い、ファイルはどこにも送りません。

npx forecall lint tools.json

日本語で結果を見たいときは --lang ja を、CI で平均点の下限を決めたいときは --fail-under 60 のように付けます。ブラウザで試したい場合は、同じ JSON を forecall.dev に貼ると、登録なしで採点できます。

注意点が 1 つあります。この点数は文字だけを読んで付けているので、browser_close のように短くても名前で意味が明らかなツールは、モデルが正しく使えていても低く出ます。点数は「どこに書き足す余地があるか」を探す目安として使ってください。実際のモデルがツールを正しく選べるかは、別の方法で測る必要があります。上の確認のとおり、点数が高くなっても、モデルの選び方が良くなるとは限りません。

まとめ：点数で抜けを見つけ、書き直したら実際のモデルで確かめる

Google と Microsoft のブラウザ操作の MCP は、引数の説明は丁寧な一方で、ツールの使いどころと戻り値はほとんど書いていませんでした。リンターは、こうした抜けをすぐに見つけます。ただし、モデルが選び間違えることまでは教えてくれません。今回の 3 つのツールでは、1 行の説明文のままでもモデルは正しく選び、長く書き直した説明文では 2 つのモデルが悪くなりました。

自分のサーバーでも、点の低いツールから順に、呼んだら何が返るかといった抜けを埋めてみてください。そのうえで、利用者が使うモデルで新しい説明文を確かめてから出すのが安全です。「drop」のような語や、使う場面の例を並べた文が、モデルを違うツールに引き寄せることがあります。