Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@playwright/mcp Go to playwright.dev and describe the page structure"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides browser automation capabilities using Playwright. This server enables LLMs to interact with web pages through structured accessibility snapshots, bypassing the need for screenshots or visually-tuned models.
This package provides MCP interface into Playwright. If you are using a coding agent, you might benefit from using the CLI+SKILLS instead.
CLI: Modern coding agents increasingly favor CLI–based workflows exposed as SKILLs over MCP because CLI invocations are more token-efficient: they avoid loading large tool schemas and verbose accessibility trees into the model context, allowing agents to act through concise, purpose-built commands. This makes CLI + SKILLs better suited for high-throughput coding agents that must balance browser automation with large codebases, tests, and reasoning within limited context windows.Learn more about Playwright CLI with SKILLS.
MCP: MCP remains relevant for specialized agentic loops that benefit from persistent state, rich introspection, and iterative reasoning over page structure, such as exploratory automation, self-healing tests, or long-running autonomous workflows where maintaining continuous browser context outweighs token cost concerns.
Fast and lightweight. Uses Playwright's accessibility tree, not pixel-based input.
LLM-friendly. No vision models needed, operates purely on structured data.
Deterministic tool application. Avoids ambiguity common with screenshot-based approaches.
Node.js 18 or newer
VS Code, Cursor, Windsurf, Claude Desktop, Goose, Junie or any other MCP client
First, install the Playwright MCP server with your client.
Standard config works in most of the tools:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}
Add via the Amp VS Code extension settings screen or by updating your settings.json file:
"amp.mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}Amp CLI Setup:
Add via the amp mcp addcommand below
amp mcp add playwright -- npx @playwright/mcp@latestAdd via the Antigravity settings or by updating your configuration file:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}Use the Claude Code CLI to add the Playwright MCP server:
claude mcp add playwright npx @playwright/mcp@latestFollow the MCP install guide, use the standard config above.
Follow the instruction in the section Configuring MCP Servers
Example: Local Setup
Add the following to your cline_mcp_settings.json file:
{
"mcpServers": {
"playwright": {
"type": "stdio",
"command": "npx",
"timeout": 30,
"args": [
"-y",
"@playwright/mcp@latest"
],
"disabled": false
}
}
}Use the Codex CLI to add the Playwright MCP server:
codex mcp add playwright npx "@playwright/mcp@latest"Alternatively, create or edit the configuration file ~/.codex/config.toml and add:
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]For more information, see the Codex MCP documentation.
Use the Copilot CLI to interactively add the Playwright MCP server:
/mcp addAlternatively, create or edit the configuration file ~/.copilot/mcp-config.json and add:
{
"mcpServers": {
"playwright": {
"type": "local",
"command": "npx",
"tools": [
"*"
],
"args": [
"@playwright/mcp@latest"
]
}
}
}For more information, see the Copilot CLI documentation.
Go to Cursor Settings -> MCP -> Add new MCP Server. Name to your liking, use command type with the command npx @playwright/mcp@latest. You can also verify config or add command like arguments via clicking Edit.
Use the Factory CLI to add the Playwright MCP server:
droid mcp add playwright "npx @playwright/mcp@latest"Alternatively, type /mcp within Factory droid to open an interactive UI for managing MCP servers.
For more information, see the Factory MCP documentation.
Follow the MCP install guide, use the standard config above.
Go to Advanced settings -> Extensions -> Add custom extension. Name to your liking, use type STDIO, and set the command to npx @playwright/mcp. Click "Add Extension".
To add the Playwright MCP server in Junie CLI:
Type /mcp
Press Ctrl+A to add a new MCP server
Select Playwright from the list
Alternatively, add to .junie/mcp/mcp.json:
{
"mcpServers": {
"Playwright": {
"command": "npx",
"args": [
"-y",
"@playwright/mcp@latest"
]
}
}
}For more information, see the Junie MCP configuration documentation.
Follow the MCP Servers documentation. For example in .kiro/settings/mcp.json:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}
Go to Program in the right sidebar -> Install -> Edit mcp.json. Use the standard config above.
Follow the MCP Servers documentation. For example in ~/.config/opencode/opencode.json:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"playwright": {
"type": "local",
"command": [
"npx",
"@playwright/mcp@latest"
],
"enabled": true
}
}
}
Open Qodo Gen chat panel in VSCode or IntelliJ → Connect more tools → + Add new MCP → Paste the standard config above.
Click Save.
Follow the MCP install guide, use the standard config above. You can also install the Playwright MCP server using the VS Code CLI:
# For VS Code
code --add-mcp '{"name":"playwright","command":"npx","args":["@playwright/mcp@latest"]}'After installation, the Playwright MCP server will be available for use with your GitHub Copilot agent in VS Code.
Go to Settings -> AI -> Manage MCP Servers -> + Add to add an MCP Server. Use the standard config above.
Alternatively, use the slash command /add-mcp in the Warp prompt and paste the standard config from above:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}Follow Windsurf MCP documentation. Use the standard config above.
Playwright MCP server supports following arguments. They can be provided in the JSON configuration above, as a part of the "args" list:
Option | Description |
--allowed-hosts <hosts...> | comma-separated list of hosts this server is allowed to serve from. Defaults to the host the server is bound to. Pass '*' to disable the host check.env |
--allowed-origins | semicolon-separated list of TRUSTED origins to allow the browser to request. Default is to allow all. Important: does not serve as a security boundary and does not affect redirects.env |
--allow-unrestricted-file-access | allow access to files outside of the workspace roots. Also allows unrestricted access to file:// URLs. By default access to file system is restricted to workspace root directories (or cwd if no roots are configured) only, and navigation to file:// URLs is blocked.env |
--blocked-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. Important: does not serve as a security boundary and does not affect redirects.env |
--block-service-workers | block service workersenv |
--browser | browser or chrome channel to use, possible values: chrome, firefox, webkit, msedge.env |
--caps | comma-separated list of additional capabilities to enable, possible values: vision, pdf, devtools.env |
--cdp-endpoint | CDP endpoint to connect to.env |
--cdp-header <headers...> | CDP headers to send with the connect request, multiple can be specified.env |
--cdp-timeout | timeout in milliseconds for connecting to CDP endpoint, defaults to 30000msenv |
--codegen | specify the language to use for code generation, possible values: "typescript", "none". Default is "typescript".env |
--config | path to the configuration file.env |
--console-level | level of console messages to return: "error", "warning", "info", "debug". Each level includes the messages of more severe levels.env |
--device | device to emulate, for example: "iPhone 15"env |
--executable-path | path to the browser executable.env |
--extension | Connect to a running browser instance (Edge/Chrome only). Requires the "Playwright Extension" to be installed.env |
--endpoint | Bound browser endpoint to connect to.env |
--grant-permissions <permissions...> | List of permissions to grant to the browser context, for example "geolocation", "clipboard-read", "clipboard-write".env |
--headless | run browser in headless mode, headed by defaultenv |
--host | host to bind server to. Default is localhost. Use 0.0.0.0 to bind to all interfaces.env |
--ignore-https-errors | ignore https errorsenv |
--init-page <path...> | path to TypeScript file to evaluate on Playwright page objectenv |
--init-script <path...> | path to JavaScript file to add as an initialization script. The script will be evaluated in every page before any of the page's scripts. Can be specified multiple times.env |
--isolated | keep the browser profile in memory, do not save it to disk.env |
--image-responses | whether to send image responses to the client. Can be "allow" or "omit", Defaults to "allow".env |
--no-sandbox | disable the sandbox for all process types that are normally sandboxed.env |
--output-dir | path to the directory for output files.env |
--output-mode | whether to save snapshots, console messages, network logs to a file or to the standard output. Can be "file" or "stdout". Default is "stdout".env |
--port | port to listen on for SSE transport.env |
--proxy-bypass | comma-separated domains to bypass proxy, for example ".com,chromium.org,.domain.com"env |
--proxy-server | specify proxy server, for example "http://myproxy:3128" or "socks5://myproxy:8080"env |
--sandbox | enable the sandbox for all process types that are normally not sandboxed.env |
--save-session | Whether to save the Playwright MCP session into the output directory.env |
--secrets | path to a file containing secrets in the dotenv formatenv |
--shared-browser-context | reuse the same browser context between all connected HTTP clients.env |
--snapshot-mode | when taking snapshots for responses, specifies the mode to use. Can be "full" or "none". Default is "full".env |
--storage-state | path to the storage state file for isolated sessions.env |
--test-id-attribute | specify the attribute to use for test ids, defaults to "data-testid"env |
--timeout-action | specify action timeout in milliseconds, defaults to 5000msenv |
--timeout-navigation | specify navigation timeout in milliseconds, defaults to 60000msenv |
--user-agent | specify user agent stringenv |
--user-data-dir | path to the user data directory. If not specified, a temporary directory will be created.env |
--viewport-size | specify browser viewport size in pixels, for example "1280x720"env |
You can run Playwright MCP with persistent profile like a regular browser (default), in isolated contexts for testing sessions, or connect to your existing browser using the browser extension.
Persistent profile
All the logged in information will be stored in the persistent profile, you can delete it between sessions if you'd like to clear the offline state.
Persistent profile is located at the following locations and you can override it with the --user-data-dir argument.
# Windows
%USERPROFILE%\AppData\Local\ms-playwright\mcp-{channel}-{workspace-hash}
# macOS
- ~/Library/Caches/ms-playwright/mcp-{channel}-{workspace-hash}
# Linux
- ~/.cache/ms-playwright/mcp-{channel}-{workspace-hash}{workspace-hash} is derived from the MCP client's workspace root, so different projects get separate profiles automatically.
Isolated
In the isolated mode, each session is started in the isolated profile. Every time you ask MCP to close the browser,
the session is closed and all the storage state for this session is lost. You can provide initial storage state
to the browser via the config's contextOptions or via the --storage-state argument. Learn more about the storage
state here.
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest",
"--isolated",
"--storage-state={path/to/storage.json}"
]
}
}
}Browser Extension
The Playwright MCP Chrome Extension allows you to connect to existing browser tabs and leverage your logged-in sessions and browser state. See microsoft/playwright › packages/extension for installation and setup instructions.
There are multiple ways to provide the initial state to the browser context or a page.
For the storage state, you can either:
Start with a user data directory using the --user-data-dir argument. This will persist all browser data between the sessions.
Start with a storage state file using the --storage-state argument. This will load cookies and local storage from the file into an isolated browser context.
For the page state, you can use:
--init-page to point to a TypeScript file that will be evaluated on the Playwright page object. This allows you to run arbitrary code to set up the page.
// init-page.ts
export default async ({ page }) => {
await page.context().grantPermissions(['geolocation']);
await page.context().setGeolocation({ latitude: 37.7749, longitude: -122.4194 });
await page.setViewportSize({ width: 1280, height: 720 });
};--init-script to point to a JavaScript file that will be added as an initialization script. The script will be evaluated in every page before any of the page's scripts.
This is useful for overriding browser APIs or setting up the environment.
// init-script.js
window.isPlaywrightMCP = true;The Playwright MCP server can be configured using a JSON configuration file. You can specify the configuration file
using the --config command line option:
npx @playwright/mcp@latest --config path/to/config.json{
/**
* The browser to use.
*/
browser?: {
/**
* The type of browser to use.
*/
browserName?: 'chromium' | 'firefox' | 'webkit';
/**
* Keep the browser profile in memory, do not save it to disk.
*/
isolated?: boolean;
/**
* Path to a user data directory for browser profile persistence.
* Temporary directory is created by default.
*/
userDataDir?: string;
/**
* Launch options passed to
* @see https://playwright.dev/docs/api/class-browsertype#browser-type-launch-persistent-context
*
* This is useful for settings options like `channel`, `headless`, `executablePath`, etc.
*/
launchOptions?: playwright.LaunchOptions;
/**
* Context options for the browser context.
*
* This is useful for settings options like `viewport`.
*/
contextOptions?: playwright.BrowserContextOptions;
/**
* Chrome DevTools Protocol endpoint to connect to an existing browser instance in case of Chromium family browsers.
*/
cdpEndpoint?: string;
/**
* CDP headers to send with the connect request.
*/
cdpHeaders?: Record<string, string>;
/**
* Timeout in milliseconds for connecting to CDP endpoint. Defaults to 30000 (30 seconds). Pass 0 to disable timeout.
*/
cdpTimeout?: number;
/**
* Remote endpoint to connect to an existing Playwright server.
*/
remoteEndpoint?: string;
/**
* Paths to TypeScript files to add as initialization scripts for Playwright page.
*/
initPage?: string[];
/**
* Paths to JavaScript files to add as initialization scripts.
* The scripts will be evaluated in every page before any of the page's scripts.
*/
initScript?: string[];
},
/**
* Connect to a running browser instance (Edge/Chrome only). If specified, `browser`
* config is ignored.
* Requires the "Playwright Extension" to be installed.
*/
extension?: boolean;
server?: {
/**
* The port to listen on for SSE or MCP transport.
*/
port?: number;
/**
* The host to bind the server to. Default is localhost. Use 0.0.0.0 to bind to all interfaces.
*/
host?: string;
/**
* The hosts this server is allowed to serve from. Defaults to the host server is bound to.
* This is not for CORS, but rather for the DNS rebinding protection.
*/
allowedHosts?: string[];
},
/**
* List of enabled tool capabilities. Possible values:
* - 'core': Core browser automation features.
* - 'pdf': PDF generation and manipulation.
* - 'vision': Coordinate-based interactions.
* - 'devtools': Developer tools features.
*/
capabilities?: ToolCapability[];
/**
* Whether to save the Playwright session into the output directory.
*/
saveSession?: boolean;
/**
* Reuse the same browser context between all connected HTTP clients.
*/
sharedBrowserContext?: boolean;
/**
* Secrets are used to replace matching plain text in the tool responses to prevent the LLM
* from accidentally getting sensitive data. It is a convenience and not a security feature,
* make sure to always examine information coming in and from the tool on the client.
*/
secrets?: Record<string, string>;
/**
* The directory to save output files.
*/
outputDir?: string;
console?: {
/**
* The level of console messages to return. Each level includes the messages of more severe levels. Defaults to "info".
*/
level?: 'error' | 'warning' | 'info' | 'debug';
},
network?: {
/**
* List of origins to allow the browser to request. Default is to allow all. Origins matching both `allowedOrigins` and `blockedOrigins` will be blocked.
*
* Supported formats:
* - Full origin: `https://example.com:8080` - matches only that origin
* - Wildcard port: `http://localhost:*` - matches any port on localhost with http protocol
*/
allowedOrigins?: string[];
/**
* List of origins to block the browser to request. Origins matching both `allowedOrigins` and `blockedOrigins` will be blocked.
*
* Supported formats:
* - Full origin: `https://example.com:8080` - matches only that origin
* - Wildcard port: `http://localhost:*` - matches any port on localhost with http protocol
*/
blockedOrigins?: string[];
};
/**
* Specify the attribute to use for test ids, defaults to "data-testid".
*/
testIdAttribute?: string;
timeouts?: {
/*
* Configures default action timeout: https://playwright.dev/docs/api/class-page#page-set-default-timeout. Defaults to 5000ms.
*/
action?: number;
/*
* Configures default navigation timeout: https://playwright.dev/docs/api/class-page#page-set-default-navigation-timeout. Defaults to 60000ms.
*/
navigation?: number;
/**
* Configures default expect timeout: https://playwright.dev/docs/test-timeouts#expect-timeout. Defaults to 5000ms.
*/
expect?: number;
};
/**
* Whether to send image responses to the client. Can be "allow", "omit", or "auto". Defaults to "auto", which sends images if the client can display them.
*/
imageResponses?: 'allow' | 'omit';
snapshot?: {
/**
* When taking snapshots for responses, specifies the mode to use.
*/
mode?: 'full' | 'none';
};
/**
* allowUnrestrictedFileAccess acts as a guardrail to prevent the LLM from accidentally
* wandering outside its intended workspace. It is a convenience defense to catch unintended
* file access, not a secure boundary; a deliberate attempt to reach other directories can be
* easily worked around, so always rely on client-level permissions for true security.
*/
allowUnrestrictedFileAccess?: boolean;
/**
* Specify the language to use for code generation.
*/
codegen?: 'typescript' | 'none';
}When running headed browser on system w/o display or from worker processes of the IDEs,
run the MCP server from environment with the DISPLAY and pass the --port flag to enable HTTP transport.
npx @playwright/mcp@latest --port 8931And then in MCP client config, set the url to the HTTP endpoint:
{
"mcpServers": {
"playwright": {
"url": "http://localhost:8931/mcp"
}
}
}Related MCP server: Playwright MCP
Playwright MCP is not a security boundary. See MCP Security Best Practices for guidance on securing your deployment.
NOTE: The Docker implementation only supports headless chromium at the moment.
{
"mcpServers": {
"playwright": {
"command": "docker",
"args": ["run", "-i", "--rm", "--init", "--pull=always", "mcr.microsoft.com/playwright/mcp"]
}
}
}Or If you prefer to run the container as a long-lived service instead of letting the MCP client spawn it, use:
docker run -d -i --rm --init --pull=always \
--entrypoint node \
--name playwright \
-p 8931:8931 \
mcr.microsoft.com/playwright/mcp \
cli.js --headless --browser chromium --no-sandbox --port 8931 --host 0.0.0.0The server will listen on host port 8931 and can be reached by any MCP client.
You can build the Docker image yourself.
docker build -t mcr.microsoft.com/playwright/mcp .import http from 'http';
import { createConnection } from '@playwright/mcp';
import { SSEServerTransport } from '@modelcontextprotocol/sdk/server/sse.js';
http.createServer(async (req, res) => {
// ...
// Creates a headless Playwright MCP server with SSE transport
const connection = await createConnection({ browser: { launchOptions: { headless: true } } });
const transport = new SSEServerTransport('/messages', res);
await connection.connect(transport);
// ...
});browser_click
Title: Click
Description: Perform click on a web page
Parameters:
element (string, optional): Human-readable element description used to obtain permission to interact with the element
target (string): Exact target element reference from the page snapshot, or a unique element selector
doubleClick (boolean, optional): Whether to perform a double click instead of a single click
button (string, optional): Button to click, defaults to left
modifiers (array, optional): Modifier keys to press
Read-only: false
browser_close
Title: Close browser
Description: Close the page
Parameters: None
Read-only: false
browser_console_messages
Title: Get console messages
Description: Returns all console messages
Parameters:
level (string): Level of the console messages to return. Each level includes the messages of more severe levels. Defaults to "info".
all (boolean, optional): Return all console messages since the beginning of the session, not just since the last navigation. Defaults to false.
filename (string, optional): Filename to save the console messages to. If not provided, messages are returned as text.
Read-only: true
browser_drag
Title: Drag mouse
Description: Perform drag and drop between two elements
Parameters:
startElement (string, optional): Human-readable source element description used to obtain the permission to interact with the element
startTarget (string): Exact target element reference from the page snapshot, or a unique element selector
endElement (string, optional): Human-readable target element description used to obtain the permission to interact with the element
endTarget (string): Exact target element reference from the page snapshot, or a unique element selector
Read-only: false
browser_drop
Title: Drop files or data onto an element
Description: 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.
Parameters:
element (string, optional): Human-readable element description used to obtain permission to interact with the element
target (string): Exact target element reference from the page snapshot, or a unique element selector
paths (array, optional): Absolute paths to files to drop onto the element.
data (object, optional): Data to drop, as a map of MIME type to string value (e.g. {"text/plain": "hello", "text/uri-list": "https://example.com"}).
Read-only: false
browser_evaluate
Title: Evaluate JavaScript
Description: Evaluate JavaScript expression on page or element
Parameters:
element (string, optional): Human-readable element description used to obtain permission to interact with the element
target (string, optional): Exact target element reference from the page snapshot, or a unique element selector
function (string): () => { /* code / } or (element) => { / code */ } when element is provided
filename (string, optional): Filename to save the result to. If not provided, result is returned as text.
Read-only: false
browser_file_upload
Title: Upload files
Description: Upload one or multiple files
Parameters:
paths (array, optional): The absolute paths to the files to upload. Can be single file or multiple files. If omitted, file chooser is cancelled.
Read-only: false
browser_fill_form
Title: Fill form
Description: Fill multiple form fields
Parameters:
fields (array): Fields to fill in
Read-only: false
browser_handle_dialog
Title: Handle a dialog
Description: Handle a dialog
Parameters:
accept (boolean): Whether to accept the dialog.
promptText (string, optional): The text of the prompt in case of a prompt dialog.
Read-only: false
browser_hover
Title: Hover mouse
Description: Hover over element on page
Parameters:
element (string, optional): Human-readable element description used to obtain permission to interact with the element
target (string): Exact target element reference from the page snapshot, or a unique element selector
Read-only: false
browser_navigate
Title: Navigate to a URL
Description: Navigate to a URL
Parameters:
url (string): The URL to navigate to
Read-only: false
browser_navigate_back
Title: Go back
Description: Go back to the previous page in the history
Parameters: None
Read-only: false
browser_network_request
Title: Show network request details
Description: 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.
Parameters:
index (integer): 1-based index of the request, as printed by browser_network_requests.
part (string, optional): Return only this part of the request. Omit to return full details.
filename (string, optional): Filename to save the result to. If not provided, output is returned as text.
Read-only: true
browser_network_requests
Title: List network requests
Description: Returns a numbered list of network requests since loading the page. Use browser_network_request with the number to get full details.
Parameters:
static (boolean): Whether to include successful static resources like images, fonts, scripts, etc. Defaults to false.
filter (string, optional): Only return requests whose URL matches this regexp (e.g. "/api/.*user").
filename (string, optional): Filename to save the network requests to. If not provided, requests are returned as text.
Read-only: true
browser_press_key
Title: Press a key
Description: Press a key on the keyboard
Parameters:
key (string): Name of the key to press or a character to generate, such as ArrowLeft or a
Read-only: false
browser_resize
Title: Resize browser window
Description: Resize the browser window
Parameters:
width (number): Width of the browser window
height (number): Height of the browser window
Read-only: false
browser_run_code_unsafe
Title: Run Playwright code (unsafe)
Description: Run a Playwright code snippet. Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent.
Parameters:
code (string, optional): 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 (string, optional): Load code from the specified file. If both code and filename are provided, code will be ignored.
Read-only: false
browser_select_option
Title: Select option
Description: Select an option in a dropdown
Parameters:
element (string, optional): Human-readable element description used to obtain permission to interact with the element
target (string): Exact target element reference from the page snapshot, or a unique element selector
values (array): Array of values to select in the dropdown. This can be a single value or multiple values.
Read-only: false
browser_snapshot
Title: Page snapshot
Description: Capture accessibility snapshot of the current page, this is better than screenshot
Parameters:
target (string, optional): Exact target element reference from the page snapshot, or a unique element selector
filename (string, optional): Save snapshot to markdown file instead of returning it in the response.
depth (number, optional): Limit the depth of the snapshot tree
boxes (boolean, optional): Include each element's bounding box as [box=x,y,width,height] in the snapshot
Read-only: true
browser_take_screenshot
Title: Take a screenshot
Description: Take a screenshot of the current page. You can't perform actions based on the screenshot, use browser_snapshot for actions.
Parameters:
element (string, optional): Human-readable element description used to obtain permission to interact with the element
target (string, optional): Exact target element reference from the page snapshot, or a unique element selector
type (string): Image format for the screenshot. Default is png.
filename (string, optional): 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.
fullPage (boolean, optional): When true, takes a screenshot of the full scrollable page, instead of the currently visible viewport. Cannot be used with element screenshots.
Read-only: true
browser_type
Title: Type text
Description: Type text into editable element
Parameters:
element (string, optional): Human-readable element description used to obtain permission to interact with the element
target (string): Exact target element reference from the page snapshot, or a unique element selector
text (string): Text to type into the element
submit (boolean, optional): Whether to submit entered text (press Enter after)
slowly (boolean, optional): 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.
Read-only: false
browser_wait_for
Title: Wait for
Description: Wait for text to appear or disappear or a specified time to pass
Parameters:
time (number, optional): The time to wait in seconds
text (string, optional): The text to wait for
textGone (string, optional): The text to wait for to disappear
Read-only: false
browser_tabs
Title: Manage tabs
Description: List, create, close, or select a browser tab.
Parameters:
action (string): Operation to perform
index (number, optional): Tab index, used for close/select. If omitted for close, current tab is closed.
url (string, optional): URL to navigate to in the new tab, used for new.
Read-only: false
browser_get_config
Title: Get config
Description: Get the final resolved config after merging CLI options, environment variables and config file.
Parameters: None
Read-only: true
browser_network_state_set
Title: Set network state
Description: Sets the browser network state to online or offline. When offline, all network requests will fail.
Parameters:
state (string): Set to "offline" to simulate offline mode, "online" to restore network connectivity
Read-only: false
browser_route
Title: Mock network requests
Description: Set up a route to mock network requests matching a URL pattern
Parameters:
pattern (string): URL pattern to match (e.g., "/api/users", "/*.{png,jpg}")
status (number, optional): HTTP status code to return (default: 200)
body (string, optional): Response body (text or JSON string)
contentType (string, optional): Content-Type header (e.g., "application/json", "text/html")
headers (array, optional): Headers to add in "Name: Value" format
removeHeaders (string, optional): Comma-separated list of header names to remove from request
Read-only: false
browser_route_list
Title: List network routes
Description: List all active network routes
Parameters: None
Read-only: true
browser_unroute
Title: Remove network routes
Description: Remove network routes matching a pattern (or all routes if no pattern specified)
Parameters:
pattern (string, optional): URL pattern to unroute (omit to remove all routes)
Read-only: false
browser_cookie_clear
Title: Clear cookies
Description: Clear all cookies
Parameters: None
Read-only: false
browser_cookie_delete
Title: Delete cookie
Description: Delete a specific cookie
Parameters:
name (string): Cookie name to delete
Read-only: false
browser_cookie_get
Title: Get cookie
Description: Get a specific cookie by name
Parameters:
name (string): Cookie name to get
Read-only: true
browser_cookie_list
Title: List cookies
Description: List all cookies (optionally filtered by domain/path)
Parameters:
domain (string, optional): Filter cookies by domain
path (string, optional): Filter cookies by path
Read-only: true
browser_cookie_set
Title: Set cookie
Description: Set a cookie with optional flags (domain, path, expires, httpOnly, secure, sameSite)
Parameters:
name (string): Cookie name
value (string): Cookie value
domain (string, optional): Cookie domain
path (string, optional): Cookie path
expires (number, optional): Cookie expiration as Unix timestamp
httpOnly (boolean, optional): Whether the cookie is HTTP only
secure (boolean, optional): Whether the cookie is secure
sameSite (string, optional): Cookie SameSite attribute
Read-only: false
browser_localstorage_clear
Title: Clear localStorage
Description: Clear all localStorage
Parameters: None
Read-only: false
browser_localstorage_delete
Title: Delete localStorage item
Description: Delete a localStorage item
Parameters:
key (string): Key to delete
Read-only: false
browser_localstorage_get
Title: Get localStorage item
Description: Get a localStorage item by key
Parameters:
key (string): Key to get
Read-only: true
browser_localstorage_list
Title: List localStorage
Description: List all localStorage key-value pairs
Parameters: None
Read-only: true
browser_localstorage_set
Title: Set localStorage item
Description: Set a localStorage item
Parameters:
key (string): Key to set
value (string): Value to set
Read-only: false
browser_sessionstorage_clear
Title: Clear sessionStorage
Description: Clear all sessionStorage
Parameters: None
Read-only: false
browser_sessionstorage_delete
Title: Delete sessionStorage item
Description: Delete a sessionStorage item
Parameters:
key (string): Key to delete
Read-only: false
browser_sessionstorage_get
Title: Get sessionStorage item
Description: Get a sessionStorage item by key
Parameters:
key (string): Key to get
Read-only: true
browser_sessionstorage_list
Title: List sessionStorage
Description: List all sessionStorage key-value pairs
Parameters: None
Read-only: true
browser_sessionstorage_set
Title: Set sessionStorage item
Description: Set a sessionStorage item
Parameters:
key (string): Key to set
value (string): Value to set
Read-only: false
browser_set_storage_state
Title: Restore storage state
Description: Restore storage state (cookies, local storage) from a file. This clears existing cookies and local storage before restoring.
Parameters:
filename (string): Path to the storage state file to restore from
Read-only: false
browser_storage_state
Title: Save storage state
Description: Save storage state (cookies, local storage) to a file for later reuse
Parameters:
filename (string, optional): File name to save the storage state to. Defaults to storage-state-{timestamp}.json if not specified.
Read-only: true
browser_annotate
Title: Annotate the current page
Description: Open the Playwright Dashboard in annotation mode for the current page and wait for the user to draw annotations. Returns the annotated screenshot, ARIA snapshot, and the list of annotations.
Parameters: None
Read-only: true
browser_hide_highlight
Title: Hide element highlight
Description: Remove a highlight overlay previously added for the element.
Parameters:
element (string, optional): Human-readable element description used when adding the highlight; must match the value passed to browser_highlight.
target (string, optional): Exact target element reference from the page snapshot, or a unique element selector
Read-only: true
browser_highlight
Title: Highlight element
Description: Show a persistent highlight overlay around the element on the page.
Parameters:
element (string, optional): Human-readable element description used to obtain permission to interact with the element
target (string): Exact target element reference from the page snapshot, or a unique element selector
style (string, optional): Additional inline CSS applied to the highlight overlay, e.g. "outline: 2px dashed red".
Read-only: true
browser_resume
Title: Resume paused script execution
Description: Resume script execution after it was paused. When called with step set to true, execution will pause again before the next action.
Parameters:
step (boolean, optional): When true, execution will pause again before the next action, allowing step-by-step debugging.
location (string, optional): Pause execution at a specific :, e.g. "example.spec.ts:42".
Read-only: false
browser_start_tracing
Title: Start tracing
Description: Start trace recording
Parameters: None
Read-only: true
browser_start_video
Title: Start video
Description: Start video recording
Parameters:
filename (string, optional): Filename to save the video.
size (object, optional): Video size
Read-only: true
browser_stop_tracing
Title: Stop tracing
Description: Stop trace recording
Parameters: None
Read-only: true
browser_stop_video
Title: Stop video
Description: Stop video recording
Parameters: None
Read-only: true
browser_video_chapter
Title: Video chapter
Description: Add a chapter marker to the video recording. Shows a full-screen chapter card with blurred backdrop.
Parameters:
title (string): Chapter title
description (string, optional): Chapter description
duration (number, optional): Duration in milliseconds to show the chapter card
Read-only: true
browser_mouse_click_xy
Title: Click
Description: Click mouse button at a given position
Parameters:
x (number): X coordinate
y (number): Y coordinate
button (string, optional): Button to click, defaults to left
clickCount (number, optional): Number of clicks, defaults to 1
delay (number, optional): Time to wait between mouse down and mouse up in milliseconds, defaults to 0
Read-only: false
browser_mouse_down
Title: Press mouse down
Description: Press mouse down
Parameters:
button (string, optional): Button to press, defaults to left
Read-only: false
browser_mouse_drag_xy
Title: Drag mouse
Description: Drag left mouse button to a given position
Parameters:
startX (number): Start X coordinate
startY (number): Start Y coordinate
endX (number): End X coordinate
endY (number): End Y coordinate
Read-only: false
browser_mouse_move_xy
Title: Move mouse
Description: Move mouse to a given position
Parameters:
x (number): X coordinate
y (number): Y coordinate
Read-only: false
browser_mouse_up
Title: Press mouse up
Description: Press mouse up
Parameters:
button (string, optional): Button to press, defaults to left
Read-only: false
browser_mouse_wheel
Title: Scroll mouse wheel
Description: Scroll mouse wheel
Parameters:
deltaX (number): X delta
deltaY (number): Y delta
Read-only: false
browser_pdf_save
Title: Save as PDF
Description: Save page as PDF
Parameters:
filename (string, optional): File name to save the pdf to. Defaults to page-{timestamp}.pdf if not specified. Prefer relative file names to stay within the output directory.
Read-only: true
browser_generate_locator
Title: Create locator for element
Description: Generate locator for the given element to use in tests
Parameters:
element (string, optional): Human-readable element description used to obtain permission to interact with the element
target (string): Exact target element reference from the page snapshot, or a unique element selector
Read-only: true
browser_verify_element_visible
Title: Verify element visible
Description: Verify element is visible on the page
Parameters:
role (string): ROLE of the element. Can be found in the snapshot like this: - {ROLE} "Accessible Name":
accessibleName (string): ACCESSIBLE_NAME of the element. Can be found in the snapshot like this: - role "{ACCESSIBLE_NAME}"
Read-only: false
browser_verify_list_visible
Title: Verify list visible
Description: Verify list is visible on the page
Parameters:
element (string): Human-readable list description
target (string): Exact target element reference that points to the list
items (array): Items to verify
Read-only: false
browser_verify_text_visible
Title: Verify text visible
Description: Verify text is visible on the page. Prefer browser_verify_element_visible if possible.
Parameters:
text (string): TEXT to verify. Can be found in the snapshot like this: - role "Accessible Name": {TEXT} or like this: - text: {TEXT}
Read-only: false
browser_verify_value
Title: Verify value
Description: Verify element value
Parameters:
type (string): Type of the element
element (string): Human-readable element description
target (string): Exact target element reference from the page snapshot
value (string): Value to verify. For checkbox, use "true" or "false".
Read-only: false
Perform click on a web page
| Name | Required | Description | Default |
|---|---|---|---|
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| doubleClick | No | Whether to perform a double click instead of a single click | |
| button | No | Button to click, defaults to left | |
| modifiers | No | Modifier keys to press |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true and openWorldHint=true. Description adds no further behavioral context beyond the obvious. No 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?
Single sentence, no redundant information. Highly concise and front-loaded.
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 click action's effects are generally understood. Could mention post-click behavior (e.g., navigation), but not necessary given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. Description does not add additional 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?
Description clearly states 'Perform click on a web page', using a specific verb and resource. It distinguishes from sibling tools like browser_drag or browser_type.
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 like browser_hover or browser_type. No prerequisites or when-not-to-use context provided.
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 include destructiveHint: true, indicating destructive behavior. The description adds no further behavioral context, such as what happens to unsaved data or if confirmation is required. Given annotations already signal destructiveness, the description meets the minimum bar but does not enhance transparency.
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 with no wasted words. It is appropriately sized for a parameterless 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?
While the tool is simple with no parameters and annotations cover destructiveness, the description lacks clarity on whether it closes the current tab or the entire browser. Given the sibling tools include browser_tabs, this ambiguity affects 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?
The tool has zero parameters, and schema coverage is 100% trivially. No additional meaning is needed beyond the tool's existence.
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 'Close the page', which is a specific verb-resource pair. It distinguishes from sibling tools like browser_navigate and browser_tabs. However, the annotation title says 'Close browser', causing slight ambiguity about whether it closes the current page or the entire browser.
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_navigate or browser_tabs. There is no mention of when not to use it or prerequisites.
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 |
|---|---|---|---|
| level | Yes | Level of the console messages to return. Each level includes the messages of more severe levels. Defaults to "info". | info |
| all | No | Return all console messages since the beginning of the session, not just since the last navigation. Defaults to false. | |
| 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?
Description adds no behavioral context beyond annotations. Annotations indicate a safe read operation, but description does not mention filtering behavior, scope, or potential sensitivities.
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 is efficient and front-loaded. Could be more informative while remaining concise.
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?
Tool has multiple parameters and no output schema, but description is minimal. Lacks details on return format, level hierarchy, and file saving 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 provides full parameter descriptions (100% coverage), so the description need not repeat them. However, it misses the opportunity to hint at filtering or file-saving functionality.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns console messages, distinguishing it from sibling browser action tools. However, it could be more precise about filtering by level and session scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., other browser inspection tools). Lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform drag and drop between two elements
| Name | Required | Description | Default |
|---|---|---|---|
| startElement | No | Human-readable source 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 | |
| endElement | No | Human-readable target element description used to obtain the permission to interact with the element | |
| endTarget | Yes | Exact target element reference from the page snapshot, or a unique element selector |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and open-world behavior. The description adds no further behavioral details (e.g., mouse event simulation, element visibility requirements).
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 sentence that is front-loaded and contains no unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and lacks details on return behavior, failure handling, or side effects. For a complex action like drag-and-drop, more context would be beneficial.
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%, and the tool description provides no additional meaning beyond what the schema already specifies for parameters. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (drag and drop) and the resource (elements). It is specific but does not differentiate from sibling tool 'browser_drop', which may have overlapping functionality.
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_click or browser_drop. 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.
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 |
|---|---|---|---|
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| paths | No | Absolute paths to files to drop onto the element. | |
| 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"}). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide destructiveHint=true and openWorldHint=true. The description adds context by stating the action simulates a drop from outside the page, but does not elaborate on side effects or error scenarios.
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: first defines the action, second states the required constraint. No unnecessary 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?
No output schema is provided, and the description does not explain what happens after a successful drop (e.g., return value, state changes). For a tool with destructiveHint, more completeness would be helpful.
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% description coverage for all four parameters. The description reiterates the constraint on 'paths' and 'data', which is not in the schema, adding minor value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool drops files or MIME-typed data onto an element, simulating external drag-and-drop. It distinguishes from sibling tools like browser_drag (internal drag) and browser_file_upload (file input upload).
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 mentions the constraint that at least one of 'paths' or 'data' must be provided, but does not specify when to use this tool over alternatives like browser_file_upload or browser_type, nor any prerequisites.
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 |
|---|---|---|---|
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| target | No | Exact target element reference from the page snapshot, or a unique element selector | |
| function | Yes | () => { /* code */ } or (element) => { /* code */ } when element is provided | |
| filename | No | Filename to save the result to. If not provided, result is returned as text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and open-world behavior, but the description adds no further behavioral context (e.g., side effects on the page, access to browser APIs, persistence). It fails to elaborate beyond the schema and 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, clear sentence with no wasted words. It is front-loaded with 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?
Without an output schema, the description should indicate what the tool returns (result of expression, errors, etc.). It also lacks context on how 'element' and 'target' interact, and does not address the implications of the open-world 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?
Schema coverage is 100% with descriptions for all four parameters. The description does not add significant meaning beyond the schema, 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 clearly states the action ('evaluate'), the resource ('JavaScript expression'), and the scope ('on page or element'). It is specific and distinguishes this tool from sibling tools like browser_click or browser_navigate.
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_run_code_unsafe, or on safety considerations (e.g., destructiveHint, openWorldHint). The agent receives no context for selection.
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 already indicate destructiveHint: true and readOnlyHint: false, implying a mutation operation. The description's 'Upload' is consistent with this, but it adds no further behavioral context (e.g., that it opens a file dialog, requires absolute paths, or that omitting paths cancels the dialog). Without annotations, this would be a gap, but annotations partially compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core action concisely and is front-loaded. It is appropriately sized, though a bit more context (e.g., 'via file chooser') could be added without harming 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 (one optional parameter, no output schema), the description and schema together provide sufficient context. The schema explains cancellation and paths, and annotations cover safety. The tool is complete enough for an agent to use correctly with minimal ambiguity.
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%, and the parameter description in the schema is detailed (absolute paths, single/multiple, cancellation behavior). The tool description adds no additional parameter meaning beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'upload' and the resource 'files', and specifies that it can handle one or multiple files. This clearly distinguishes it from sibling tools like browser_click or browser_navigate, 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?
The description provides no guidance on when to use this tool versus alternatives, such as when to upload files in a browser context. There are no prerequisites, exclusions, or mention of alternatives like fill_form for file inputs.
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?
While annotations indicate destructiveHint=true and openWorldHint=true, the description adds no behavioral context beyond 'Fill multiple form fields'. It does not disclose potential side effects like form submission or event triggering, which the agent might need.
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 one sentence, which is efficient. However, it could include more useful information (e.g., supported field types) without becoming 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 the complexity of form filling and the absence of an output schema, the description is somewhat minimal. It covers the basic purpose but lacks details on return values or edge cases, though the schema provides field types.
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?
With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description adds no additional meaning beyond the schema, so 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 'Fill multiple form fields' is a specific verb+resource, clearly indicating the tool's function. It distinguishes from sibling tools like browser_type (single field) and browser_click by emphasizing multiple fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like browser_type or browser_select_option. It lacks explicit context or exclusions, leaving the agent to infer usage from the name alone.
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, so agent knows it's a mutating action. Description adds minimal extra context, but no contradiction. Bar lowered due to 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?
Very concise (two words), but it is efficient. Could add slight more detail without becoming 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?
Description is too minimal for a tool that handles browser dialogs. It does not explain when dialogs occur, the role of promptText, or that accept is required. Context is insufficient for proper use.
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 schema already documents parameters well. Description adds no new meaning beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states verb (handle) and resource (dialog), which is clear. However, it does not specify what 'handle' entails (accept, dismiss, prompt). The input schema clarifies, but the description could be more precise.
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, or prerequisites like a dialog being open. The description lacks context for proper selection.
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 |
|---|---|---|---|
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector |
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 behavioral details (e.g., triggering hover effects, no visual feedback). Bar is lower due to annotations, but description provides no additional context.
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 waste. Could be more informative without sacrificing 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?
No output schema, and description omits context about behavioral effects or usage scenarios. For a simple action, it lacks completeness to guide 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?
Schema coverage is 100% with descriptions for both parameters. Baseline 3; the description does not add meaning 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 'Hover over element on page' uses a specific verb ('hover') and resource ('element'), clearly distinguishing it from sibling tools like browser_click or browser_drag.
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 such as browser_click, browser_drag, or browser_press_key. The description lacks context for selection.
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 |
|---|---|---|---|
| index | Yes | 1-based index of the request, as printed by browser_network_requests. | |
| part | No | Return only this part of the request. Omit to return full details. | |
| filename | No | Filename to save the result to. If not provided, output is returned as text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's statement about returning details adds minimal behavioral context. There is no mention of side effects or permissions, but no 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?
Two sentences, front-loaded with purpose and a clear usage guide. Every word earns its place with 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?
For a simple read tool with annotations covering safety, the description adequately explains the output (headers and body) and the optional part. It could mention that it requires prior use of browser_network_requests, which it does.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter. The description adds a usage hint for index but does not significantly enhance understanding beyond the schema, keeping the score at 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?
The description clearly states the action (returns full details) and the resource (a single network request), and distinguishes it from the sibling browser_network_requests by referencing the index from that tool. This provides precise context for selection.
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 explicitly tells the agent to use the number from browser_network_requests, establishing a clear sequential dependency. It does not explicitly state when not to use, but the context is sufficient.
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 |
|---|---|---|---|
| static | Yes | Whether to include successful static resources like images, fonts, scripts, etc. Defaults to false. | |
| filter | No | Only return requests whose URL matches this regexp (e.g. "/api/.*user"). | |
| filename | No | Filename to save the network requests to. If not provided, requests are returned as text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint. The description adds that the output is a numbered list, which is useful behavioral context beyond 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?
Single sentence, 21 words, 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?
The tool is simple with full schema coverage. The description plus schema adequately cover functionality, though the output format could be described more precisely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameters. The description does not add additional meaning beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a numbered list of network requests since page load, distinguishing itself from the sibling tool browser_network_request which provides 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?
The description mentions using browser_network_request with the number for full details, providing a clear alternative. However, it lacks explicit when-not-to-use guidance.
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 destructive (destructiveHint=true) and non-read-only (readOnlyHint=false). Description adds no behavioral details such as key hold duration, focus requirements, or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no extraneous information. Highly concise.
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?
A straightforward tool with one parameter and no output schema. The description, while minimal, is sufficient for the simple action, though omission of when to use browser_type over this is a minor 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?
Schema coverage is 100% with a clear description for the 'key' parameter. Description repeats the purpose but does not add semantics 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 'Press a key on the keyboard' clearly states the action and target, distinguishing from siblings like browser_type (typing multiple characters) and browser_click (pointing device).
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 like browser_type or browser_hover. Lacks context for exclusions or prerequisites.
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 indicate destructiveHint: true, so the description adds no behavioral details beyond that. The description does not mention side effects like triggering responsive layout changes, but with annotations present, the burden is partially mitigated.
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 with no extraneous words, achieving maximum conciseness while being clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 required parameters, no output schema) and adequate annotations, the description is minimally acceptable but lacks additional context like typical use or relationship with sibling tools.
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 the width and height parameters. The description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resize the browser window' clearly specifies the verb (resize) and resource (browser window), distinguishing it from sibling tools like browser_navigate or 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 provides no guidance on when to use this tool or when to avoid it. For a simple operation like resizing, minimal guidance might be acceptable, but there is no context about typical use cases (e.g., before taking a screenshot).
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?
Description explicitly warns of RCE-equivalent risk, going beyond annotations (destructiveHint=true) by explaining the mechanism. No 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?
Two concise sentences: first states purpose, second adds critical warning. 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?
For a high-risk tool with 2 params and no output schema, the description covers the nature of execution, risk, and param interaction (code vs filename). Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed param docs. The tool description does not add new meaning beyond 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 runs a Playwright code snippet and highlights it as unsafe/RCE-equivalent, distinguishing it from safer browser tools like browser_evaluate which run JS in page context.
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 only when necessary due to danger, but does not explicitly state when to use or alternatives like browser_evaluate for simple page JS.
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 |
|---|---|---|---|
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true and openWorldHint=true, but the description omits any behavioral traits such as side effects (e.g., triggering events, changing UI state) or error handling. The description adds no value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. It is front-loaded and contains 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?
The tool is a simple action, but the description does not mention return behavior, error scenarios, or events triggered. The absence of an output schema increases the need for such context, but the description only meets minimal requirements.
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% and the schema descriptions adequately explain each parameter. However, the description itself adds no additional meaning beyond what is in the schema, 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 clearly states the verb 'Select an option' and the resource 'dropdown', aligning well with the tool name. It is distinct from sibling tools like browser_click or browser_type, though it does not explicitly contrast with them.
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 typing in input fields, or browser_click for clicking elements). The description does not mention 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.
Capture accessibility snapshot of the current page, this is better than screenshot
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| depth | No | Limit the depth of the snapshot tree | |
| boxes | No | Include each element's bounding box as [box=x,y,width,height] in the snapshot |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and non-destructive, which is consistent with the description. The description adds that it captures an accessibility snapshot, but does not detail what that entails or any behavioral quirks (e.g., whether it waits for page load, or the format of the snapshot).
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 with the key action. However, it is almost too brief and could be slightly expanded 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 has four optional parameters and no output schema, the description is insufficient. It does not explain what an accessibility snapshot is, how target selection works, or what the return value looks like. The schema descriptions help but overall context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage, so the description does not need to add parameter semantics. It doesn't add any beyond the schema, which is acceptable per 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 the tool captures an accessibility snapshot of the current page. It also distinguishes it from the sibling tool browser_take_screenshot by claiming superiority, making the purpose obvious and differentiated.
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 this tool should be used instead of a screenshot for accessibility data. However, it does not explicitly state when not to use it or list alternatives beyond the single comparison.
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 |
|---|---|---|---|
| action | Yes | Operation to perform | |
| index | No | Tab index, used for close/select. If omitted for close, current tab is closed. | |
| url | No | URL to navigate to in the new tab, used for new. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description's mention of 'close' is consistent but adds no new behavioral context beyond enumerating actions. No 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?
A single concise sentence lists all actions, front-loading the purpose. No extraneous content.
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 covers tab management actions but omits return values (e.g., what 'list' returns) or behavior details (e.g., without output schema). Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter (action, index, url) having descriptions. The description merely summarizes the actions without adding meaning 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 explicitly lists four actions (list, create, close, select) on the browser tab resource. It clearly differentiates from sibling tools like browser_click and browser_navigate by focusing on tab management.
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 the tool is for tab operations, and sibling tool names (e.g., browser_click, browser_navigate) indicate context. No explicit when-not or alternative guidance is provided, but the intent is clear.
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 |
|---|---|---|---|
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| target | No | Exact target element reference from the page snapshot, or a unique element selector | |
| type | Yes | Image format for the screenshot. Default is png. | png |
| filename | No | 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. | |
| fullPage | No | When true, takes a screenshot of the full scrollable page, instead of the currently visible viewport. Cannot be used with element screenshots. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior. The description adds value by noting that screenshots are not actionable, which is a behavioral trait beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no extraneous information. Purpose is front-loaded, and the critical usage distinction is immediately provided.
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 5 parameters (all documented in schema) and no output schema, the description adequately explains the tool's core function. Could mention the return type (e.g., image file path or base64) but missing output schema reduces burden.
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 description does not need to compensate. It does not add meaning beyond what the schema already provides. Baseline score 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 a screenshot of the current page and explicitly differentiates from the sibling tool browser_snapshot by noting that screenshots cannot be used 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?
Provides explicit when-not-to-use guidance with a named alternative (browser_snapshot for actions). Could further clarify typical use cases like capturing visual state for review.
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 |
|---|---|---|---|
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| text | Yes | Text to type into the element | |
| submit | No | Whether to submit entered text (press Enter after) | |
| 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, covering basic safety. The description adds no extra behavioral context (e.g., triggering events, requiring interaction permission), but it doesn't 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 a single short sentence that is front-loaded and contains no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description is too minimal for a browser interaction tool with many siblings. It doesn't explain that typing requires a snapshot reference, nor does it mention the 'submit' or 'slowly' parameters' purposes beyond what's in the schema. Usage context against siblings is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 5 parameters have descriptions in the input schema (100% coverage). The description's single sentence adds no additional meaning beyond what the schema already provides, meeting the baseline for high 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 'Type text into editable element' is highly specific with a clear verb and resource, and it effectively distinguishes this tool from siblings like browser_click or browser_press_key.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like browser_fill_form or browser_press_key, nor does it mention prerequisites (e.g., element must be in focus) 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.
Wait for text to appear or disappear or a specified time to pass
| Name | Required | Description | Default |
|---|---|---|---|
| time | No | The time to wait in seconds | |
| text | No | The text to wait for | |
| textGone | No | The text to wait for to disappear |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; the description adds the specific conditions waited for, but does not detail polling or timeout 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?
A single, front-loaded sentence that efficiently conveys the tool's purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the three conditions adequately, but leaves ambiguity on behavior when multiple parameters are provided simultaneously.
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%, and the description summarizes the parameters' purposes without adding significant new meaning 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 it waits for text to appear, disappear, or a timeout, distinguishing it from sibling tools that perform 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 explicit when-to-use or exclusion guidance, but the context of sibling actions implies it is for waiting relative to other browser tools.
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.73browser_clickbrowser_closebrowser_console_messagesbrowser_dragbrowser_dropbrowser_evaluatebrowser_file_uploadbrowser_fill_formbrowser_handle_dialogbrowser_hoverbrowser_navigatebrowser_navigate_backbrowser_network_requestbrowser_network_requestsbrowser_press_keybrowser_resizebrowser_run_code_unsafebrowser_select_optionbrowser_snapshotbrowser_tabsbrowser_take_screenshotbrowser_typebrowser_wait_forEach tool has a clearly distinct purpose. Overlapping operations like browser_snapshot and browser_take_screenshot are explicitly differentiated in descriptions. No two tools cause ambiguity.
All tools follow a consistent 'browser_verb_noun' pattern (e.g., browser_click, browser_navigate_back, browser_file_upload). The naming is predictable and uniform.
23 tools cover a wide range of browser automation operations without being excessive. The count is appropriate for the domain, though slightly on the higher side.
The tool set covers most essential browser interactions: navigation, clicking, typing, forms, screenshots, dialogs, tabs, network requests, and more. Minor gaps exist (e.g., cookie management, scrolling), but the surface is comprehensive.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
E2LLM gives your AI eyes and hands in a real browser: structured perception (SiFR) plus action.
Screenshot, diff, audit and sitemap-capture any web page — 5 MCP tools for AI agents.
Live browser debugging for AI assistants — DOM, console, network via MCP.
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/Hanato238/playwright-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
