Playwrightを用いたブラウザ自動化機能を提供するモデルコンテキストプロトコル（MCP）サーバー。このサーバーにより、LLMは構造化されたアクセシビリティスナップショットを通じてWebページと対話できるようになり、スクリーンショットや視覚的に調整されたモデルを必要としません。
高速かつ軽量。ピクセルベースの入力ではなく、Playwright のアクセシビリティ ツリーを使用します。
LLM 対応。ビジョンモデルは必要なく、純粋に構造化データ上で動作します。
決定論的なツールアプリケーション。スクリーンショットベースのアプローチでよくある曖昧さを回避します。
Node.js 18以降
VS Code、Cursor、Windsurf、Claude Desktop、その他のMCPクライアント
まず、クライアントにPlaywright MCPサーバーをインストールします。典型的な構成は以下のとおりです。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}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 エージェントで使用できるようになります。
Cursor Settings -> MCP -> Add new MCP Serverに進みます。お好みの名前を入力し、 commandタイプを使用してnpx @playwright/mcpコマンドを実行します。 Editをクリックして設定を確認したり、コマンドのような引数を追加したりすることもできます。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}Windsuff MCPドキュメントに従ってください。以下の設定を使用してください。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}MCP インストールガイドに従って、次の構成を使用します。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}Playwright MCPサーバーは以下の引数をサポートしています。これらは上記のJSON設定の"args"リストの一部として指定できます。
> npx @playwright/mcp@latest --help
--allowed-origins <origins> semicolon-separated list of origins to allow the
browser to request. Default is to allow all.
--blocked-origins <origins> semicolon-separated list of origins to block the
browser from requesting. Blocklist is evaluated
before allowlist. If used without the allowlist,
requests not matching the blocklist are still
allowed.
--block-service-workers block service workers
--browser <browser> browser or chrome channel to use, possible
values: chrome, firefox, webkit, msedge.
--caps <caps> comma-separated list of capabilities to enable,
possible values: tabs, pdf, history, wait, files,
install. Default is all.
--cdp-endpoint <endpoint> CDP endpoint to connect to.
--config <path> path to the configuration file.
--device <device> device to emulate, for example: "iPhone 15"
--executable-path <path> path to the browser executable.
--headless run browser in headless mode, headed by default
--host <host> host to bind server to. Default is localhost. Use
0.0.0.0 to bind to all interfaces.
--ignore-https-errors ignore https errors
--isolated keep the browser profile in memory, do not save
it to disk.
--no-image-responses do not send image responses to the client.
--no-sandbox disable the sandbox for all process types that
are normally sandboxed.
--output-dir <path> path to the directory for output files.
--port <port> port to listen on for SSE transport.
--proxy-bypass <bypass> comma-separated domains to bypass proxy, for
example ".com,chromium.org,.domain.com"
--proxy-server <proxy> specify proxy server, for example
"http://myproxy:3128" or "socks5://myproxy:8080"
--save-trace Whether to save the Playwright Trace of the
session into the output directory.
--storage-state <path> path to the storage state file for isolated
sessions.
--user-agent <ua string> specify user agent string
--user-data-dir <path> path to the user data directory. If not
specified, a temporary directory will be created.
--viewport-size <size> specify browser viewport size in pixels, for
example "1280, 720"
--vision Run server that uses screenshots (Aria snapshots
are used by default)Playwright MCP は、通常のブラウザ (デフォルト) のように永続プロファイルを使用して実行することも、テスト セッション用の分離されたコンテキストで実行することもできます。
永続的なプロファイル
ログイン情報はすべて永続プロファイルに保存されます。オフライン状態をクリアしたい場合は、セッション間でこのプロファイルを削除できます。永続プロファイルは以下の場所に保存されており、 --user-data-dir引数で上書きできます。
# Windows
%USERPROFILE%\AppData\Local\ms-playwright\mcp-{channel}-profile
# macOS
- ~/Library/Caches/ms-playwright/mcp-{channel}-profile
# Linux
- ~/.cache/ms-playwright/mcp-{channel}-profile孤立した
分離モードでは、各セッションは分離プロファイルで開始されます。MCPにブラウザを閉じるよう指示するたびにセッションが閉じられ、そのセッションのすべてのストレージ状態が失われます。設定のcontextOptionsまたは--storage-state引数を使用して、ブラウザに初期のストレージ状態を提供できます。ストレージ状態の詳細については、こちらをご覧ください。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest",
"--isolated",
"--storage-state={path/to/storage.json}
]
}
}
}Playwright MCPサーバーはJSON設定ファイルを使用して設定できます。設定ファイルは、 --configコマンドラインオプションを使用して指定できます。
npx @playwright/mcp@latest --config path/to/config.json{
// Browser configuration
browser?: {
// Browser type to use (chromium, firefox, or webkit)
browserName?: 'chromium' | 'firefox' | 'webkit';
// Keep the browser profile in memory, do not save it to disk.
isolated?: boolean;
// Path to user data directory for browser profile persistence
userDataDir?: string;
// Browser launch options (see Playwright docs)
// @see https://playwright.dev/docs/api/class-browsertype#browser-type-launch
launchOptions?: {
channel?: string; // Browser channel (e.g. 'chrome')
headless?: boolean; // Run in headless mode
executablePath?: string; // Path to browser executable
// ... other Playwright launch options
};
// Browser context options
// @see https://playwright.dev/docs/api/class-browser#browser-new-context
contextOptions?: {
viewport?: { width: number, height: number };
// ... other Playwright context options
};
// CDP endpoint for connecting to existing browser
cdpEndpoint?: string;
// Remote Playwright server endpoint
remoteEndpoint?: string;
},
// Server configuration
server?: {
port?: number; // Port to listen on
host?: string; // Host to bind to (default: localhost)
},
// List of enabled capabilities
capabilities?: Array<
'core' | // Core browser automation
'tabs' | // Tab management
'pdf' | // PDF generation
'history' | // Browser history
'wait' | // Wait utilities
'files' | // File handling
'install' | // Browser installation
'testing' // Testing
>;
// Enable vision mode (screenshots instead of accessibility snapshots)
vision?: boolean;
// Directory for output files
outputDir?: string;
// Network configuration
network?: {
// List of origins to allow the browser to request. Default is to allow all. Origins matching both `allowedOrigins` and `blockedOrigins` will be blocked.
allowedOrigins?: string[];
// List of origins to block the browser to request. Origins matching both `allowedOrigins` and `blockedOrigins` will be blocked.
blockedOrigins?: string[];
};
/**
* Do not send image responses to the client.
*/
noImageResponses?: boolean;
}ディスプレイのないシステム上または IDE のワーカー プロセスからヘッダー付きブラウザーを実行する場合は、DISPLAY を指定した環境から MCP サーバーを実行し、 --portフラグを渡して SSE トランスポートを有効にします。
npx @playwright/mcp@latest --port 8931次に、MCP クライアント構成で、SSE エンドポイントへのurlを設定します。
{
"mcpServers": {
"playwright": {
"url": "http://localhost:8931/sse"
}
}
}**注意:**現時点では、Docker 実装ではヘッドレス Chromium のみがサポートされています。
{
"mcpServers": {
"playwright": {
"command": "docker",
"args": ["run", "-i", "--rm", "--init", "--pull=always", "mcr.microsoft.com/playwright/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);
// ...
});ツールは次の 2 つのモードで使用できます。
スナップショットモード（デフォルト）：アクセシビリティスナップショットを使用してパフォーマンスと信頼性を向上します
ビジョンモード: スクリーンショットを使用して視覚的なインタラクションを行います
ビジョン モードを使用するには、サーバーの起動時に--visionフラグを追加します。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest",
"--vision"
]
}
}
}ビジョン モードは、提供されたスクリーンショットに基づいて、XY 座標空間を使用して要素と対話できるコンピューター使用モデルで最も効果的に機能します。
ブラウザのスナップショット
タイトル: ページスナップショット
説明: 現在のページのアクセシビリティスナップショットをキャプチャします。これはスクリーンショットよりも優れています。
パラメータ: なし
読み取り専用: true
ブラウザクリック
タイトル: クリック
説明: Webページでクリックを実行する
パラメータ:
element (文字列): 要素と対話するための許可を得るために使用される、人間が読める要素の説明
ref (文字列): ページスナップショットからの正確なターゲット要素参照
読み取り専用: false
ブラウザドラッグ
タイトル: マウスをドラッグ
説明: 2つの要素間でドラッグアンドドロップを実行します
パラメータ:
startElement (文字列): 要素と対話するための許可を取得するために使用される、人間が読めるソース要素の説明
startRef (文字列): ページスナップショットからの正確なソース要素参照
endElement (文字列): 要素と対話するための許可を取得するために使用される、人間が読めるターゲット要素の説明
endRef (文字列): ページスナップショットからの正確なターゲット要素参照
読み取り専用: false
ブラウザホバー
タイトル: ホバーマウス
説明: ページ上の要素にマウスを移動します
パラメータ:
element (文字列): 要素と対話するための許可を得るために使用される、人間が読める要素の説明
ref (文字列): ページスナップショットからの正確なターゲット要素参照
読み取り専用: true
ブラウザの種類
タイトル: テキストを入力
説明: 編集可能な要素にテキストを入力します
パラメータ:
element (文字列): 要素と対話するための許可を得るために使用される、人間が読める要素の説明
ref (文字列): ページスナップショットからの正確なターゲット要素参照
text (文字列): 要素に入力するテキスト
submit （ブール値、オプション）：入力したテキストを送信するかどうか（送信後にEnterキーを押す）
slowly (boolean, オプション): 一度に1文字ずつ入力するかどうか。ページ内のキーハンドラをトリガーするのに便利です。デフォルトでは、テキスト全体が一度に入力されます。
読み取り専用: false
ブラウザ選択オプション
タイトル: オプションを選択
説明: ドロップダウンからオプションを選択します
パラメータ:
element (文字列): 要素と対話するための許可を得るために使用される、人間が読める要素の説明
ref (文字列): ページスナップショットからの正確なターゲット要素参照
values (配列): ドロップダウンで選択する値の配列。単一の値または複数の値を指定できます。
読み取り専用: false
ブラウザのキーを押す
タイトル: キーを押す
説明: キーボードのキーを押します
パラメータ:
key (文字列): 押すキーの名前、または生成するa （例： ArrowLeft 、
読み取り専用: false
ブラウザの待機時間
タイトル: 待つ
説明: テキストが表示されたり消えたりするか、指定された時間が経過するのを待ちます
パラメータ:
time （数値、オプション）：待機時間（秒）
text （文字列、オプション）：待機するテキスト
textGone (文字列、オプション): 消えるのを待つテキスト
読み取り専用: true
ブラウザファイルアップロード
タイトル: ファイルをアップロード
説明: 1つまたは複数のファイルをアップロードします
パラメータ:
paths (配列): アップロードするファイルへの絶対パス。1つのファイルでも複数のファイルでも構いません。
読み取り専用: false
ブラウザハンドルダイアログ
タイトル: ダイアログを処理する
説明: ダイアログを処理する
パラメータ:
accept (boolean): ダイアログを受け入れるかどうか。
promptText (文字列、オプション): プロンプトダイアログの場合のプロンプトのテキスト。
読み取り専用: false
ブラウザナビゲート
タイトル: URL に移動する
説明: URL に移動する
パラメータ:
url (文字列): 移動するURL
読み取り専用: false
ブラウザの戻る
タイトル: 戻る
説明: 前のページに戻る
パラメータ: なし
読み取り専用: true
ブラウザで進む
タイトル: 前進
説明: 次のページへ進む
パラメータ: なし
読み取り専用: true
ブラウザのスクリーンショット
タイトル: スクリーンショットを撮る
説明: 現在のページのスクリーンショットを撮ります。スクリーンショットに基づいてアクションを実行することはできません。アクションには browser_snapshot を使用してください。
パラメータ:
raw (ブール値、オプション): 圧縮せずにPNG形式で返すかどうか。デフォルトはfalseで、JPEG画像を返します。
filename (文字列, オプション): スクリーンショットを保存するファイル名。指定されていない場合は、デフォルトでpage-{timestamp}.{png|jpeg}になります。
element (文字列, オプション): 要素のスクリーンショットの許可を得るために使用される、人間が読める形式の要素説明。指定されていない場合は、ビューポートのスクリーンショットが撮影されます。element を指定する場合は、ref も指定する必要があります。
ref (文字列, オプション): ページスナップショットから取得する正確なターゲット要素の参照。指定されていない場合は、ビューポートのスクリーンショットが取得されます。ref を指定する場合は、要素も指定する必要があります。
読み取り専用: true
ブラウザPDF保存
タイトル: PDFとして保存
説明: ページをPDFとして保存
パラメータ:
filename (文字列、オプション): PDFを保存するファイル名。指定されていない場合は、デフォルトでpage-{timestamp}.pdfになります。
読み取り専用: true
ブラウザネットワークリクエスト
タイトル: ネットワークリクエストの一覧
説明: ページの読み込み以降のすべてのネットワーク リクエストを返します
パラメータ: なし
読み取り専用: true
ブラウザコンソールメッセージ
タイトル: コンソールメッセージを取得する
説明: すべてのコンソールメッセージを返します
パラメータ: なし
読み取り専用: true
ブラウザのインストール
タイトル: 設定で指定されたブラウザをインストールする
説明: 設定で指定されたブラウザをインストールします。ブラウザがインストールされていないというエラーが発生した場合にこれを呼び出します。
パラメータ: なし
読み取り専用: false
ブラウザを閉じる
タイトル: ブラウザを閉じる
説明: ページを閉じる
パラメータ: なし
読み取り専用: true
ブラウザのサイズ変更
タイトル: ブラウザウィンドウのサイズを変更する
説明: ブラウザウィンドウのサイズを変更する
パラメータ:
width （数値）：ブラウザウィンドウの幅
height （数値）：ブラウザウィンドウの高さ
読み取り専用: true
ブラウザタブリスト
タイトル: リストタブ
説明: ブラウザのタブを一覧表示する
パラメータ: なし
読み取り専用: true
ブラウザタブ新規
タイトル: 新しいタブを開く
説明: 新しいタブを開く
パラメータ:
url (文字列、オプション): 新しいタブで移動するURL。指定しない場合、新しいタブは空白になります。
読み取り専用: true
ブラウザタブ選択
タイトル: タブを選択
説明: インデックスでタブを選択する
パラメータ:
index （数値）：選択するタブのインデックス
読み取り専用: true
ブラウザタブを閉じる
タイトル: タブを閉じる
説明: タブを閉じる
パラメータ:
index (数値, オプション): 閉じるタブのインデックス。指定されていない場合は現在のタブを閉じます。
読み取り専用: false
ブラウザ生成プレイライトテスト
タイトル: Playwright テストを生成する
説明: 指定されたシナリオの Playwright テストを生成します
パラメータ:
name (文字列): テストの名前
description (文字列): テストの説明
steps （配列）：テストのステップ
読み取り専用: true
ブラウザのスクリーンキャプチャ
タイトル: スクリーンショットを撮る
説明: 現在のページのスクリーンショットを撮ります
パラメータ: なし
読み取り専用: true
ブラウザ画面上のマウス移動
タイトル: マウスを動かす
説明: マウスを指定された位置に移動する
パラメータ:
element (文字列): 要素と対話するための許可を得るために使用される、人間が読める要素の説明
x (数値): X座標
y (数値): Y座標
読み取り専用: true
ブラウザ画面のクリック
タイトル: クリック
説明: マウスの左ボタンをクリック
パラメータ:
element (文字列): 要素と対話するための許可を得るために使用される、人間が読める要素の説明
x (数値): X座標
y (数値): Y座標
読み取り専用: false
ブラウザ画面ドラッグ
タイトル: マウスをドラッグ
説明: 左マウスボタンをドラッグ
パラメータ:
element (文字列): 要素と対話するための許可を得るために使用される、人間が読める要素の説明
startX (数値): 開始X座標
startY (数値): 開始Y座標
endX (数値): 終了X座標
endY (数値): 終了Y座標
読み取り専用: false
ブラウザ画面タイプ
タイトル: テキストを入力
説明: テキストを入力
パラメータ:
text (文字列): 要素に入力するテキスト
submit （ブール値、オプション）：入力したテキストを送信するかどうか（送信後にEnterキーを押す）
読み取り専用: false
ブラウザのキーを押す
タイトル: キーを押す
説明: キーボードのキーを押します
パラメータ:
key (文字列): 押すキーの名前、または生成するa （例： ArrowLeft 、
読み取り専用: false
ブラウザの待機時間
タイトル: 待つ
説明: テキストが表示されたり消えたりするか、指定された時間が経過するのを待ちます
パラメータ:
time （数値、オプション）：待機時間（秒）
text （文字列、オプション）：待機するテキスト
textGone (文字列、オプション): 消えるのを待つテキスト
読み取り専用: true
ブラウザファイルアップロード
タイトル: ファイルをアップロード
説明: 1つまたは複数のファイルをアップロードします
パラメータ:
paths (配列): アップロードするファイルへの絶対パス。1つのファイルでも複数のファイルでも構いません。
読み取り専用: false
ブラウザハンドルダイアログ
タイトル: ダイアログを処理する
説明: ダイアログを処理する
パラメータ:
accept (boolean): ダイアログを受け入れるかどうか。
promptText (文字列、オプション): プロンプトダイアログの場合のプロンプトのテキスト。
読み取り専用: 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 indicate destructiveHint=true and readOnlyHint=false, so the agent knows this mutates state. However, beyond annotations, the description adds no behavioral context (e.g., whether it waits for navigation, scrolls into view, or handles dialogs). It does not contradict 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 extremely short (one sentence), which is concise but arguably too brief. It lacks informative content that could be included without affecting conciseness. It is front-loaded but does not earn its place with substantial value.
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 has 5 parameters, no output schema, and many siblings, the description is incomplete. It does not explain the effect of clicking (e.g., navigation, state changes), preconditions, or typical usage patterns. The annotations partially compensate but the description leaves significant gaps.
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 parameters are well-documented in the schema. The description adds no additional meaning or context beyond what is already provided in the parameter descriptions.
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 'Perform click on a web page' states the action and resource clearly, but does not distinguish from sibling tools like browser_hover or browser_drag. It lacks specificity about element targeting or click types beyond the bare minimum.
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 on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., page must be loaded, element must be visible), exclusions, or scenarios where another tool might be more appropriate.
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?
Annotations already indicate destructiveHint=true, so the destructive nature is clear. However, the description adds no behavioral context beyond that, such as what happens to unsaved data or whether the page can be reopened. With annotations present, the bar is lower, but the description still fails to add value.
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 at 4 words, with no wasted content. For a simple close action, this level of conciseness is optimal and well-structured.
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 no parameters and no output schema, the description is barely adequate. It does not explain side effects, such as whether the browser closes the entire window or just the current tab, or how it interacts with multiple tabs. A minimal tool can get by with a short description, but it still lacks completeness.
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?
No parameters exist in the schema, and the description does not mention any. Since there are no parameters to explain, the description does not need to add semantic information. Baseline score of 4 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 'Close the page' is a clear verb+resource combination. It is distinct from sibling tools like browser_navigate or browser_tabs, though very minimal. Could be more specific (e.g., current tab vs 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?
No guidance is provided about when to use this tool versus alternatives like browser_navigate_back or browser_tabs. Agents have no context to decide which tool is appropriate for closing a tab vs page.
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 declare readOnlyHint=true and destructiveHint=false. The description adds no additional behavioral context beyond 'returns all console messages', which is consistent but not enriching.
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?
Single sentence that is concise and to the point. No wasted words, and the structure is appropriate for a simple tool.
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 well-described schema and annotations, the description is sufficient for a straightforward read-only tool. It lacks return value details but that is acceptable without an output schema.
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 are fully described in the schema (100% coverage). The description adds no extra meaning beyond what the schema already provides, achieving the baseline.
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 clearly states it returns console messages, which is a specific verb+resource. However, it does not differentiate from sibling tools like browser_network_requests, but the 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 on when to use this tool versus alternatives. For example, it doesn't mention that this tool is for accessing client-side console output, distinct from network request logs.
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 openWorldHint=true, but the description does not elaborate on specific behaviors, such as how drag events are simulated, whether it requires WebDriver or Playwright, or what happens if elements are not draggable. It adds minimal value beyond 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, front-loaded sentence with zero wasted words. It conveys the essential action efficiently.
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 4 parameters and no output schema, but the description omits details about return values, error cases, or how the drag-and-drop coordinates are interpreted (e.g., center points vs. specific locations). It fails to fully inform an agent about the tool's capabilities and limitations.
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 all 4 parameters with full description coverage (100%). The tool description does not add any additional meaning to the parameters beyond what the schema already provides, such as clarifying the difference between startElement and startTarget. Baseline of 3 is appropriate given high schema coverage.
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 uses a specific verb ('Perform drag and drop') and clearly identifies the resource ('between two elements'). It effectively distinguishes this tool from sibling tools like browser_click, browser_hover, and browser_drop (which might only handle the release phase).
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, such as browser_drop for only releasing, or what prerequisites are needed (e.g., obtaining element references via snapshot). The description lacks any contextual hints about ideal scenarios or exclusions.
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 indicate destructiveHint and openWorldHint, so description adds 'as if dragged from outside the page' which clarifies the simulation. However, it does not detail potential side effects like triggering event handlers or page navigation.
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 the core purpose front-loaded. Every word is meaningful and no 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 is adequate for a simple drop action, but given destructive and open-world annotations, it lacks details on what happens after drop (e.g., event triggering, return value). The schema covers parameters well, but behavioral outcomes are not specified.
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%, but the description adds a critical constraint not in schema: 'At least one of paths or data must be provided.' This clarifies optionality beyond the required fields.
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 drops files or MIME-typed data onto an element simulating an external drag. It distinguishes from siblings like browser_drag by specifying 'dragged from outside the page' and from browser_file_upload by referring to drop behavior.
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 explicit guidance on when to use this tool over alternatives like browser_drag or browser_file_upload. The hint 'At least one of paths or data must be provided' is a constraint, not a usage guideline.
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 indicate destructiveHint and openWorldHint, so the description doesn't need to repeat that. However, it doesn't add details about potential side effects or page modifications beyond what annotations provide.
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, front-loaded sentence with no superfluous words. It effectively conveys the core purpose.
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?
While the description covers the basic action, it lacks explanation of return values (e.g., what the JavaScript expression returns) and does not elaborate on the filename parameter for saving results. Given the annotations and schema, it meets minimum viability but has gaps.
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 are fully described in the schema (100% coverage), so the description adds little extra meaning. The phrase 'on page or element' hints at the element parameter but does not add concrete semantics.
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 evaluates JavaScript on a page or element, which is a specific verb+resource. However, it does not differentiate from the sibling tool 'browser_run_code_unsafe' which also executes code.
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_run_code_unsafe' or 'browser_click'. There is no mention of prerequisites, safety considerations, or contextual cues.
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?
Annotations include destructiveHint=true and openWorldHint=true, but the description adds no further behavioral context such as side effects (e.g., form submission) or cancellation behavior beyond what the parameter description covers.
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 short, direct sentences with no wasted words, effectively communicating the tool's function.
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 is adequate given the simple interface, but could mention the need for a file input element or how the tool interacts with the browser's file chooser for fuller completeness.
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 100% of parameters; the description adds clarity about single vs multiple files and cancellation, complementing the schema's details.
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 'Upload' and the resource 'one or multiple files', differentiating it from sibling tools like browser_click, browser_navigate, etc.
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 explicit guidance on when to use this tool versus alternatives, nor any prerequisites (e.g., needing a file input element). Implied usage from context.
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?
Annotations indicate destructiveHint=true and openWorldHint=true, but the description adds no behavioral context (e.g., whether it overwrites existing values or handles validation). With annotations, the bar is lower, but the description still doesn't supplement.
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 irrelevant information, achieving maximal conciseness.
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?
While the schema covers parameters, the description lacks context about behavior (e.g., clearing fields, submitting), and there is no output schema. It is minimally complete given the tool's complexity.
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 the input schema fully documents parameters. The description adds no extra semantics beyond what the schema provides, hence baseline 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 'Fill multiple form fields' uses a specific verb (fill) and resource (form fields), clearly distinguishing it from siblings like browser_type (types into a single field) and browser_click.
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 for filling forms but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like browser_type for individual fields.
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 declare readOnlyHint=true and destructiveHint=false. The description adds that the search is on the accessibility snapshot, returns nodes with surrounding context and paths, and is cheaper than a snapshot. This provides useful behavioral context beyond annotations without contradiction.
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 two sentences, front-loaded with the main purpose, and contains no redundant information. Every part is meaningful and efficiently conveys the tool's function and usage.
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 simplicity, absence of output schema, and good annotations, the description covers all needed context: what it does, what the return looks like, and when it's appropriate. It is complete for effective selection and 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?
Schema coverage is 100% with descriptions for both parameters. The description adds extra semantics: case-insensitive substring for text, case-sensitive by default for regex with flag syntax. This enhances understanding beyond the schema fields.
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 searches the accessibility snapshot for text or regex and returns matching nodes with context. It distinguishes itself from 'browser_snapshot' by noting it's cheaper when only locating an element, providing a specific verb and resource.
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 explains when to use this tool (to locate an element cheaply) and provides constraints ('provide either text or regex, not both'). It implies when not to use (when full snapshot is needed) but does not explicitly list alternatives beyond the sibling comparison.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, but the description adds no additional behavioral context. It does not explain that the tool requires an active dialog, what happens to the dialog after handling, or that prompt dialogs may need text input beyond the schema.
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 very concise (one sentence), but it omits important context. While not verbose, it is under-specified, earning a middle score.
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 role in browser automation and the presence of many sibling tools, the description fails to explain its context (e.g., only works when a dialog is open) or how it fits into a workflow. No output schema exists, but the description does not compensate by describing return 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 description coverage is 100%, with clear descriptions for 'accept' and 'promptText'. The description adds no extra meaning but does not need to, as the schema is sufficient. 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 'Handle a dialog' is slightly more specific than the name, indicating the tool deals with browser dialogs. However, 'handle' is a generic verb and does not specify whether it accepts, dismisses, or inputs text, leaving the purpose 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?
No guidance is provided about when to use this tool, such as after a dialog appears or as an alternative to other browser tools. The description lacks any contextual cues for selecting it over siblings like browser_click or browser_navigate.
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?
The description provides no behavioral details beyond what annotations indicate. Annotations show destructiveHint=true and openWorldHint=true, but the description does not explain what effects hovering has on the page state or interaction flow.
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 wasted words. It is appropriately front-loaded but could potentially include a bit more detail without losing conciseness.
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 simplicity and lack of output schema, the description is minimally adequate. However, it omits mention of potential side effects, timing, or return behavior, which are relevant given the openWorld and destructive hints.
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 description of the 'element' parameter adds meaningful context about its role in obtaining permission, and the 'target' parameter description clarifies acceptable selectors. With 100% schema description coverage, the description enhances understanding beyond the schema alone.
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 'Hover over element on page' clearly states the verb and resource, making the tool's purpose immediately understandable. However, it does not explicitly distinguish itself from sibling tools like browser_click or browser_drag, which could provide nuance.
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 given on when to use this tool versus alternatives such as browser_click or browser_type. There is no mention of prerequisites or context where hovering is appropriate.
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 indicate read-only and safe; description adds details about returning full details or selective parts. Does not contradict 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?
Two sentences, front-loaded with purpose, no wasted 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?
No output schema, but description covers return format (headers, body, or part) and file saving. Sufficient for a simple retrieval 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 coverage is 100%, so baseline 3. Description adds context for 'part' (omit for full) and 'filename' (save vs text output), enhancing beyond 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?
Clearly states it returns details of a single network request, distinguishes from 'browser_network_requests' which lists them. Specific verb+resource.
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?
Explicitly instructs to use the number from browser_network_requests. No explicit when-not-to-use, but context is clear.
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 indicate readOnlyHint=true, description adds scope (since page load) and output format (numbered list), but no other behavioral traits.
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, no redundancy, front-loaded with purpose.
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 but description hints at output format; lacks pagination/limit info but adequate for a read-only list 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 parameters with descriptions; description adds no extra semantic value beyond what schema 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?
Clearly states it returns a numbered list of network requests since page load, and distinguishes from sibling browser_network_request for full details.
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?
Explicitly mentions when to use sibling for full details, but lacks constraints or when-not-to-use scenarios.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description need not repeat that. However, it adds no extra context about keyboard events or focus requirements, which is acceptable given the tool's simplicity.
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 (5 words) with no wasted text. It could benefit from slight expansion for clarity, but its brevity aligns with the tool's simplicity.
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 single parameter, no output schema, and annotations covering safety, the description is adequate for a basic key press action. However, it doesn't mention potential effects like keydown/keyup events or prerequisite focus, which limits completeness.
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 a clear parameter description. The tool's description adds no additional semantic value beyond what the schema already provides, so 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 'Press a key on the keyboard' explicitly states the action and resource, clearly distinguishing it from sibling tools like browser_type (for typing text) and browser_click (for 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 alternatives (e.g., browser_type for character strings, browser_hover for mouse actions). The description lacks context for appropriate usage.
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?
Annotations already mark destructiveHint: true and readOnlyHint: false, indicating state change. The description adds no additional behavioral context (e.g., effect on layout, timing).
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?
Single sentence, no extraneous words. Appropriate length for a simple tool.
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 resize operation, the description is adequate but omits units (e.g., pixels) and validation limits. With no output schema, more detail would help.
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 width and height. The tool description adds no extra semantic meaning beyond what the schema 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 'Resize the browser window' is a specific verb-resource pair. It clearly distinguishes from sibling tools like browser_navigate or browser_click, which have different actions.
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 on when to use this tool versus alternatives. The description does not mention context, prerequisites, or 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.
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 provide destructiveHint=true and openWorldHint=true. The description reinforces this by labeling it 'Unsafe' and 'RCE-equivalent', but does not add new behavioral details beyond what annotations convey. It is consistent with 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, front-loaded sentence that immediately states the action and critical warning. No words are wasted; every part 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?
Given the tool's power and lack of output schema, the description could mention return values or error handling. However, for a code runner, the return is implicit in the code. The warning is sufficient, but completeness is adequate.
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 parameters well-described in the schema itself (including a full example for 'code'). The tool description adds no extra parameter semantics beyond the schema, so 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 verb 'Run' and the resource 'Playwright code snippet'. The warning about unsafety and RCE-equivalency differentiates it from sibling tools like browser_evaluate, making its purpose distinct and specific.
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 through its warning that this tool is for advanced use cases requiring server-side code execution, but it does not explicitly state when to use it versus alternatives like browser_evaluate. No exclusions or when-not guidance is provided.
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 provide destructiveHint=true, readOnlyHint=false, openWorldHint=true, but the description adds no further behavioral context (e.g., side effects like triggering change events, need for the dropdown to be expanded, or permission flow beyond element description). The description does not contradict 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?
A single, front-loaded sentence that is concise and contains no redundant information. Perfectly sized for this simple tool.
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 with well-documented schema, but the description does not clarify that 'values' refers to option value attributes or that the element must be a <select>. Missing minor context that would help an agent.
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?
Input schema coverage is 100% with descriptions for all three parameters. The description adds no extra meaning beyond what the schema already provides, 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 'Select an option in a dropdown' uses a specific verb ('select') and clearly identifies the resource (dropdown option). This effectively distinguishes it from sibling tools like browser_click, browser_type, and browser_fill_form.
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 (e.g., browser_fill_form for filling dropdowns via text, or browser_type for interacting with non-select elements). The description lacks any contextual usage advice.
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 indicate readOnlyHint=true and non-destructive. The description adds 'accessibility snapshot' context but doesn't elaborate on behavioral traits like what happens to the page state.
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, concise and front-loaded. It could benefit from slightly more structure but is effective and not verbose.
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 four parameters and no output schema, the description is too brief. It fails to explain the return format, the effect of parameters like depth or boxes, or how the snapshot differs from a screenshot.
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 each parameter has a description. The tool description does not add additional meaning beyond the schema, so baseline 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 tool captures an accessibility snapshot and claims it's better than a screenshot, distinguishing it from sibling tools like browser_take_screenshot.
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 use for accessibility over screenshot, but lacks explicit guidance on when to use vs alternatives like browser_evaluate or when not to use.
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 indicate destructiveHint=true and readOnlyHint=false, which the description aligns with. The description adds minimal behavioral detail beyond the schema, such as 'if omitted for close, current tab is closed,' but does not elaborate on consequences of create or select.
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 covering all intended actions. It is efficient but lacks structural elements like bullet points or separate lines for each action, though not necessary given 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?
For a tab management tool with multiple actions and no output schema, the description covers the core functionality but omits details like what happens when listing empty tabs, the effect of 'select' on focus, or error states. It is minimally adequate.
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?
Input schema has 100% coverage with descriptions for action, index, and url. The description only restates the actions and does not add new semantics or examples for parameter usage.
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 explicitly states the four actions (list, create, close, select) and the resource (browser tab). It clearly distinguishes from sibling tools like browser_navigate (which operates within a tab) and browser_close (which likely closes the browser, not a tab).
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 for basic tab management but provides no explicit guidance on when to use this tool versus alternatives like browser_navigate or browser_close. It does not mention prerequisites or 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.
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 mark this as read-only and non-destructive. The description adds an important behavioral limitation: the screenshot cannot be used as a basis for actions, which is not captured in annotations. However, it doesn't describe how the screenshot is returned or any side effects beyond the annotation hints.
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: the first states the purpose, the second provides a crucial usage caveat. No redundant words, and the structure effectively front-loads the core action before delivering the warning.
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?
While the schema covers parameters thoroughly, the description omits what the tool returns (e.g., file path, image data) after taking the screenshot. The note about not using it for actions suggests the image is for visual inspection, but this isn't explicit. For a tool with no output schema, this is a notable gap.
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 6 parameters are fully documented in the schema with detailed descriptions (e.g., scale explains CSS vs device pixels, fullPage notes it cannot be combined with element). The description itself adds no parameter-level detail, so it aligns with the schema-heavy 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?
States 'Take a screenshot of the current page' with a specific verb and resource. It distinguishes itself from browser_snapshot by explicitly noting 'use browser_snapshot for actions,' clarifying that this tool is for visual capture while the alternative is for actions.
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?
Explicitly warns 'You can't perform actions based on the screenshot, use browser_snapshot for actions,' providing a clear exclusion and naming the alternative. This gives the agent concrete guidance on when not to use this tool and which sibling to use instead.
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?
Annotations already declare destructiveHint=true (modification). Description adds minimal behavioral context; does not mention the submit or slowly parameters that affect behavior.
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?
Single sentence, no fluff. Front-loaded with verb and object. Efficient use of space.
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?
With 5 parameters and no output schema, the description is too brief. It omits details like target specification, editable element requirements, and return 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?
All parameters are documented in the input schema (100% coverage). The description does not add additional meaning beyond what the schema provides, baseline score 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 'Type text into editable element' clearly identifies the verb (type) and resource (editable element), distinguishing it from sibling tools like browser_click or browser_fill_form.
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 on when to use this tool versus alternatives (e.g., browser_fill_form, browser_press_key). Missing context about prerequisites or when not to use.
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?
Annotations mark the tool as read-only and non-destructive, which the description reinforces. However, the description does not disclose behavior when multiple parameters are combined (e.g., both text and time), potential error conditions, or timeout behavior, which are important for correct invocation.
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, front-loaded sentence that efficiently conveys the tool's core functionality with no extraneous 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 no output schema and simple behavior, the description lacks critical details about parameter combination logic, error handling, and return behavior. Agents may need to infer behavior from the parameter descriptions alone, which is insufficient for robust decision-making.
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 each parameter described. The description adds context by linking 'text' to 'appear', 'textGone' to 'disappear', and 'time' to a wait duration. However, it does not explain interaction between parameters or provide formatting details 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's purpose: waiting for text to appear, disappear, or a specified time. It distinguishes itself from sibling browser action tools like click or navigate by focusing on waiting.
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 scenarios (waiting for text or time) but does not explicitly state when to use this tool versus alternatives like polling or other wait mechanisms. No exclusions or when-not-to-use guidance is provided.
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. Dates show when Glama detected each change.
v0.0.79browser_take_screenshot5 fields changedInput schema / properties / filename / descriptionPrevious value: -"File name to save the screenshot to. Defaults to `page-{timestamp}.{png|jpeg}` if not specified. Prefer relative file names to stay within the output directory."New value: +"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."Input schema / properties / type / defaultRemoved value: -"png"Input schema / properties / type / descriptionPrevious value: -"Image format for the screenshot. Default is png."New value: +"Image format for the screenshot. If unset, inferred from the filename extension, otherwise png."Input schema / properties / type / enumPrevious value: -[
- "png",
- "jpeg"
-]New value: +[
+ "png",
+ "jpeg",
+ "webp"
+]Input schema / requiredPrevious value: -[
- "type",
- "scale"
-]New value: +[
+ "scale"
+]v0.0.78browser_findbrowser_take_screenshot2 fields changedInput schema / properties / scaleAdded value: +{
+ "default": "css",
+ "description": "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.",
+ "enum": [
+ "css",
+ "device"
+ ],
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "type"
-]New value: +[
+ "type",
+ "scale"
+]v0.0.74browser_snapshot1 field changedInput schema / properties / boxes / descriptionPrevious value: -"Include each element's bounding box as [box=x,y,width,height] in the snapshot"New value: +"Include each element's bounding box as [box=x,y,width,height] in the snapshot. Coordinates are viewport-relative, in CSS pixels (Element.getBoundingClientRect)"v0.0.72browser_click4 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / refRemoved value: -{
- "description": "Exact target element reference from the page snapshot",
- "type": "string"
-}Input schema / properties / targetAdded value: +{
+ "description": "Exact target element reference from the page snapshot, or a unique element selector",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "element",
- "ref"
-]New value: +[
+ "target"
+]browser_close1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"browser_console_messages4 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / allAdded value: +{
+ "description": "Return all console messages since the beginning of the session, not just since the last navigation. Defaults to false.",
+ "type": "boolean"
+}Input schema / properties / filenameAdded value: +{
+ "description": "Filename to save the console messages to. If not provided, messages are returned as text.",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "level"
+]browser_drag6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / endRefRemoved value: -{
- "description": "Exact target element reference from the page snapshot",
- "type": "string"
-}Input schema / properties / endTargetAdded value: +{
+ "description": "Exact target element reference from the page snapshot, or a unique element selector",
+ "type": "string"
+}Input schema / properties / startRefRemoved value: -{
- "description": "Exact source element reference from the page snapshot",
- "type": "string"
-}Input schema / properties / startTargetAdded value: +{
+ "description": "Exact target element reference from the page snapshot, or a unique element selector",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "startElement",
- "startRef",
- "endElement",
- "endRef"
-]New value: +[
+ "startTarget",
+ "endTarget"
+]browser_dropbrowser_evaluate4 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / filenameAdded value: +{
+ "description": "Filename to save the result to. If not provided, result is returned as text.",
+ "type": "string"
+}Input schema / properties / refRemoved value: -{
- "description": "Exact target element reference from the page snapshot",
- "type": "string"
-}Input schema / properties / targetAdded value: +{
+ "description": "Exact target element reference from the page snapshot, or a unique element selector",
+ "type": "string"
+}browser_file_upload1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"browser_fill_form5 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / fields / items / properties / elementAdded value: +{
+ "description": "Human-readable element description used to obtain permission to interact with the element",
+ "type": "string"
+}Input schema / properties / fields / items / properties / refRemoved value: -{
- "description": "Exact target field reference from the page snapshot",
- "type": "string"
-}Input schema / properties / fields / items / properties / targetAdded value: +{
+ "description": "Exact target element reference from the page snapshot, or a unique element selector",
+ "type": "string"
+}Input schema / properties / fields / items / requiredPrevious value: -[
- "name",
- "type",
- "ref",
- "value"
-]New value: +[
+ "target",
+ "name",
+ "type",
+ "value"
+]browser_handle_dialog1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"browser_hover4 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / refRemoved value: -{
- "description": "Exact target element reference from the page snapshot",
- "type": "string"
-}Input schema / properties / targetAdded value: +{
+ "description": "Exact target element reference from the page snapshot, or a unique element selector",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "element",
- "ref"
-]New value: +[
+ "target"
+]browser_installbrowser_navigate1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"browser_navigate_back1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"browser_network_requestbrowser_network_requests6 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / filenameAdded value: +{
+ "description": "Filename to save the network requests to. If not provided, requests are returned as text.",
+ "type": "string"
+}Input schema / properties / filterAdded value: +{
+ "description": "Only return requests whose URL matches this regexp (e.g. \"/api/.*user\").",
+ "type": "string"
+}Input schema / properties / includeStaticRemoved value: -{
- "default": false,
- "description": "Whether to include successful static resources like images, fonts, scripts, etc. Defaults to false.",
- "type": "boolean"
-}Input schema / properties / staticAdded value: +{
+ "default": false,
+ "description": "Whether to include successful static resources like images, fonts, scripts, etc. Defaults to false.",
+ "type": "boolean"
+}Input schema / requiredAdded value: +[
+ "static"
+]browser_press_key1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"browser_resize1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"browser_run_codebrowser_run_code_unsafebrowser_select_option4 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / refRemoved value: -{
- "description": "Exact target element reference from the page snapshot",
- "type": "string"
-}Input schema / properties / targetAdded value: +{
+ "description": "Exact target element reference from the page snapshot, or a unique element selector",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "element",
- "ref",
- "values"
-]New value: +[
+ "target",
+ "values"
+]browser_snapshot4 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / boxesAdded value: +{
+ "description": "Include each element's bounding box as [box=x,y,width,height] in the snapshot",
+ "type": "boolean"
+}Input schema / properties / depthAdded value: +{
+ "description": "Limit the depth of the snapshot tree",
+ "type": "number"
+}Input schema / properties / targetAdded value: +{
+ "description": "Exact target element reference from the page snapshot, or a unique element selector",
+ "type": "string"
+}browser_tabs2 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / urlAdded value: +{
+ "description": "URL to navigate to in the new tab, used for new.",
+ "type": "string"
+}browser_take_screenshot5 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / element / descriptionPrevious value: -"Human-readable element description used to obtain permission to screenshot the element. If not provided, the screenshot will be taken of viewport. If element is provided, ref must be provided too."New value: +"Human-readable element description used to obtain permission to interact with the element"Input schema / properties / refRemoved value: -{
- "description": "Exact target element reference from the page snapshot. If not provided, the screenshot will be taken of viewport. If ref is provided, element must be provided too.",
- "type": "string"
-}Input schema / properties / targetAdded value: +{
+ "description": "Exact target element reference from the page snapshot, or a unique element selector",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "type"
+]browser_type4 fields changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"Input schema / properties / refRemoved value: -{
- "description": "Exact target element reference from the page snapshot",
- "type": "string"
-}Input schema / properties / targetAdded value: +{
+ "description": "Exact target element reference from the page snapshot, or a unique element selector",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "element",
- "ref",
- "text"
-]New value: +[
+ "target",
+ "text"
+]browser_wait_for1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"v1.0.1browser_click1 field changedInput schema / properties / modifiersAdded value: +{
+ "description": "Modifier keys to press",
+ "items": {
+ "enum": [
+ "Alt",
+ "Control",
+ "ControlOrMeta",
+ "Meta",
+ "Shift"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+}browser_console_messages1 field changedInput schema / properties / levelAdded value: +{
+ "default": "info",
+ "description": "Level of the console messages to return. Each level includes the messages of more severe levels. Defaults to \"info\".",
+ "enum": [
+ "error",
+ "warning",
+ "info",
+ "debug"
+ ],
+ "type": "string"
+}browser_file_upload2 fields changedInput schema / properties / paths / descriptionPrevious value: -"The absolute paths to the files to upload. Can be a single file or multiple files."New value: +"The absolute paths to the files to upload. Can be single file or multiple files. If omitted, file chooser is cancelled."Input schema / requiredRemoved value: -[
- "paths"
-]browser_fill_formbrowser_navigate_forwardbrowser_network_requests1 field changedInput schema / properties / includeStaticAdded value: +{
+ "default": false,
+ "description": "Whether to include successful static resources like images, fonts, scripts, etc. Defaults to false.",
+ "type": "boolean"
+}browser_run_codebrowser_snapshot1 field changedInput schema / properties / filenameAdded value: +{
+ "description": "Save snapshot to markdown file instead of returning it in the response.",
+ "type": "string"
+}browser_tab_closebrowser_tab_listbrowser_tab_newbrowser_tab_selectbrowser_tabsbrowser_take_screenshot1 field changedInput schema / properties / filename / descriptionPrevious value: -"File name to save the screenshot to. Defaults to `page-{timestamp}.{png|jpeg}` if not specified."New value: +"File name to save the screenshot to. Defaults to `page-{timestamp}.{png|jpeg}` if not specified. Prefer relative file names to stay within the output directory."v1.0.0browser_clickbrowser_closebrowser_console_messagesbrowser_dragbrowser_evaluatebrowser_file_uploadbrowser_handle_dialogbrowser_hoverbrowser_installbrowser_navigatebrowser_navigate_backbrowser_navigate_forwardbrowser_network_requestsbrowser_press_keybrowser_resizebrowser_select_optionbrowser_snapshotbrowser_tab_closebrowser_tab_listbrowser_tab_newbrowser_tab_selectbrowser_take_screenshotbrowser_typebrowser_wait_forMost tools have distinct purposes, but there is potential confusion between browser_evaluate and browser_run_code_unsafe (both execute JS, but one is RCE-equivalent) and between browser_snapshot and browser_take_screenshot (descriptions clarify but agent might still misselect). Overall, the tools are well-differentiated.
All tools start with 'browser_', but the naming pattern is inconsistent: some are verbs (browser_click), some verb_noun (browser_fill_form), and some nouns (browser_tabs, browser_network_requests). The mix of styles reduces predictability.
With 24 tools, the set covers a wide range of browser automation actions without being overwhelmingly large. Each tool serves a clear purpose, though a few could be consolidated (e.g., browser_network_request and browser_network_requests).
The tool surface covers most common browser automation tasks: navigation, input, form filling, file upload, network, console, dialogs, tabs, and screenshots. Minor gaps exist (e.g., cookie management, frame handling), but the core workflows are well-supported.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
E2LLM gives your AI eyes and hands in a real browser: structured perception (SiFR) plus action.
A Model Context Protocol server for Wix AI tools
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/microsoft/playwright-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server