Playwright を利用したブラウザ自動化機能を提供する Model Context Protocol (MCP) サーバーです。このサーバーにより、LLM は構造化されたアクセシビリティスナップショットを通じてウェブページと対話できるようになり、スクリーンショットや視覚的に調整されたモデルが不要になります。
このパッケージは Playwright への MCP インターフェースを提供します。コーディングエージェントを使用している場合は、代わりに CLI+SKILLS を使用する方が有益な場合があります。
CLI: 最近のコーディングエージェントは、CLI ベースのワークフローを SKILL として公開する方法を MCP よりも好む傾向があります。これは、CLI 呼び出しの方がトークン効率が良いためです。大きなツールスキーマや冗長なアクセシビリティツリーをモデルコンテキストに読み込むことを避け、エージェントが簡潔で目的に特化したコマンドを通じて行動できるようにします。そのため、CLI + SKILLs は、限られたコンテキストウィンドウ内でブラウザ自動化と大規模なコードベース、テスト、推論のバランスを取る必要がある、高スループットのコーディングエージェントに適しています。詳細はこちら: Playwright CLI with SKILLS
MCP: MCP は、永続的な状態、豊富な内省、ページ構造に対する反復的な推論が有益な特殊なエージェントループ（探索的自動化、自己修復テスト、継続的なブラウザコンテキストの維持がトークンコストの懸念を上回る長時間実行の自律ワークフローなど）において、依然として有用です。
高速かつ軽量。Playwright のアクセシビリティツリーを使用し、ピクセルベースの入力は使用しません。
LLM フレンドリー。視覚モデルは不要で、構造化データのみで動作します。
決定論的なツール適用。スクリーンショットベースのアプローチに共通する曖昧さを回避します。
Node.js 18 以降
VS Code、Cursor、Windsurf、Claude Desktop、Goose、Grok、Junie、またはその他の MCP クライアント
まず、Playwright MCP サーバーをクライアントにインストールします。
標準設定は、ほとんどのツールで動作します。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}
Amp VS Code 拡張機能の設定画面から追加するか、settings.json ファイルを更新して追加します。
"amp.mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}Amp CLI セットアップ:
以下の amp mcp add コマンドで追加します。
amp mcp add playwright -- npx @playwright/mcp@latestAntigravity の設定から追加するか、設定ファイルを更新して追加します。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}Claude Code CLI を使用して Playwright MCP サーバーを追加します。
claude mcp add playwright npx @playwright/mcp@latestMCP インストール ガイド に従い、上記の標準設定を使用します。
MCP サーバーの設定 セクションの手順に従います。
例: ローカルセットアップ
以下の内容を cline_mcp_settings.json ファイルに追加します。
{
"mcpServers": {
"playwright": {
"type": "stdio",
"command": "npx",
"timeout": 30,
"args": [
"-y",
"@playwright/mcp@latest"
],
"disabled": false
}
}
}Codex CLI を使用して Playwright MCP サーバーを追加します。
codex mcp add playwright npx "@playwright/mcp@latest"または、設定ファイル ~/.codex/config.toml を作成または編集し、以下を追加します。
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]詳細については、Codex MCP ドキュメント を参照してください。
Copilot CLI を使用して、対話的に Playwright MCP サーバーを追加します。
/mcp addまたは、設定ファイル ~/.copilot/mcp-config.json を作成または編集し、以下を追加します。
{
"mcpServers": {
"playwright": {
"type": "local",
"command": "npx",
"tools": [
"*"
],
"args": [
"@playwright/mcp@latest"
]
}
}
}詳細については、Copilot CLI ドキュメント を参照してください。
Cursor Settings -> MCP -> Add new MCP Server に移動します。任意の名前を付け、command タイプを選択し、コマンド npx @playwright/mcp@latest を入力します。Edit をクリックして設定を確認したり、引数のようなコマンドを追加したりすることもできます。
Factory CLI を使用して Playwright MCP サーバーを追加します。
droid mcp add playwright "npx @playwright/mcp@latest"または、Factory droid 内で /mcp と入力して、MCP サーバーを管理するための対話型 UI を開きます。
詳細については、Factory MCP ドキュメント を参照してください。
MCP インストール ガイド に従い、上記の標準設定を使用します。
Advanced settings -> Extensions -> Add custom extension に移動します。任意の名前を付け、タイプ STDIO を選択し、command に npx @playwright/mcp を設定します。「Add Extension」をクリックします。
Grok CLI を使用して Playwright MCP サーバーを追加します。
grok mcp add playwright -- npx @playwright/mcp@latestまたは、設定ファイル ~/.grok/config.toml を作成または編集し、以下を追加します。
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]詳細については、Grok MCP ドキュメント を参照してください。
Junie CLI で Playwright MCP サーバーを追加するには:
/mcp と入力します
Ctrl+A を押して新しい MCP サーバーを追加します
リストから Playwright を選択します
または、.junie/mcp/mcp.json に追加します。
{
"mcpServers": {
"Playwright": {
"command": "npx",
"args": [
"-y",
"@playwright/mcp@latest"
]
}
}
}詳細については、Junie MCP 設定ドキュメント を参照してください。
MCP サーバーの ドキュメント に従います。例として .kiro/settings/mcp.json に以下を追加します。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}
右サイドバーの Program -> Install -> Edit mcp.json に移動します。上記の標準設定を使用します。
MCP サーバーの ドキュメント に従います。例として ~/.config/opencode/opencode.json に以下を追加します。
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"playwright": {
"type": "local",
"command": [
"npx",
"@playwright/mcp@latest"
],
"enabled": true
}
}
}
VSCode または IntelliJ で Qodo Gen チャットパネルを開きます → Connect more tools → + Add new MCP → 上記の標準設定を貼り付けます。
Save をクリックします。
MCP インストール ガイド に従い、上記の標準設定を使用します。VS Code CLI を使用して Playwright MCP サーバーをインストールすることもできます。
# For VS Code
code --add-mcp '{"name":"playwright","command":"npx","args":["@playwright/mcp@latest"]}'インストール後、Playwright MCP サーバーは VS Code の GitHub Copilot エージェントで使用できるようになります。
Settings -> AI -> Manage MCP Servers -> + Add に移動して MCP サーバーを追加 します。上記の標準設定を使用します。
または、Warp プロンプトでスラッシュコマンド /add-mcp を使用し、上記の標準設定を貼り付けます。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}Windsurf MCP ドキュメント に従います。上記の標準設定を使用します。
Playwright MCP サーバーは以下の引数をサポートしています。これらは、上記の JSON 設定内で、"args" リストの一部として指定できます。
オプション | 説明 |
| このサーバーが提供を許可されるホストのカンマ区切りのリスト。デフォルトはサーバーがバインドされているホストです。'*' を指定するとホストチェックを無効にします。env |
| ブラウザがリクエストを許可する TRUSTED（信頼された）オリジンのセミコロン区切りのリスト。デフォルトはすべて許可します。重要: セキュリティ境界として機能せず、リダイレクトに影響しません。env |
| ワークスペースルート外のファイルへのアクセスを許可します。また |
| ブラウザがリクエストをブロックするオリジンのセミコロン区切りのリスト。ブロックリストは許可リストの前に評価されます。許可リストなしで使用した場合、ブロックリストに一致しないリクエストは引き続き許可されます。重要: セキュリティ境界として機能せず、リダイレクトに影響しません。env |
| サービスワーカーをブロックしますenv |
| 使用するブラウザまたは Chrome チャンネル。指定可能な値: chrome、firefox、webkit、msedge。env |
| 有効にする追加機能のカンマ区切りのリスト。指定可能な値: vision、pdf、devtools。env |
| 接続先の CDP エンドポイント。env |
| 接続リクエストとともに送信する CDP ヘッダー。複数指定可能。env |
| CDP エンドポイントへの接続タイムアウト（ミリ秒）。デフォルトは 30000ms。env |
| コード生成に使用する言語を指定します。指定可能な値: "typescript"、"python"、"java"、"csharp"、"none"。デフォルトは "typescript"。env |
| 設定ファイルへのパス。env |
| 返すコンソールメッセージのレベル: "error"、"warning"、"info"、"debug"。各レベルにはより重大なレベルのメッセージが含まれます。env |
| エミュレートするデバイス（例: "iPhone 15"）env |
| 汎用モバイルデバイスをエミュレートします（Chromium では Pixel 10、WebKit では iPhone 17）。モバイルページは通常軽量で、トークンを節約できます。--device との併用はできません。env |
| ブラウザ実行ファイルへのパス。env |
| 実行中のブラウザインスタンスに接続します（Edge/Chrome のみ）。"Playwright Extension" のインストールが必要です。env |
| 接続先のバウンドブラウザエンドポイント。env |
| ブラウザコンテキストに付与する権限のリスト（例: "geolocation"、"clipboard-read"、"clipboard-write"）env |
| ブラウザをヘッドレスモードで実行します。デフォルトはヘッド付き。env |
| サーバーをバインドするホスト。デフォルトは localhost。すべてのインターフェースにバインドするには 0.0.0.0 を使用します。env |
| HTTPS エラーを無視しますenv |
| Playwright のページオブジェクトで評価する TypeScript ファイルへのパスenv |
| 初期化スクリプトとして追加する JavaScript ファイルへのパス。このスクリプトはすべてのページで、そのページのスクリプトよりも前に評価されます。複数回指定可能。env |
| ブラウザプロファイルをメモリ内に保持し、ディスクに保存しません。env |
| 画像レスポンスをクライアントに送信するかどうか。"allow" または "omit" を指定可能。デフォルトは "allow"。env |
| 通常サンドボックス化されるすべてのプロセスタイプのサンドボックスを無効にします。env |
| 出力ファイル用ディレクトリへのパス。env |
| 古い出力ファイルを削除するしきい値（バイト単位）env |
| SSE トランスポート用のリスンポート。env |
| プロキシをバイパスするドメインのカンマ区切りリスト（例: ".com,chromium.org,.domain.com"）env |
| プロキシサーバーを指定します（例: "http://myproxy:3128" または "socks5://myproxy:8080"）env |
| 通常サンドボックス化されないすべてのプロセスタイプのサンドボックスを有効にします。env |
| Playwright MCP セッションを出力ディレクトリに保存するかどうか。env |
| dotenv 形式のシークレットを含むファイルへのパスenv |
| すべての接続された HTTP クライアント間で同じブラウザコンテキストを再利用します。env |
| 各要素のバウンディングボックスをスナップショットに [box=x,y,width,height] として含めます。座標はビューポート相対、CSS ピクセル単位です。env |
| レスポンス用のスナップショットを撮る際のモードを指定します。"full" または "none" が指定可能。デフォルトは "full"。env |
| 分離セッション用のストレージ状態ファイルへのパス。env |
| テスト ID に使用する属性を指定します。デフォルトは "data-testid"env |
| アクションのタイムアウトをミリ秒で指定します。デフォルトは 5000ms。env |
| ナビゲーションのタイムアウトをミリ秒で指定します。デフォルトは 60000ms。env |
| 各アクション後のトリガーされた処理の落ち着きを待つ時間（ミリ秒）。デフォルトは 500ms。env |
| ユーザーエージェント文字列を指定しますenv |
| ユーザーデータディレクトリへのパス。指定しない場合、一時ディレクトリが作成されます。env |
| ブラウザのビューポートサイズをピクセル単位で指定します（例: "1280x720"）env |
Playwright MCP は、通常のブラウザのように永続的なプロファイルを使用する（デフォルト）、テストセッション用に隔離されたコンテキストで実行する、またはブラウザ拡張機能を使用して既存のブラウザに接続する、のいずれかの方法で実行できます。
永続的なプロファイル
ログイン情報はすべて永続的なプロファイルに保存されます。セッション間で削除してオフライン状態をクリアすることもできます。
永続的なプロファイルは以下の場所にあり、--user-data-dir 引数で上書きできます。
# Windows
%USERPROFILE%\AppData\Local\ms-playwright\mcp-{channel}-{workspace-hash}
# macOS
- ~/Library/Caches/ms-playwright/mcp-{channel}-{workspace-hash}
# Linux
- ~/.cache/ms-playwright/mcp-{channel}-{workspace-hash}{workspace-hash} は MCP クライアントのワークスペースルートから派生するため、異なるプロジェクトは自動的に個別のプロファイルを取得します。
[!IMPORTANT] 永続的なプロファイルは同時に1つのブラウザインスタンスでのみ使用できるため、同じワークスペースを共有する同時実行の MCP クライアントは競合します。複数のクライアントを並行して実行するには、追加の各クライアントを
--isolatedで起動するか、別の--user-data-dirを指定します。
隔離モード
隔離モードでは、各セッションは隔離されたプロファイルで開始されます。MCP にブラウザを閉じるよう指示するたびに、セッションは閉じられ、このセッションのすべてのストレージ状態は失われます。設定の contextOptions または --storage-state 引数を介して、ブラウザに初期ストレージ状態を提供できます。ストレージ状態の詳細はこちらを参照してください。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest",
"--isolated",
"--storage-state={path/to/storage.json}"
]
}
}
}ブラウザ拡張機能
Playwright MCP Chrome 拡張機能を使用すると、既存のブラウザタブに接続し、ログイン済みセッションやブラウザ状態を活用できます。インストールと設定手順については microsoft/playwright › packages/extension を参照してください。
ブラウザコンテキストやページに初期状態を提供する方法は複数あります。
ストレージ状態については、次のいずれかを選択できます：
--user-data-dir 引数を使用してユーザーデータディレクトリで開始する。これにより、すべてのブラウザデータがセッション間で永続化されます。
--storage-state 引数を使用してストレージ状態ファイルで開始する。これにより、ファイルからクッキーとローカルストレージが隔離されたブラウザコンテキストにロードされます。
ページ状態については、以下を使用できます：
--init-page で、Playwright のページオブジェクト上で評価される TypeScript ファイルを指定します。これにより、ページを設定するための任意のコードを実行できます。
// init-page.ts
export default async ({ page }) => {
await page.context().grantPermissions(['geolocation']);
await page.context().setGeolocation({ latitude: 37.7749, longitude: -122.4194 });
await page.setViewportSize({ width: 1280, height: 720 });
};--init-script で、初期化スクリプトとして追加される JavaScript ファイルを指定します。このスクリプトは、ページのスクリプトが実行される前にすべてのページで評価されます。
これは、ブラウザ API のオーバーライドや環境のセットアップに便利です。
// init-script.js
window.isPlaywrightMCP = true;Playwright MCP サーバーは、JSON 設定ファイルを使用して設定できます。設定ファイルは --config コマンドラインオプションで指定します：
npx @playwright/mcp@latest --config path/to/config.json{
/**
* The browser to use.
*/
browser?: {
/**
* The type of browser to use.
*/
browserName?: 'chromium' | 'firefox' | 'webkit';
/**
* Keep the browser profile in memory, do not save it to disk.
*/
isolated?: boolean;
/**
* Path to a user data directory for browser profile persistence.
* Temporary directory is created by default.
*/
userDataDir?: string;
/**
* Launch options passed to
* @see https://playwright.dev/docs/api/class-browsertype#browser-type-launch-persistent-context
*
* This is useful for settings options like `channel`, `headless`, `executablePath`, etc.
*/
launchOptions?: playwright.LaunchOptions;
/**
* Context options for the browser context.
*
* This is useful for settings options like `viewport`.
*/
contextOptions?: playwright.BrowserContextOptions;
/**
* Chrome DevTools Protocol endpoint to connect to an existing browser instance in case of Chromium family browsers.
*/
cdpEndpoint?: string;
/**
* CDP headers to send with the connect request.
*/
cdpHeaders?: Record<string, string>;
/**
* Timeout in milliseconds for connecting to CDP endpoint. Defaults to 30000 (30 seconds). Pass 0 to disable timeout.
*/
cdpTimeout?: number;
/**
* Remote endpoint to connect to an existing Playwright server. May be a
* WebSocket URL string, or a [ConnectOptions] object that mirrors the
* `connectOptions` shape used by the test runner. When passed as an object,
* `exposeNetwork`, `headers`, `slowMo`, and `timeout` are forwarded to the
* underlying connect call.
*/
remoteEndpoint?: string | playwright.ConnectOptions & { endpoint: string };
/**
* Paths to TypeScript files to add as initialization scripts for Playwright page.
*/
initPage?: string[];
/**
* Paths to JavaScript files to add as initialization scripts.
* The scripts will be evaluated in every page before any of the page's scripts.
*/
initScript?: string[];
},
/**
* Connect to a running browser instance (Edge/Chrome only). If specified, `browser`
* config is ignored.
* Requires the "Playwright Extension" to be installed.
*/
extension?: boolean;
server?: {
/**
* The port to listen on for SSE or MCP transport.
*/
port?: number;
/**
* The host to bind the server to. Default is localhost. Use 0.0.0.0 to bind to all interfaces.
*/
host?: string;
/**
* The hosts this server is allowed to serve from. Defaults to the host server is bound to.
* This is not for CORS, but rather for the DNS rebinding protection.
*/
allowedHosts?: string[];
},
/**
* List of enabled tool capabilities. Possible values:
* - 'core': Core browser automation features.
* - 'pdf': PDF generation and manipulation.
* - 'vision': Coordinate-based interactions.
* - 'devtools': Developer tools features.
*/
capabilities?: ToolCapability[];
/**
* Whether to save the Playwright session into the output directory.
*/
saveSession?: boolean;
/**
* Reuse the same browser context between all connected HTTP clients.
*/
sharedBrowserContext?: boolean;
/**
* Secrets are used to replace matching plain text in the tool responses to prevent the LLM
* from accidentally getting sensitive data. It is a convenience and not a security feature,
* make sure to always examine information coming in and from the tool on the client.
*/
secrets?: Record<string, string>;
/**
* The directory to save output files.
*/
outputDir?: string;
/**
* Threshold for evicting old output files, in bytes.
*/
outputMaxSize?: number;
console?: {
/**
* The level of console messages to return. Each level includes the messages of more severe levels. Defaults to "info".
*/
level?: 'error' | 'warning' | 'info' | 'debug';
},
network?: {
/**
* List of origins to allow the browser to request. Default is to allow all. Origins matching both `allowedOrigins` and `blockedOrigins` will be blocked.
*
* Supported formats:
* - Full origin: `https://example.com:8080` - matches only that origin
* - Wildcard port: `http://localhost:*` - matches any port on localhost with http protocol
*/
allowedOrigins?: string[];
/**
* List of origins to block the browser to request. Origins matching both `allowedOrigins` and `blockedOrigins` will be blocked.
*
* Supported formats:
* - Full origin: `https://example.com:8080` - matches only that origin
* - Wildcard port: `http://localhost:*` - matches any port on localhost with http protocol
*/
blockedOrigins?: string[];
};
/**
* Specify the attribute to use for test ids, defaults to "data-testid".
*/
testIdAttribute?: string;
timeouts?: {
/*
* Configures default action timeout: https://playwright.dev/docs/api/class-page#page-set-default-timeout. Defaults to 5000ms.
*/
action?: number;
/*
* Configures default navigation timeout: https://playwright.dev/docs/api/class-page#page-set-default-navigation-timeout. Defaults to 60000ms.
*/
navigation?: number;
/**
* Configures default expect timeout: https://playwright.dev/docs/test-timeouts#expect-timeout. Defaults to 5000ms.
*/
expect?: number;
/**
* How long to wait after each action for triggered work (navigations, requests) to settle before responding. Defaults to 500ms.
*/
settle?: number;
};
/**
* Whether to send image responses to the client. Can be "allow", "omit", or "auto". Defaults to "auto", which sends images if the client can display them.
*/
imageResponses?: 'allow' | 'omit';
snapshot?: {
/**
* When taking snapshots for responses, specifies the mode to use.
*/
mode?: 'full' | 'none';
/**
* Whether to include each element's bounding box as [box=x,y,width,height] in snapshots.
* Coordinates are viewport-relative, in CSS pixels (Element.getBoundingClientRect).
*/
boxes?: boolean;
};
/**
* allowUnrestrictedFileAccess acts as a guardrail to prevent the LLM from accidentally
* wandering outside its intended workspace. It is a convenience defense to catch unintended
* file access, not a secure boundary; a deliberate attempt to reach other directories can be
* easily worked around, so always rely on client-level permissions for true security.
*/
allowUnrestrictedFileAccess?: boolean;
/**
* Specify the language to use for code generation.
*/
codegen?: 'typescript' | 'python' | 'java' | 'csharp' | 'none';
}ディスプレイがないシステムや IDE のワーカープロセスからヘッド付きブラウザを実行する場合は、DISPLAY 環境変数が設定された環境で MCP サーバーを実行し、--port フラグを渡して HTTP トランスポートを有効にします。
npx @playwright/mcp@latest --port 8931次に、MCP クライアント設定で、url を HTTP エンドポイントに設定します：
{
"mcpServers": {
"playwright": {
"url": "http://localhost:8931/mcp"
}
}
}Related MCP server: Playwright MCP Server
Playwright MCP はセキュリティ境界ではありません。デプロイメントの保護に関するガイダンスは MCP セキュリティのベストプラクティス を参照してください。
注： 現在、Docker 実装はヘッドレス Chromium のみをサポートしています。
{
"mcpServers": {
"playwright": {
"command": "docker",
"args": ["run", "-i", "--rm", "--init", "--pull=always", "mcr.microsoft.com/playwright/mcp"]
}
}
}または、MCP クライアントにコンテナを起動させる代わりに、長期実行サービスとして実行する場合は、以下を使用します：
docker run -d -i --rm --init --pull=always \
--entrypoint node \
--name playwright \
-p 8931:8931 \
mcr.microsoft.com/playwright/mcp \
/app/cli.js --headless --browser chromium --no-sandbox --port 8931 --host 0.0.0.0サーバーはホストポート 8931 でリッスンし、任意の MCP クライアントからアクセスできます。
Docker イメージを自分でビルドすることもできます。
docker build -t mcr.microsoft.com/playwright/mcp .import http from 'http';
import { createConnection } from '@playwright/mcp';
import { SSEServerTransport } from '@modelcontextprotocol/sdk/server/sse.js';
http.createServer(async (req, res) => {
// ...
// Creates a headless Playwright MCP server with SSE transport
const connection = await createConnection({ browser: { launchOptions: { headless: true } } });
const transport = new SSEServerTransport('/messages', res);
await connection.connect(transport);
// ...
});browser_click
タイトル: クリック
説明: ウェブページ上でクリックを実行します
パラメータ:
element (string, 任意): 要素との対話許可を得るために使用される、人間が読める要素の説明
target (string): ページスナップショットからの正確なターゲット要素参照、または一意の要素セレクター
doubleClick (boolean, 任意): シングルクリックではなくダブルクリックを実行するかどうか
button (string, 任意): クリックするボタン、デフォルトは左
modifiers (array, 任意): 押す修飾キー
読み取り専用: false
browser_close
タイトル: ブラウザを閉じる
説明: ページを閉じます
パラメータ: なし
読み取り専用: false
browser_console_messages
タイトル: コンソールメッセージを取得
説明: すべてのコンソールメッセージを返します
パラメータ:
level (string): 返すコンソールメッセージのレベル。各レベルにはより重大なレベルのメッセージが含まれます。デフォルトは "info" です。
all (boolean, 任意): セッション開始以降のすべてのコンソールメッセージを返すかどうか（最後のナビゲーション以降のみではない）。デフォルトは false。
filename (string, 任意): コンソールメッセージを保存するファイル名。指定しない場合、メッセージはテキストとして返されます。
読み取り専用: true
browser_drag
タイトル: マウスをドラッグ
説明: 2つの要素間でドラッグアンドドロップを実行します
パラメータ:
startElement (string, 任意): 要素との対話許可を得るために使用される、人間が読めるソース要素の説明
startTarget (string): ページスナップショットからの正確なターゲット要素参照、または一意の要素セレクター
endElement (string, 任意): 要素との対話許可を得るために使用される、人間が読めるターゲット要素の説明
endTarget (string): ページスナップショットからの正確なターゲット要素参照、または一意の要素セレクター
読み取り専用: false
browser_drop
タイトル: 要素にファイルまたはデータをドロップ
説明: ページの外部からドラッグしたかのように、要素にファイルまたは MIME タイプのデータをドロップします。"paths" または "data" の少なくとも一方を指定する必要があります。
パラメータ:
element (string, 任意): 要素との対話許可を得るために使用される、人間が読める要素の説明
target (string): ページスナップショットからの正確なターゲット要素参照、または一意の要素セレクター
paths (array, 任意): 要素にドロップするファイルの絶対パス。
data (object, 任意): ドロップするデータ。MIME タイプをキー、文字列を値とするマップ（例：{"text/plain": "hello", "text/uri-list": "https://example.com"}）。
読み取り専用: false
browser_evaluate
タイトル: JavaScript を評価
説明: ページまたは要素上で JavaScript 式を評価します
パラメータ:
element (string, 任意): 要素との対話許可を得るために使用される、人間が読める要素の説明
target (string, 任意): ページスナップショットからの正確なターゲット要素参照、または一意の要素セレクター
function (string): () => { /* コード / } または要素が指定された場合は (element) => { / コード */ }
filename (string, 任意): 結果を保存するファイル名。指定しない場合、結果はテキストとして返されます。
読み取り専用: false
browser_file_upload
タイトル: ファイルをアップロード
説明: 1つまたは複数のファイルをアップロードします
パラメータ:
paths (array, 任意): アップロードするファイルの絶対パス。単一ファイルまたは複数ファイル。省略した場合、ファイル選択はキャンセルされます。
読み取り専用: false
browser_fill_form
タイトル: フォームに入力
説明: 複数のフォームフィールドに入力します
パラメータ:
fields (array): 入力するフィールド
読み取り専用: false
browser_find
タイトル: ページスナップショット内を検索
説明: 現在のページのアクセシビリティスナップショットをテキストまたは正規表現で検索します。一致したスナップショットノードを、周辺の数行のコンテキスト（検索スニペットのようなもの）とともに返します。各ノードはツリーのルートからのパスの下に表示され、要素とその参照を見つけるためだけにスナップショット全体を取得するよりも軽量です。
パラメータ:
text (string, 任意): ページスナップショット内で検索するプレーンテキスト（大文字小文字を区別しない部分一致）。text または regex のいずれかを指定します。両方は指定できません。
regex (string, 任意): ページスナップショット内で検索する正規表現。デフォルトでは大文字小文字を区別して一致します。フラグを追加するにはパターンをスラッシュで囲みます（例："/error/i" で大文字小文字を区別しない）。text または regex のいずれかを指定します。両方は指定できません。
読み取り専用: true
browser_handle_dialog
タイトル: ダイアログを処理
説明: ダイアログを処理します
パラメータ:
accept (boolean): ダイアログを受け入れるかどうか。
promptText (string, 任意): プロンプトダイアログの場合のプロンプトテキスト。
読み取り専用: false
browser_hover
タイトル: マウスをホバー
説明: ページ上の要素にマウスをホバーします
パラメータ:
element (string, 任意): 要素との対話許可を得るために使用される、人間が読める要素の説明
target (string): ページスナップショットからの正確なターゲット要素参照、または一意の要素セレクター
読み取り専用: false
browser_navigate
タイトル: URL に移動
説明: URL に移動します
パラメータ:
url (string): 移動先の URL
読み取り専用: false
browser_navigate_back
タイトル: 戻る
説明: 履歴内の前のページに戻ります
パラメータ: なし
読み取り専用: false
browser_network_request
タイトル: ネットワークリクエストの詳細を表示
説明: 単一のネットワークリクエストの完全な詳細（ヘッダーと本文）を返します。part が設定されている場合は単一部分を返します。browser_network_requests からの番号を使用します。
パラメータ:
index (integer): browser_network_requests によって出力された、リクエストの1から始まるインデックス。
part (string, 任意): リクエストのこの部分のみを返します。省略すると完全な詳細を返します。
filename (string, 任意): 結果を保存するファイル名。指定しない場合、出力はテキストとして返されます。
読み取り専用: true
browser_network_requests
タイトル: ネットワークリクエストを一覧表示
説明: ページ読み込み以降のネットワークリクエストの番号付きリストを返します。完全な詳細を得るには番号を指定して browser_network_request を使用します。
パラメータ:
static (boolean): 画像、フォント、スクリプトなどの成功した静的リソースを含めるかどうか。デフォルトは false。
filter (string, 任意): この正規表現に一致する URL のリクエストのみを返します（例："/api/.*user"）。
filename (string, 任意): ネットワークリクエストを保存するファイル名。指定しない場合、リクエストはテキストとして返されます。
読み取り専用: true
browser_press_key
タイトル: キーを押す
説明: キーボードのキーを押します
パラメータ:
key (string): 押すキーの名前、または生成する文字（例：ArrowLeft や a）
読み取り専用: false
browser_resize
タイトル: ブラウザウィンドウのサイズ変更
説明: ブラウザウィンドウのサイズを変更します
パラメータ:
width (number): ブラウザウィンドウの幅
height (number): ブラウザウィンドウの高さ
読み取り専用: false
browser_run_code_unsafe
タイトル: Playwrightコードの実行（安全ではありません）
説明: Playwrightコードスニペットを実行します。安全ではありません：Playwrightサーバープロセス内で任意のJavaScriptを実行し、RCEと同等です。
パラメータ:
code (string, オプション): 実行するPlaywrightコードを含むJavaScript関数。単一の引数 page で呼び出され、ページ操作に使用できます。例: async (page) => { await page.getByRole('button', { name: 'Submit' }).click(); return await page.title(); }
filename (string, オプション): 指定されたファイルからコードを読み込みます。code と filename の両方が指定された場合、code は無視されます。
読み取り専用: false
browser_select_option
タイトル: オプションの選択
説明: ドロップダウンでオプションを選択します
パラメータ:
element (string, オプション): 要素との対話許可を得るために使用される人間が読める要素の説明
target (string): ページスナップショットからの正確なターゲット要素参照、または一意の要素セレクター
values (array): ドロップダウンで選択する値の配列。単一の値でも複数の値でもかまいません。
読み取り専用: false
browser_snapshot
タイトル: ページスナップショット
説明: 現在のページのアクセシビリティスナップショットを取得します。これはスクリーンショットより優れています。
パラメータ:
target (string, オプション): ページスナップショットからの正確なターゲット要素参照、または一意の要素セレクター
filename (string, オプション): スナップショットをレスポンスで返す代わりにマークダウンファイルに保存します。
depth (number, オプション): スナップショットツリーの深さを制限します
boxes (boolean, オプション): 各要素の境界ボックスをスナップショット内に [box=x,y,width,height] として含めます。座標はビューポート基準、CSSピクセル単位（Element.getBoundingClientRect）です。
読み取り専用: true
browser_take_screenshot
タイトル: スクリーンショットの撮影
説明: 現在のページのスクリーンショットを撮影します。スクリーンショットに基づいてアクションを実行することはできません。アクションには browser\_snapshot を使用してください。
パラメータ:
element (string, オプション): 要素との対話許可を得るために使用される人間が読める要素の説明
target (string, オプション): ページスナップショットからの正確なターゲット要素参照、または一意の要素セレクター
type (string, オプション): スクリーンショットの画像形式。未設定の場合はファイル名の拡張子から推測され、それ以外の場合は png になります。
filename (string, オプション): スクリーンショットを保存するファイル名。指定しない場合のデフォルトは page-{timestamp}.{png|jpeg|webp} です。出力ディレクトリ内に収めるため、相対ファイル名を推奨します。
fullPage (boolean, オプション): true の場合、現在表示されているビューポートではなく、ページ全体のスクロール可能なスクリーンショットを撮影します。要素のスクリーンショットとは併用できません。
scale (string): 画像解像度のスケール。"css" はCSSピクセル単位のスクリーンショットを生成します（小さく、デバイス間で一貫）。"device" はデバイスピクセルを使用した高解像度スクリーンショットを生成します（大きく、デバイスピクセル比を考慮）。デフォルトは css です。
読み取り専用: true
browser_type
タイトル: テキストの入力
説明: 編集可能な要素にテキストを入力します
パラメータ:
element (string, オプション): 要素との対話許可を得るために使用される人間が読める要素の説明
target (string): ページスナップショットからの正確なターゲット要素参照、または一意の要素セレクター
text (string): 要素に入力するテキスト
submit (boolean, オプション): 入力したテキストを送信するかどうか（その後 Enter を押す）
slowly (boolean, オプション): 一度に一文字ずつ入力するかどうか。ページ内のキーハンドラーをトリガーするのに便利です。デフォルトではテキスト全体が一度に入力されます。
読み取り専用: false
browser_wait_for
タイトル: 待機
説明: テキストが表示されるか消えるか、指定された時間が経過するのを待ちます
パラメータ:
time (number, オプション): 待機する時間（秒）
text (string, オプション): 待機するテキスト
textGone (string, オプション): 消えるのを待機するテキスト
読み取り専用: false
browser_tabs
タイトル: タブの管理
説明: ブラウザタブの一覧表示、作成、閉じる、または選択を行います。
パラメータ:
action (string): 実行する操作
index (number, オプション): タブインデックス。close/select に使用します。close で省略した場合、現在のタブが閉じられます。
url (string, オプション): 新しいタブで移動する URL。new に使用します。
読み取り専用: false
browser_get_config
タイトル: 設定の取得
説明: CLIオプション、環境変数、設定ファイルをマージした最終的な解決済み設定を取得します。
パラメータ: なし
読み取り専用: true
browser_network_state_set
タイトル: ネットワーク状態の設定
説明: ブラウザのネットワーク状態をオンラインまたはオフラインに設定します。オフラインの場合、すべてのネットワークリクエストは失敗します。
パラメータ:
state (string): オフラインモードをシミュレートするには "offline"、ネットワーク接続を復元するには "online" に設定します
読み取り専用: false
browser_route
タイトル: ネットワークリクエストのモック
説明: URLパターンに一致するネットワークリクエストをモックするルートを設定します
パラメータ:
pattern (string): 一致させるURLパターン（例："/api/users"、"/*.{png,jpg}"）
status (number, オプション): 返すHTTPステータスコード（デフォルト：200）
body (string, オプション): レスポンスボディ（テキストまたはJSON文字列）
contentType (string, オプション): Content-Type ヘッダー（例："application/json"、"text/html"）
headers (array, オプション): "名前: 値" 形式で追加するヘッダー
removeHeaders (string, オプション): リクエストから削除するヘッダー名のカンマ区切りリスト
読み取り専用: false
browser_route_list
タイトル: ネットワークルートの一覧表示
説明: アクティブなすべてのネットワークルートを一覧表示します
パラメータ: なし
読み取り専用: true
browser_unroute
タイトル: ネットワークルートの削除
説明: パターンに一致するネットワークルートを削除します（パターンを指定しない場合はすべてのルートを削除）
パラメータ:
pattern (string, オプション): 削除するURLパターン（省略するとすべてのルートを削除）
読み取り専用: false
browser_cookie_clear
タイトル: クッキーのクリア
説明: すべてのクッキーをクリアします
パラメータ: なし
読み取り専用: false
browser_cookie_delete
タイトル: クッキーの削除
説明: 特定のクッキーを削除します
パラメータ:
name (string): 削除するクッキー名
読み取り専用: false
browser_cookie_get
タイトル: クッキーの取得
説明: 名前で特定のクッキーを取得します
パラメータ:
name (string): 取得するクッキー名
読み取り専用: true
browser_cookie_list
タイトル: クッキーの一覧表示
説明: すべてのクッキーを一覧表示します（ドメイン/パスでフィルタリング可能）
パラメータ:
domain (string, オプション): ドメインでクッキーをフィルタリング
path (string, オプション): パスでクッキーをフィルタリング
読み取り専用: true
browser_cookie_set
タイトル: クッキーの設定
説明: オプションフラグ（domain, path, expires, httpOnly, secure, sameSite）付きでクッキーを設定します
パラメータ:
name (string): クッキー名
value (string): クッキーの値
domain (string, オプション): クッキーのドメイン
path (string, オプション): クッキーのパス
expires (number, オプション): Unixタイムスタンプとしてのクッキーの有効期限
httpOnly (boolean, オプション): クッキーがHTTPのみかどうか
secure (boolean, オプション): クッキーがセキュアかどうか
sameSite (string, オプション): クッキーのSameSite属性
読み取り専用: false
browser_localstorage_clear
タイトル: localStorageのクリア
説明: すべてのlocalStorageをクリアします
パラメータ: なし
読み取り専用: false
browser_localstorage_delete
タイトル: localStorage項目の削除
説明: localStorage項目を削除します
パラメータ:
key (string): 削除するキー
読み取り専用: false
browser_localstorage_get
タイトル: localStorage項目の取得
説明: キーでlocalStorage項目を取得します
パラメータ:
key (string): 取得するキー
読み取り専用: true
browser_localstorage_list
タイトル: localStorageの一覧表示
説明: すべてのlocalStorageのキーと値のペアを一覧表示します
パラメータ: なし
読み取り専用: true
browser_localstorage_set
タイトル: localStorage項目の設定
説明: localStorage項目を設定します
パラメータ:
key (string): 設定するキー
value (string): 設定する値
読み取り専用: false
browser_sessionstorage_clear
タイトル: sessionStorageのクリア
説明: すべてのsessionStorageをクリアします
パラメータ: なし
読み取り専用: false
browser_sessionstorage_delete
タイトル: sessionStorage項目の削除
説明: sessionStorage項目を削除します
パラメータ:
key (string): 削除するキー
読み取り専用: false
browser_sessionstorage_get
タイトル: sessionStorage項目の取得
説明: キーでsessionStorage項目を取得します
パラメータ:
key (string): 取得するキー
読み取り専用: true
browser_sessionstorage_list
タイトル: sessionStorageの一覧表示
説明: すべてのsessionStorageのキーと値のペアを一覧表示します
パラメータ: なし
読み取り専用: true
browser_sessionstorage_set
タイトル: sessionStorage項目の設定
説明: sessionStorage項目を設定します
パラメータ:
key (string): 設定するキー
value (string): 設定する値
読み取り専用: false
browser_sessionstorage_set
タイトル: sessionStorageのアイテムを設定
説明: sessionStorageのアイテムを設定します
パラメータ:
key (string): 設定するキー
value (string): 設定する値
読み取り専用: false
browser_set_storage_state
タイトル: ストレージ状態を復元
説明: ファイルからストレージ状態（クッキー、ローカルストレージ）を復元します。復元前に既存のクッキーとローカルストレージをクリアします。
パラメータ:
filename (string): 復元元のストレージ状態ファイルへのパス
読み取り専用: false
browser_storage_state
タイトル: ストレージ状態を保存
説明: ストレージ状態（クッキー、ローカルストレージ）をファイルに保存し、後で再利用できるようにします
パラメータ:
filename (string, オプション): ストレージ状態を保存するファイル名。指定しない場合のデフォルトはstorage-state-{timestamp}.jsonです。
読み取り専用: true
browser_annotate
タイトル: 現在のページに注釈を付ける
説明: 現在のページでPlaywrightダッシュボードを注釈モードで開き、ユーザーが注釈を描画するのを待ちます。注釈付きスクリーンショット、ARIAスナップショット、および注釈のリストを返します。
パラメータ: なし
読み取り専用: true
browser_hide_highlight
タイトル: 要素のハイライトを非表示
説明: 要素に以前追加されたハイライトオーバーレイを削除します。
パラメータ:
element (string, オプション): ハイライト追加時に使用された人間が読める要素の説明。browser_highlightに渡された値と一致する必要があります。
target (string, オプション): ページスナップショットからの正確なターゲット要素参照、または一意の要素セレクタ
読み取り専用: true
browser_highlight
タイトル: 要素をハイライト
説明: ページ上の要素の周りに永続的なハイライトオーバーレイを表示します。
パラメータ:
element (string, オプション): 要素とのインタラクション許可を得るために使用される人間が読める要素の説明
target (string): ページスナップショットからの正確なターゲット要素参照、または一意の要素セレクタ
style (string, オプション): ハイライトオーバーレイに適用される追加のインラインCSS。例: "outline: 2px dashed red"。
読み取り専用: true
browser_resume
タイトル: 一時停止したスクリプト実行を再開
説明: 一時停止後のスクリプト実行を再開します。stepがtrueに設定されている場合、次のアクションの前に実行が再度一時停止します。
パラメータ:
step (boolean, オプション): trueの場合、次のアクションの前に実行が再度一時停止し、ステップバイステップのデバッグが可能になります。
location (string, オプション): 特定の:で実行を一時停止します。例: "example.spec.ts:42"。
読み取り専用: false
browser_start_tracing
タイトル: トレースを開始
説明: トレースの記録を開始します
パラメータ: なし
読み取り専用: true
browser_start_video
タイトル: ビデオを開始
説明: ビデオの記録を開始します
パラメータ:
filename (string, オプション): ビデオを保存するファイル名。
size (object, オプション): ビデオサイズ
読み取り専用: true
browser_stop_tracing
タイトル: トレースを停止
説明: トレースの記録を停止します
パラメータ: なし
読み取り専用: true
browser_stop_video
タイトル: ビデオを停止
説明: ビデオの記録を停止します
パラメータ: なし
読み取り専用: true
browser_video_chapter
タイトル: ビデオチャプター
説明: ビデオ録画にチャプターマーカーを追加します。ぼかし背景の全画面チャプターカードを表示します。
パラメータ:
title (string): チャプタータイトル
description (string, オプション): チャプターの説明
duration (number, オプション): チャプターカードを表示する時間（ミリ秒）
読み取り専用: true
browser_video_hide_actions
タイトル: アクションオーバーレイを非表示
説明: ページ上で実行されたアクションへの注釈付けを停止します。
パラメータ: なし
読み取り専用: true
browser_video_show_actions
タイトル: アクションオーバーレイを表示
説明: ページ上で実行される後続のアクションに、アクション名を示すコールアウトとターゲット要素のハイライトを付けて注釈します。ビデオ録画やスクリーンキャスト中に便利です。
パラメータ:
duration (number, オプション): 各アクション注釈の画面表示時間（ミリ秒）。デフォルトは500。
position (string, オプション): ページに対するアクションタイトルの配置場所。デフォルトは右上。
cursor (string, オプション): ポインターアクションのカーソル装飾。"pointer"（デフォルト）はマウスポインターを前のアクションポイントから次のアクションポイントへアニメーション表示します。"none"はカーソル装飾を無効にします。
読み取り専用: true
browser_mouse_click_xy
タイトル: クリック
説明: 指定された位置でマウスボタンをクリックします
パラメータ:
x (number): X座標
y (number): Y座標
button (string, オプション): クリックするボタン。デフォルトは左
clickCount (number, オプション): クリック回数。デフォルトは1
delay (number, オプション): マウスダウンとマウスアップの間の待機時間（ミリ秒）。デフォルトは0
読み取り専用: false
browser_mouse_down
タイトル: マウスダウンを押す
説明: マウスダウンを押します
パラメータ:
button (string, オプション): 押すボタン。デフォルトは左
読み取り専用: false
browser_mouse_drag_xy
タイトル: マウスをドラッグ
説明: 左マウスボタンを指定された位置までドラッグします
パラメータ:
startX (number): 開始X座標
startY (number): 開始Y座標
endX (number): 終了X座標
endY (number): 終了Y座標
読み取り専用: false
browser_mouse_move_xy
タイトル: マウスを移動
説明: マウスを指定された位置に移動します
パラメータ:
x (number): X座標
y (number): Y座標
読み取り専用: false
browser_mouse_up
タイトル: マウスアップを押す
説明: マウスアップを押します
パラメータ:
button (string, オプション): 押すボタン。デフォルトは左
読み取り専用: false
browser_mouse_wheel
タイトル: マウスホイールをスクロール
説明: マウスホイールをスクロールします
パラメータ:
deltaX (number): X方向のデルタ
deltaY (number): Y方向のデルタ
読み取り専用: false
browser_pdf_save
タイトル: PDFとして保存
説明: ページをPDFとして保存します
パラメータ:
filename (string, オプション): PDFを保存するファイル名。指定しない場合のデフォルトはpage-{timestamp}.pdfです。出力ディレクトリ内に収めるため、相対ファイル名を推奨します。
読み取り専用: true
browser_generate_locator
タイトル: 要素のロケーターを作成
説明: 指定された要素のロケーターを生成し、テストで使用できるようにします
パラメータ:
element (string, オプション): 要素とのインタラクション許可を得るために使用される人間が読める要素の説明
target (string): ページスナップショットからの正確なターゲット要素参照、または一意の要素セレクタ
読み取り専用: true
browser_verify_element_visible
タイトル: 要素の可視性を確認
説明: 要素がページ上に表示されていることを確認します
パラメータ:
role (string): 要素のROLE。スナップショット内で - {ROLE} "Accessible Name": のように見つけられます。
accessibleName (string): 要素のACCESSIBLE_NAME。スナップショット内で - role "{ACCESSIBLE_NAME}" のように見つけられます。
読み取り専用: false
browser_verify_list_visible
タイトル: リストの可視性を確認
説明: リストがページ上に表示されていることを確認します
パラメータ:
element (string): 人間が読めるリストの説明
target (string): リストを指す正確なターゲット要素参照
items (array): 確認するアイテム
読み取り専用: false
browser_verify_text_visible
タイトル: テキストの可視性を確認
説明: テキストがページ上に表示されていることを確認します。可能であればbrowser_verify_element_visibleを優先してください。
パラメータ:
text (string): 確認するTEXT。スナップショット内で - role "Accessible Name": {TEXT} または - text: {TEXT} のように見つけられます。
読み取り専用: false
browser_verify_value
タイトル: 値を確認
説明: 要素の値を確認します
パラメータ:
type (string): 要素のタイプ
element (string): 人間が読める要素の説明
target (string): ページスナップショットからの正確なターゲット要素参照
value (string): 確認する値。チェックボックスの場合は "true" または "false" を使用します。
読み取り専用: false
Perform click on a web page
| Name | Required | Description | Default |
|---|---|---|---|
| button | No | Button to click, defaults to left | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| modifiers | No | Modifier keys to press | |
| doubleClick | No | Whether to perform a double click instead of a single click |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true, indicating the tool mutates state and can be destructive. The description adds no further behavioral disclosure, such as possible navigation or permission requirements. It does not contradict annotations, but provides no value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. However, it is terse and omits useful context that could be added without bloat, such as the requirement for a snapshot target. It is appropriately sized but not front-loaded with any distinguishing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema), the description alone is minimally sufficient because the schema fully describes parameters. However, it lacks context about return values, when to use click vs other actions, and potential side effects. The schema covers parameter semantics, so a score of 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with every parameter documented (e.g., target is 'Exact target element reference from the page snapshot, or a unique element selector'). The description itself adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Perform click') and the resource ('web page'), which is specific enough. However, it does not differentiate from sibling interaction tools like browser_hover or browser_drag; the agent must infer that 'click' is a distinct action without additional context. It is unambiguous about the core operation but lacks detail on the target element requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites such as needing a page snapshot to obtain a valid target, nor does it contrast with browser_hover or browser_drag. An agent receives no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the page
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already indicates destructiveHint=true, so the agent knows the action is destructive. The description simply repeats that by saying 'close' without adding any extra context about side effects (e.g., whether it closes just the current tab, loses unsaved state, or affects other tabs). It does not contradict the annotation, but it adds no new behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only three words. It communicates the essential action and target without any fluff, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description is functional but lacks completeness. It leaves open the scope of 'close'—does it close the current page/tab, or the entire browser? In a context with sibling tools like browser_tabs, this ambiguity could be problematic. More detail would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is trivially complete at 100%. The description does not need to explain any parameter semantics, and the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Close the page' clearly states the action (close) and the resource (page), making it unambiguous. It is distinct from sibling tools like browser_navigate or browser_snapshot, so an agent can easily identify it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention potential alternatives (e.g., using browser_tabs to manage multiple pages) or any conditions that would make closing appropriate. The context is minimal and leaves the decision entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all console messages
| Name | Required | Description | Default |
|---|---|---|---|
| all | No | Return all console messages since the beginning of the session, not just since the last navigation. Defaults to false. | |
| level | Yes | Level of the console messages to return. Each level includes the messages of more severe levels. Defaults to "info". | info |
| filename | No | Filename to save the console messages to. If not provided, messages are returned as text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint true and destructiveHint false, so the description adds no conflicting side-effect information. It does not elaborate on behavior such as saving to a file, but that is covered by parameter descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundancy, front-loading the verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with full schema coverage, the description is adequate, though it omits explicit use-case guidance and output format details beyond what the schema provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions, so the tool description itself does not add meaning beyond the schema, but no parameter meaning is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Returns' and identifies the resource 'console messages' with scope 'all', making the tool's purpose clear and distinct from sibling tools such as network request retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like browser_network_requests or browser_snapshot, nor does it mention filtering or filename-saving scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform drag and drop between two elements
| Name | Required | Description | Default |
|---|---|---|---|
| endTarget | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| endElement | No | Human-readable target element description used to obtain the permission to interact with the element | |
| startTarget | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| startElement | No | Human-readable source element description used to obtain the permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds no extra behavioral context such as side effects on the DOM or event firing, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and provides the core information without any irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action with well-described parameters and no output schema, the description is mostly complete. It does not mention any return values or wait behavior, but the lack of output schema makes this acceptable. It could have added a note about the order of start and end parameters, but the parameter names and descriptions handle that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all four parameters described. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (perform drag and drop) and the resource (between two elements), distinguishing it from sibling tools like browser_click, browser_hover, and browser_drop. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It does not mention conditions such as needing to move an element or triggering drag-and-drop events, nor does it reference sibling tools like browser_drop or browser_click.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drop files or MIME-typed data onto an element, as if dragged from outside the page. At least one of "paths" or "data" must be provided.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Data to drop, as a map of MIME type to string value (e.g. {"text/plain": "hello", "text/uri-list": "https://example.com"}). | |
| paths | No | Absolute paths to files to drop onto the element. | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey destructive and non-read-only behavior, so the description does not need to repeat that. The description adds useful semantic context about simulating an external drag, but does not disclose any side effects beyond the basic drop action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that concisely explains both the action and the key parameter requirement. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the detailed schema and annotations, provides enough information to invoke the tool correctly. There is no output schema, so return-value details are not required, and the parameter permission explanation is handled by the 'element' field description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have clear schema descriptions. The tool description adds an important cross-parameter constraint that at least one of 'paths' or 'data' must be provided, which is not otherwise expressed in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: dropping files or MIME-typed data onto an element. It uses a specific verb and resource, and distinguishes itself from in-page drag operations by specifying 'as if dragged from outside the page'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a useful usage constraint ('At least one of paths or data must be provided') and hints at external drag context, but it does not explicitly name sibling tools or state when to prefer this over browser_file_upload or browser_drag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate JavaScript expression on page or element
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| filename | No | Filename to save the result to. If not provided, result is returned as text. | |
| function | Yes | () => { /* code */ } or (element) => { /* code */ } when element is provided |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and readOnlyHint=false, so the agent knows this can modify state. The description adds minimal context beyond that—it mentions 'on page or element' but doesn't warn about the power of arbitrary JS execution or potential side effects. Since the annotation covers the destructive nature, the description's lack of extra detail keeps it at a baseline 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no redundant words. The action is front-loaded and easy to parse. This is appropriately concise for a tool whose parameter details are already in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this tool executes arbitrary JavaScript with destructive potential, the description is too sparse. It doesn't mention that the function can modify the page, that results can be saved to a file (though schema covers it), or that there is a separate unsafe variant (browser_run_code_unsafe) that might be more appropriate for certain tasks. The description lacks the context an agent needs to safely and correctly use this tool, especially when annotations already warn about destructiveness but the description provides no additional guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are documented in the schema itself. The description does not add any meaning beyond what the schema provides—it doesn't elaborate on the function syntax, target usage, or filename behavior. With high schema coverage, the baseline is 3, and the description contributes nothing extra.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Evaluate' and the resource 'JavaScript expression on page or element', making the core purpose obvious. However, it doesn't distinguish from the sibling browser_run_code_unsafe, which might also execute code, so it loses a point for not differentiating between similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like browser_run_code_unsafe or when to avoid it. No context about prerequisites (e.g., page must be loaded) or scenarios that favor this tool over others. The description simply states the action without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload one or multiple files
| Name | Required | Description | Default |
|---|---|---|---|
| paths | No | The absolute paths to the files to upload. Can be single file or multiple files. If omitted, file chooser is cancelled. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructive behavior and non-read-only semantics, so the description does not need to restate those. However, the description does not mention side effects beyond uploading, such as navigating away, opening or cancelling a file chooser, or potential overwrite behavior, though the parameter description partially covers the cancellation case.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and free of filler. Every word contributes meaning, and the parameter description adds necessary details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description and parameter comment cover the essential input and basic behavior. However, it does not describe what happens after the upload, what success or failure looks like, or how this fits into the broader browser automation workflow, leaving some practical context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines an array of strings, but the parameter description adds important meaning: paths must be absolute, multiple files are allowed, and omitting the parameter cancels the file chooser. This goes beyond the raw schema and helps an agent use the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Upload') and the resource ('files'), and specifies 'one or multiple'. It does not explicitly state the destination or context, but the tool name and sibling set make the browser file-upload intent sufficiently clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as browser_drop or other browser interaction tools. It also does not mention prerequisites like whether the file chooser must already be open or how paths should be formatted beyond 'absolute'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill multiple form fields
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | Fields to fill in |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=false and destructiveHint=true, so the write and potentially destructive nature is covered. The description adds the 'multiple form fields' detail but does not disclose additional behavior such as overwriting values or submitting the form.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundant words or boilerplate. It is appropriately short and easy to parse, though it sacrifices deeper context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The rich schema fully documents the nested field objects, including target references, type-specific value behavior, and permission-related element descriptions. Combined with the read-only and destructive annotations, the description is sufficient for correct invocation; only alternative-selection guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the fields array and its nested target, name, type, value, and element properties all have descriptive text. The description itself does not add parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fill multiple form fields' clearly identifies the action and resource, and the word 'multiple' helps distinguish it from single-field tools like browser_type. It does not explicitly contrast with sibling tools, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool instead of alternatives such as browser_type, browser_select_option, or browser_click. The term 'multiple' implies batch usage, but there is no explicit when-to-use or exclusion context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the accessibility snapshot of the current page for text or a regular expression. Returns matching snapshot nodes with a few lines of surrounding context (like search snippets), each shown under its path from the root of the tree, which is cheaper than capturing the whole snapshot when you only need to locate an element and its ref.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Plain text to search for in the page snapshot (case-insensitive substring match). Provide either text or regex, not both. | |
| regex | No | Regular expression to search for in the page snapshot. Matching is case-sensitive by default; wrap the pattern in slashes to add flags, e.g. "/error/i" for case-insensitive. Provide either text or regex, not both. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive behavior. The description adds useful behavioral detail about return format, surrounding context, path-from-root presentation, and cost characteristics. It is consistent with the annotations, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense, well-structured sentence that front-loads the action and then provides the output shape and the key trade-off. There is no filler or redundancy; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains return shape and the main use case, and annotations cover safety. However, since neither parameter is marked required in the schema, the description could more explicitly instruct the agent to provide exactly one of text or regex.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; both text and regex are already documented with mutual exclusivity and regex flag syntax. The description adds no parameter-level meaning beyond restating that either text or regex is used, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search'), a clear resource ('the accessibility snapshot of the current page'), and a well-defined result (matching snapshot nodes with surrounding context and refs). It also distinguishes itself from the whole-snapshot sibling by explaining its narrower focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear when-to-use condition: this is 'cheaper than capturing the whole snapshot when you only need to locate an element and its ref.' It implicitly contrasts with browser_snapshot but does not explicitly name the sibling or state when NOT to use this tool, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Handle a dialog
| Name | Required | Description | Default |
|---|---|---|---|
| accept | Yes | Whether to accept the dialog. | |
| promptText | No | The text of the prompt in case of a prompt dialog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate readOnlyHint=false and destructiveHint=true, covering the main safety aspect. However, the description adds no detail about side effects, such as submitting a form or canceling a prompt, beyond what the parameter names imply. It does not clearly disclose the consequences of accepting or rejecting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and lacks necessary detail, making it under-specified. It is terse but not informative enough to guide an agent effectively, similar to a placeholder like 'Process'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or additional context is provided. The description does not explain what happens after handling the dialog, how the parameters interact, or any post-conditions. This is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both 'accept' (boolean) and 'promptText' (string for prompt dialogs). The description does not add extra meaning, but the schema already provides adequate parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Handle a dialog' identifies the action and resource but is vague. It does not specify the type of dialog (alert, confirm, prompt) or the precise effect, though the 'accept' parameter implies accept/dismiss. It is distinct from sibling tools, but the purpose is under-specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool, such as after a dialog appears or in contrast to other browser actions. The description gives no context for the appropriate situation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hover over element on page
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=true, so the description doesn't need to re-state them. The description adds no extra behavioral detail about side effects (e.g., triggering JavaScript events, potential menu changes). With annotations present, the bar is lower, but there's still room for more transparency about outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—six words, no redundancy, and perfectly focused on the action. It follows a clear verb-object structure with no extra fluff, making it easy to parse and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple interaction tool, the description, alongside the parameter schema and annotations, is adequate. It lacks details on return values (but no output schema exists) and does not mention any prerequisites or setup. Given the simplicity, it covers essential context without being overlong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (target and element) have descriptions in the schema, achieving 100% coverage. The tool description does not add further meaning beyond the schema; it simply restates the action. Since schema coverage is complete, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (hover) and the target (element on page). It distinguishes itself from sibling tools like click, drag, and type by specifying the hover action. However, it lacks detail about what the hover does (e.g., showing tooltips or hover menus), but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use hover versus other interactions. While it's intuitive that hover is for mouse-over actions, the description doesn't mention edge cases or alternative tools (e.g., use click for activating, hover for previews). It provides minimal implicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns full details (headers and body) of a single network request, or a single part if part is set. Use the number from browser_network_requests.
| Name | Required | Description | Default |
|---|---|---|---|
| part | No | Return only this part of the request. Omit to return full details. | |
| index | Yes | 1-based index of the request, as printed by browser_network_requests. | |
| filename | No | Filename to save the result to. If not provided, output is returned as text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds that it returns headers and body and can filter to a part, but does not elaborate on output structure or edge cases. Given annotation coverage, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant wording. The main purpose is front-loaded, the part option is explained, and the source of the index is given. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only retrieval tool with full schema coverage and annotations, the description is sufficient. It explains the return type (full details or part) and the index source. It lacks explicit output format details, but the enum values for 'part' are self-explanatory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters, so the schema already documents them. The description adds critical value by explaining that 'index' comes from browser_network_requests, which is not in the schema, enhancing clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns full details of a single network request, with an optional 'part' parameter to narrow down. It distinguishes from the sibling tool browser_network_requests by referencing its index, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Use the number from browser_network_requests' explicitly guides when to use this tool—after obtaining a listing. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a numbered list of network requests since loading the page. Use browser_network_request with the number to get full details.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Only return requests whose URL matches this regexp (e.g. "/api/.*user"). | |
| static | Yes | Whether to include successful static resources like images, fonts, scripts, etc. Defaults to false. | |
| filename | No | Filename to save the network requests to. If not provided, requests are returned as text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable context about the temporal scope ('since loading the page') and the numbered list format, which goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. The primary action is front-loaded, and the companion tool reference is placed efficiently at the end. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description tells the agent what the tool returns (a numbered list) and how to proceed for details. Since there is no output schema, this is essential. It does not describe potential error cases or edge scenarios, but for a read-only list tool with strong schema coverage, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions covering 100% of the input schema. The tool description does not add any additional meaning to the parameters themselves, so the baseline of 3 applies; it neither enhances nor detracts from what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a numbered list of network requests since page load, and explicitly differentiates from the sibling tool browser_network_request by instructing to use that tool for details. This is a specific verb+resource with a clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage pattern: first call this tool to get a list, then use browser_network_request with the number for full details. This is clear guidance on when to use it versus its companion, though it does not mention any other alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Press a key on the keyboard
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Name of the key to press or a character to generate, such as `ArrowLeft` or `a` |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not mention any side effects, such as triggering keyboard events or potential destructive behavior. The annotations indicate destructiveHint: true, but the description adds no additional behavioral context beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise — a single sentence that directly conveys the action. No unnecessary information or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action with a single well-defined parameter, the description is adequate. It lacks mention of when to use this tool (e.g., for shortcuts or navigation keys) but is otherwise complete for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'key' is fully described in the schema with examples, and schema coverage is 100%. The description adds minimal extra meaning ('on the keyboard') but doesn't clarify key formats or special keys, which is already covered by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (press) and the resource (key on the keyboard). It is distinct from broader actions like navigate or click, though it does not explicitly differentiate from browser_type (typing) or browser_click (clicking).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings (e.g., browser_type for text entry or browser_click for mouse actions). The description lacks any contextual cues for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resize the browser window
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | Width of the browser window | |
| height | Yes | Height of the browser window |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the bare action. Annotations already indicate it is not read-only and is destructive, but the description adds no extra context about side effects like layout reflows or potential viewport changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short declarative sentence with no unnecessary words. It is perfectly concise and well-structured for the simple action it describes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description is adequate, but it lacks any extra context such as units (e.g., pixels), constraints, or when resizing might be appropriate. Given the simplicity and schema coverage, it is minimally complete but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (width and height), achieving 100% coverage. The description adds no additional meaning about the parameters, so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (resize) and the resource (browser window), making it distinct from sibling tools like navigate or click. However, it lacks any nuance about whether it resizes the viewport or the entire window, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention scenarios like adjusting viewport for responsive testing or any conditions that would make it preferable to other navigation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Playwright code snippet. Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | A JavaScript function containing Playwright code to execute. It will be invoked with a single argument, page, which you can use for any page interaction. For example: `async (page) => { await page.getByRole('button', { name: 'Submit' }).click(); return await page.title(); }` | |
| filename | No | Load code from the specified file. If both code and filename are provided, code will be ignored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so the description's 'Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent' adds specific severity and mechanism beyond the generic flags. This enhances transparency without contradicting annotations, though it could also mention side effects or sandboxing if any.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs purpose and a crucial warning. It front-loads the action and immediately follows with the risk, maximizing information density with zero filler. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (arbitrary code execution) and the lack of an output schema, the description does not mention the return value or error behavior. The example in the code parameter shows a return, but that's in the schema. For an advanced tool, this is a notable gap, but the core purpose and danger are clear. A 3 reflects the missing return semantics and operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with detailed descriptions, including the precedence rule for code vs filename. The tool description adds no additional parameter meaning beyond the schema, so a baseline of 3 is appropriate. The schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Run a Playwright code snippet.' It specifies the resource (Playwright code) and immediately flags the critical distinction from siblings with 'Unsafe: executes arbitrary JavaScript ... RCE-equivalent.' This unambiguous verb+resource plus the danger label leaves no ambiguity about what the tool does and separates it from all other browser tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a strong warning about safety ('Unsafe', 'RCE-equivalent') but does not explicitly state when to use it versus alternatives. It implies it's for advanced custom logic, but there is no direct 'use this only if...' or mention of safer alternatives. The warning serves as a caution but not a full usage guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select an option in a dropdown
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| values | Yes | Array of values to select in the dropdown. This can be a single value or multiple values. | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive=true, so the description does not contradict that. But the description adds no further behavioral detail (e.g., side effects on the page). With annotations present, the bar is lower, and the description is neutral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is well-structured and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers all parameters. The description is short but sufficient for a basic understanding. It does not specify whether values are labels or values, but that is a minor omission given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions for target and values. The tool description itself does not explain parameters beyond what the schema already provides, so it adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (select) and the target (option in a dropdown), distinguishing it from more general actions like click or type. However, it does not explicitly contrast with sibling tools, so it misses a bit of distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when selecting is appropriate or when other actions (e.g., click, type) might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture accessibility snapshot of the current page, this is better than screenshot
| Name | Required | Description | Default |
|---|---|---|---|
| boxes | No | Include each element's bounding box as [box=x,y,width,height] in the snapshot. Coordinates are viewport-relative, in CSS pixels (Element.getBoundingClientRect) | |
| depth | No | Limit the depth of the snapshot tree | |
| target | No | Exact target element reference from the page snapshot, or a unique element selector | |
| filename | No | Save snapshot to markdown file instead of returning it in the response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds 'capture' but no further behavioral detail beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. The phrase 'this is better than screenshot' adds some comparative value but could be considered slightly extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and the description does not explain what format the snapshot takes, how parameters like depth or target affect the result, or what kind of accessibility information is included. This leaves important context missing for an agent deciding whether and how to call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters with descriptions, so the baseline is 3. The description does not add any additional parameter meaning or usage notes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear action ('capture') and object ('accessibility snapshot of the current page'), and distinguishes itself from screenshot with a comparative remark, though 'better than screenshot' is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives minimal guidance by saying 'better than screenshot', but does not explicitly state when to use this tool over alternatives like browser_evaluate or browser_console_messages, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List, create, close, or select a browser tab.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to in the new tab, used for new. | |
| index | No | Tab index, used for close/select. If omitted for close, current tab is closed. | |
| action | Yes | Operation to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. However, the description adds no behavioral context beyond what the schema provides (e.g., index omission for close closes current tab is in schema). No mention of side effects like tab switching or browser-level changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists all supported actions. It is front-loaded with verbs and avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has multiple actions and a required action parameter. The description lists the actions but does not explain action-specific requirements (e.g., URL required for new, index for close/select) or edge cases like closing the last tab. Given the schema covers parameter details, the description is adequate but not rich. With no output schema, the agent must infer return values from the action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter having a description (url, index, action with enum). The tool description adds no parameter-level detail, so it does not go beyond schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs (list, create, close, select) and a specific resource (browser tab). It distinguishes from siblings like browser_close (closes the entire browser) and browser_navigate (navigates current tab) by focusing on tab operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the list of actions but provides no explicit when-to-use guidance or exclusions. Given siblings like browser_close (closes the entire browser) and browser_navigate (navigates current tab), an agent might benefit from explicit differentiation, but the actions themselves are clear enough that usage is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of the current page. You can't perform actions based on the screenshot, use browser_snapshot for actions.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Image format for the screenshot. If unset, inferred from the filename extension, otherwise png. | |
| scale | Yes | Image resolution scale. "css" produces a screenshot sized in CSS pixels (smaller, consistent across devices). "device" produces a high-resolution screenshot using device pixels (larger, accounts for the device pixel ratio). Default is css. | css |
| target | No | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| filename | No | File name to save the screenshot to. Defaults to `page-{timestamp}.{png|jpeg|webp}` if not specified. Prefer relative file names to stay within the output directory. | |
| fullPage | No | When true, takes a screenshot of the full scrollable page, instead of the currently visible viewport. Cannot be used with element screenshots. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds a key behavioral trait: the output is not interactive ('You can't perform actions based on the screenshot'), which is not captured by annotations. This adds meaningful context about the tool's limitations beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant phrasing. The core purpose is stated first, followed by a critical limitation and alternative, maximizing informativeness per word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only screenshot tool with comprehensive schema documentation and safety annotations, the description covers the essential decision points: when to use it and when not to. It doesn't explain return formats or error handling, but those are less critical given the tool's simplicity and the annotations' coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for all 6 parameters. The description adds no parameter-specific information, and the baseline of 3 is appropriate since the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Take') and resource ('screenshot of the current page'). Explicitly distinguishes from browser_snapshot by stating what it is not for ('You can't perform actions based on the screenshot'), making it clear which tool to use for captures vs. interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-not-to-use guidance: 'You can't perform actions based on the screenshot' and directs to the alternative 'use browser_snapshot for actions'. This clearly routes an agent to the correct tool for interactive needs while implying this tool is for visual captures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into editable element
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to type into the element | |
| slowly | No | Whether to type one character at a time. Useful for triggering key handlers in the page. By default entire text is filled in at once. | |
| submit | No | Whether to submit entered text (press Enter after) | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true and readOnlyHint=false already signal that this tool can modify state, so the description does not contradict that. However, the main description adds no additional behavioral context beyond the annotations, such as whether typing overwrites existing content or triggers page events. The parameter descriptions do mention key-handler triggering and Enter submission, but the main description itself stays shallow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or repetition. It front-loads the verb and object, making the tool's primary purpose immediately obvious.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with several closely related siblings (fill_form, press_key, click), the description is too thin to fully orient an agent. It lacks any mention of when typing is appropriate, how the target is resolved, or what side effects to expect, so the agent must rely on parameter descriptions and external context to make a confident choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3 because the input schema already documents all five parameters. The main description, 'Type text into editable element,' adds no meaning beyond the schema's parameter descriptions, which already define text, slowly, submit, target, and element clearly enough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Type text') and a clear target ('editable element'), which distinguishes it from many sibling tools at a high level. It is slightly vague about whether 'editable element' includes textareas, contenteditable regions, or only input fields, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to prefer this tool over sibling tools such as browser_fill_form or browser_press_key. It does not mention exclusions, prerequisites, or scenarios where typing would be inappropriate, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for text to appear or disappear or a specified time to pass
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | The text to wait for | |
| time | No | The time to wait in seconds | |
| textGone | No | The text to wait for to disappear |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral detail beyond the readOnlyHint by explaining that it waits for text appearance/disappearance or a time delay. However, it does not specify what happens if multiple parameters are provided or if none are provided, so behavior is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and conditions. It contains no unnecessary words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple wait tool with no output schema, the description covers the main use cases, but it omits edge cases such as default behavior when no parameters are supplied, timeout behavior, or error conditions. These gaps make it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions already cover each parameter individually, and the tool description mostly restates them. It does not clarify the relationship between text, textGone, and time (e.g., whether they are mutually exclusive or combinable), so minimal semantic value is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for a condition: text to appear, text to disappear, or a specified time to pass. This distinguishes it from sibling tools like click, navigate, or type, and its purpose is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when waiting for page state or a delay), but it does not explicitly state when to prefer this over alternatives or how to choose among text, textGone, and time parameters. It provides functional guidance but lacks explicit usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.0.79browser_clickbrowser_closebrowser_console_messagesbrowser_dragbrowser_dropbrowser_evaluatebrowser_file_uploadbrowser_fill_formbrowser_findbrowser_handle_dialogbrowser_hoverbrowser_navigatebrowser_navigate_backbrowser_network_requestbrowser_network_requestsbrowser_press_keybrowser_resizebrowser_run_code_unsafebrowser_select_optionbrowser_snapshotbrowser_tabsbrowser_take_screenshotbrowser_typebrowser_wait_forScored across 24 tools
Each tool has a clearly distinct purpose, covering actions like navigation, clicking, typing, screenshots, network requests, file upload, and dialog handling. Even similar tools like browser_snapshot and browser_take_screenshot are differentiated by their intended use (actions vs. visual capture).
All tools share the 'browser_' prefix, and most follow a verb_noun or verb pattern (e.g., browser_click, browser_fill_form). However, a few are noun-based (e.g., browser_network_requests, browser_tabs) which breaks the verb-first convention slightly, but the overall pattern remains predictable.
With 24 tools, the set is extensive but well-scoped for a full browser automation server. Each tool addresses a specific operation, and the count is appropriate for the domain, though it borders on the heavier side.
The toolset covers core browser automation workflows: navigation, clicks, forms, network, screenshots, accessibility, dialogs, file upload, and tabs. Minor gaps exist (e.g., no direct tool for scrolling or getting current URL), but these do not significantly hinder common agent tasks.
E2LLM gives your AI eyes and hands in a real browser: structured perception (SiFR) plus action.
Official Browserless MCP server: browser automation, scraping, screenshots and PDFs for AI agents.
Control a real browser from AI agents: navigate, click, type, screenshot, read the page.
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.