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 は、ダイアログが出ているときにだけ意味があるツールです。しかし説明文からは、それが読み取れません。

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

一方で、同じサーバーの中にも点の高いツールがあります。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 点のまま）。破壊的でないことをクライアントに伝える意味もあります。

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

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

npx forecall lint tools.json

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

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

まとめ：まず「いつ使うか」と「何を返すか」を 1 文ずつ足す

Google と Microsoft のブラウザ操作の MCP は、引数の説明は丁寧な一方で、ツールの使いどころと戻り値はほとんど書いていませんでした。どちらも、エージェントがツールを選ぶときにいちばん必要な情報です。

自分のサーバーでも、点の低いツールから順に「どんな場面で使うか（似たツールとの違い）」と「何が返るか」を 1 文ずつ足すところから始めるのが、手間に対していちばん効果があります。drag の例では、それだけで 31 点が 74 点になりました。