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 Open example.com and tell me the page title and main heading."
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, Grok, 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 add command 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".
Use the Grok CLI to add the Playwright MCP server:
grok mcp add playwright -- npx @playwright/mcp@latestAlternatively, create or edit the configuration file ~/.grok/config.toml and add:
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]For more information, see the Grok MCP documentation.
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", "python", "java", "csharp", "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 |
--mobile | emulate a generic mobile device (Pixel 10 for Chromium, iPhone 17 for WebKit). Mobile pages are usually lighter, which saves tokens. Cannot be combined with --device.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-max-size | Threshold for evicting old output files, in bytes.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-boxes | include each element's bounding box as [box=x,y,width,height] in snapshots. Coordinates are viewport-relative, in CSS pixels.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 |
--timeout-settle | how long to wait after each action for triggered work to settle, in milliseconds, defaults to 500msenv |
--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.
A persistent profile can only be used by one browser instance at a time, so concurrent MCP clients sharing the same workspace will conflict. To run several clients in parallel, start each additional client with--isolated or point it at a distinct --user-data-dir.
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. May be a
* WebSocket URL string, or a [ConnectOptions] object that mirrors the
* `connectOptions` shape used by the test runner. When passed as an object,
* `exposeNetwork`, `headers`, `slowMo`, and `timeout` are forwarded to the
* underlying connect call.
*/
remoteEndpoint?: string | playwright.ConnectOptions & { endpoint: string };
/**
* Paths to TypeScript files to add as initialization scripts for Playwright page.
*/
initPage?: string[];
/**
* Paths to JavaScript files to add as initialization scripts.
* The scripts will be evaluated in every page before any of the page's scripts.
*/
initScript?: string[];
},
/**
* Connect to a running browser instance (Edge/Chrome only). If specified, `browser`
* config is ignored.
* Requires the "Playwright Extension" to be installed.
*/
extension?: boolean;
server?: {
/**
* The port to listen on for SSE or MCP transport.
*/
port?: number;
/**
* The host to bind the server to. Default is localhost. Use 0.0.0.0 to bind to all interfaces.
*/
host?: string;
/**
* The hosts this server is allowed to serve from. Defaults to the host server is bound to.
* This is not for CORS, but rather for the DNS rebinding protection.
*/
allowedHosts?: string[];
},
/**
* List of enabled tool capabilities. Possible values:
* - 'core': Core browser automation features.
* - 'pdf': PDF generation and manipulation.
* - 'vision': Coordinate-based interactions.
* - 'devtools': Developer tools features.
*/
capabilities?: ToolCapability[];
/**
* Whether to save the Playwright session into the output directory.
*/
saveSession?: boolean;
/**
* Reuse the same browser context between all connected HTTP clients.
*/
sharedBrowserContext?: boolean;
/**
* Secrets are used to replace matching plain text in the tool responses to prevent the LLM
* from accidentally getting sensitive data. It is a convenience and not a security feature,
* make sure to always examine information coming in and from the tool on the client.
*/
secrets?: Record<string, string>;
/**
* The directory to save output files.
*/
outputDir?: string;
/**
* Threshold for evicting old output files, in bytes.
*/
outputMaxSize?: number;
console?: {
/**
* The level of console messages to return. Each level includes the messages of more severe levels. Defaults to "info".
*/
level?: 'error' | 'warning' | 'info' | 'debug';
},
network?: {
/**
* List of origins to allow the browser to request. Default is to allow all. Origins matching both `allowedOrigins` and `blockedOrigins` will be blocked.
*
* Supported formats:
* - Full origin: `https://example.com:8080` - matches only that origin
* - Wildcard port: `http://localhost:*` - matches any port on localhost with http protocol
*/
allowedOrigins?: string[];
/**
* List of origins to block the browser to request. Origins matching both `allowedOrigins` and `blockedOrigins` will be blocked.
*
* Supported formats:
* - Full origin: `https://example.com:8080` - matches only that origin
* - Wildcard port: `http://localhost:*` - matches any port on localhost with http protocol
*/
blockedOrigins?: string[];
};
/**
* Specify the attribute to use for test ids, defaults to "data-testid".
*/
testIdAttribute?: string;
timeouts?: {
/*
* Configures default action timeout: https://playwright.dev/docs/api/class-page#page-set-default-timeout. Defaults to 5000ms.
*/
action?: number;
/*
* Configures default navigation timeout: https://playwright.dev/docs/api/class-page#page-set-default-navigation-timeout. Defaults to 60000ms.
*/
navigation?: number;
/**
* Configures default expect timeout: https://playwright.dev/docs/test-timeouts#expect-timeout. Defaults to 5000ms.
*/
expect?: number;
/**
* How long to wait after each action for triggered work (navigations, requests) to settle before responding. Defaults to 500ms.
*/
settle?: number;
};
/**
* Whether to send image responses to the client. Can be "allow", "omit", or "auto". Defaults to "auto", which sends images if the client can display them.
*/
imageResponses?: 'allow' | 'omit';
snapshot?: {
/**
* When taking snapshots for responses, specifies the mode to use.
*/
mode?: 'full' | 'none';
/**
* Whether to include each element's bounding box as [box=x,y,width,height] in snapshots.
* Coordinates are viewport-relative, in CSS pixels (Element.getBoundingClientRect).
*/
boxes?: boolean;
};
/**
* allowUnrestrictedFileAccess acts as a guardrail to prevent the LLM from accidentally
* wandering outside its intended workspace. It is a convenience defense to catch unintended
* file access, not a secure boundary; a deliberate attempt to reach other directories can be
* easily worked around, so always rely on client-level permissions for true security.
*/
allowUnrestrictedFileAccess?: boolean;
/**
* Specify the language to use for code generation.
*/
codegen?: 'typescript' | 'python' | 'java' | 'csharp' | 'none';
}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 \
/app/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_find
Title: Find in page snapshot
Description: Search the accessibility snapshot of the current page for text or a regular expression. Returns matching snapshot nodes with a few lines of surrounding context (like search snippets), each shown under its path from the root of the tree, which is cheaper than capturing the whole snapshot when you only need to locate an element and its ref.
Parameters:
text (string, optional): Plain text to search for in the page snapshot (case-insensitive substring match). Provide either text or regex, not both.
regex (string, optional): Regular expression to search for in the page snapshot. Matching is case-sensitive by default; wrap the pattern in slashes to add flags, e.g. "/error/i" for case-insensitive. Provide either text or regex, not both.
Read-only: true
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. Coordinates are viewport-relative, in CSS pixels (Element.getBoundingClientRect)
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, optional): Image format for the screenshot. If unset, inferred from the filename extension, otherwise png.
filename (string, optional): File name to save the screenshot to. Defaults to page-{timestamp}.{png|jpeg|webp} if not specified. Prefer relative file names to stay within the output directory.
fullPage (boolean, optional): When true, takes a screenshot of the full scrollable page, instead of the currently visible viewport. Cannot be used with element screenshots.
scale (string): Image resolution scale. "css" produces a screenshot sized in CSS pixels (smaller, consistent across devices). "device" produces a high-resolution screenshot using device pixels (larger, accounts for the device pixel ratio). Default is css.
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_recording
Title: Start recording user actions
Description: Start recording actions that the user performs in the browser as Playwright code. Use it when the user wants to demonstrate a flow manually. Call browser_stop_recording when the user says they are done to retrieve the recorded actions.
Parameters: None
Read-only: true
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_recording
Title: Stop recording user actions
Description: Stop the recording started with browser_start_recording and return the recorded actions as Playwright code.
Parameters: None
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_video_hide_actions
Title: Hide action overlays
Description: Stop annotating actions performed on the page.
Parameters: None
Read-only: true
browser_video_show_actions
Title: Show action overlays
Description: Annotate subsequent actions performed on the page with a callout that names the action and highlights the target element. Useful while video recording or screencasting.
Parameters:
duration (number, optional): How long each action annotation stays on screen, in milliseconds. Defaults to 500.
position (string, optional): Where to place the action title relative to the page. Defaults to top-right.
cursor (string, optional): Cursor decoration for pointer actions. "pointer" (default) animates a mouse pointer from the previous action point to the next one; "none" disables the cursor decoration.
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 |
|---|---|---|---|
| button | No | Button to click, defaults to left | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| modifiers | No | Modifier keys to press | |
| doubleClick | No | Whether to perform a double click instead of a single click |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate that this is not read-only and is potentially destructive, so the description does not need to restate that. However, the description adds no additional behavioral context, such as whether clicks can trigger navigation, form submission, or page state changes beyond what the annotations already convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loaded, with no wasted words. It loses a point because it is so minimal that it provides little beyond the tool name and annotations.
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 five-parameter schema, no output schema, and many sibling browser tools, the description is too thin. It does not explain when to click, what side effects may occur, or how this differs from hover, press_key, or other interaction 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 all five parameters. The description itself adds no extra meaning to the parameters, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Perform click') and the resource ('web page'), so an agent knows what the tool does. It does not explicitly distinguish it from sibling tools like browser_hover or browser_press_key, but the basic purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, such as browser_hover, browser_type, or browser_press_key. The description does not mention any prerequisites, exclusions, or a preferred context for clicking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the page
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true and readOnlyHint=false, so the description adds no additional behavioral context. It does not mention irreversible effects, session implications, or what happens to the page content. Since the annotation carries the safety profile, the description contributes nothing beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two words—'Close the page'—which is maximally concise and front-loaded. There is no wasted text, and it immediately conveys the core action.
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 destructive operation with no parameters and no output schema, the description is mostly adequate. However, it does not clarify whether 'page' means the current tab or the entire browser, and it omits any mention of side effects like unsaved changes being lost. Given the annotation title says 'Close browser,' there is slight ambiguity, but the description is not severely deficient.
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 description coverage is 100% (vacuously). With no parameters to explain, the baseline for this dimension is 4, and the description correctly omits any parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Close the page' clearly identifies the action (close) and resource (page), distinguishing it from the sibling tools like navigate, click, or hover. It is specific enough to convey the operation, though it doesn't explicitly differentiate from a hypothetical 'close browser' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor are any exclusions or prerequisites mentioned. The description merely states what it does without any contextual instruction for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all console messages
| Name | Required | Description | Default |
|---|---|---|---|
| all | No | Return all console messages since the beginning of the session, not just since the last navigation. Defaults to false. | |
| level | Yes | Level of the console messages to return. Each level includes the messages of more severe levels. Defaults to "info". | info |
| filename | No | Filename to save the console messages to. If not provided, messages are returned as text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the operation is read-only and non-destructive. The description adds almost no behavioral context beyond the generic 'Returns all console messages' and fails to disclose key traits such as level inheritance, the 'all' flag only affecting navigation boundaries, and the filename parameter changing the output behavior. This is a meaningful gap for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It is concise, though almost too terse to be useful, omitting qualifications that would help the agent understand the tool's actual scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should clarify return types and behavioral nuances. It does not mention the effect of the filename parameter, the 'level' hierarchy, or the difference between session-wide and navigation-scoped messages, leaving important operational details undocumented.
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 all three parameters. The description contributes no additional parameter meaning, which matches the baseline expectation when the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as returning console messages, with a specific verb ('Returns') and resource ('console messages'). However, it does not differentiate the tool from siblings like browser_network_requests, and the word 'all' is somewhat misleading given the default level and all-flag behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios, exclusions, or references to sibling tools, leaving the agent to infer appropriate usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform drag and drop between two elements
| Name | Required | Description | Default |
|---|---|---|---|
| endTarget | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| endElement | No | Human-readable target element description used to obtain the permission to interact with the element | |
| startTarget | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| startElement | No | Human-readable source element description used to obtain the permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal that the tool is destructive (destructiveHint=true) and not read-only, so the safety profile is covered. The description adds that this is a two-element gesture, but it stops short of explaining what happens on drop or what side effects to expect.
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, direct sentence states the action and the objects involved with no wasted words. The key information is 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?
For a small tool with full schema coverage and annotations, the description is functional. It lacks any note on permissions, visibility requirements, or expected behavior after the drop, but the structured data covers most invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with meaningful descriptions (startTarget/endTarget, startElement/endElement). The description adds only the 'between two elements' relationship, which is helpful but not necessary given schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Perform drag and drop') and names the resources ('between two elements'), making the core action clear. It does not explicitly distinguish browser_drag from the similarly named sibling browser_drop, so it is clear but not 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?
No guidance is given on when to choose this tool rather than siblings like browser_click, browser_hover, or especially browser_drop. There are no stated prerequisites, caveats, or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drop files or MIME-typed data onto an element, as if dragged from outside the page. At least one of "paths" or "data" must be provided.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Data to drop, as a map of MIME type to string value (e.g. {"text/plain": "hello", "text/uri-list": "https://example.com"}). | |
| paths | No | Absolute paths to files to drop onto the element. | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive=true, readOnly=false, and openWorld=true. The description adds useful context beyond annotations by clarifying that the drop is simulated 'as if from outside the page' and that paths/data are mutually required. It does not disclose permission requirements or the side effects of a drop, but the destructive annotation already flags risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action first, then the required constraint. Every phrase earns its place; there is no wasted wording or unnecessary repetition of schema details.
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?
Combined with a fully documented schema and safety-relevant annotations, the description is sufficient for a basic call. However, it lacks guidance on when to prefer paths over data, what happens if both are supplied, or how target/element interact. It is adequate but could be more complete for a browser-interaction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents all parameters well. The description adds value by stating the non-obvious constraint that 'at least one' of paths or data must be provided, which the schema itself does not enforce since only target is required. It also implicitly maps paths and data to the two input modes mentioned.
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 names a specific action ('Drop'), a resource ('onto an element'), and the two supported input forms ('files or MIME-typed data'). The phrase 'as if dragged from outside the page' clearly distinguishes this from browser_drag (internal drag) and browser_file_upload. The at-least-one constraint further sharpens the tool's purpose.
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 use case — simulating an external drag-and-drop — which helps an agent choose this over browser_drag. However, it does not explicitly mention when not to use it, nor does it name sibling alternatives like browser_file_upload or browser_drag. The usage guidance is adequate but left mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate JavaScript expression on page or element
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| filename | No | Filename to save the result to. If not provided, result is returned as text. | |
| function | Yes | () => { /* code */ } or (element) => { /* code */ } when element is provided |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already communicate destructiveHint=true and readOnlyHint=false, which cover the safety profile. The description adds that evaluation can target a page or element, but it does not disclose side effects, execution context, or whether arbitrary code can mutate page state. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler or repetition. Every word contributes to identifying the operation, making it highly concise and easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema covers parameters and the annotations cover destructiveness, so the core invocation is viable. However, there is no output schema, and the description does not explain return shapes, error behavior, execution context, or how this differs from running unsafe code. It is adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description only loosely maps to function, target, and element without adding meaning beyond the schema. This matches the baseline for fully covered schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Evaluate JavaScript expression on page or element'. It clearly states what the tool does. However, it does not explicitly distinguish itself from the sibling browser_run_code_unsafe, which also appears to execute JavaScript, so it does not earn a 5.
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 about when to use this tool versus browser_run_code_unsafe or any other sibling. It does not mention situations where element targeting is required, nor when the filename parameter should be used instead of returned text. There is no when-to-use or when-not-to-use information.
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 a non-read-only, destructive operation, but the description adds no behavioral context beyond the word 'upload'. It does not state side effects, how the file chooser is handled, or what happens after upload.
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 one short sentence with no filler. It is efficient, though very sparse; the minimalism is more of a completeness issue than a conciseness issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no mention of return values, prerequisites, or suitable call contexts. With no output schema and only a terse description, an agent gets the basic action but not enough to confidently invoke it alongside 23 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%, and the paths parameter explains absolute paths, single/multiple files, and cancellation behavior. The description only paraphrases the schema without adding new meaning, 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 uses a specific verb ('Upload') and resource ('files'), and clarifies single-or-multiple. It is immediately understandable and distinct from most browser siblings, though it does not explain what receiving context is used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool over alternatives such as browser_drop, or whether it should be called while a file chooser is open. The schema hint about cancellation is useful but does not appear in the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill multiple form fields
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | Fields to fill in |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate readOnlyHint=false and destructiveHint=true, so the mutation/destructive profile is covered. The description does not add behavioral context such as whether the form is submitted, which side effects occur, or why the action may be destructive, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single,front-loaded sentence with no filler or repetition. It communicates the essential action in the fewest possible 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 rich input schema and annotations provide a minimally usable picture of how to invoke the tool. However, with no output schema and no guidance on when to prefer this over sibling tools, the description alone is not fully complete for correct tool selection.
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 each parameter already has explicit documentation in the input schema. The description adds no parameter-level meaning beyond indicating that multiple form fields can be filled at once.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fill multiple form fields' uses a specific verb and resource, making the core action clear. The word 'multiple' hints at batch behavior and loosely distinguishes it from single-field tools like browser_type or browser_select_option, but it does not explicitly name those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as browser_type, browser_select_option, or browser_click. The 'multiple' qualifier implies a batch or form-filling scenario, but this is not stated explicitly enough to help an agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the accessibility snapshot of the current page for text or a regular expression. Returns matching snapshot nodes with a few lines of surrounding context (like search snippets), each shown under its path from the root of the tree, which is cheaper than capturing the whole snapshot when you only need to locate an element and its ref.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Plain text to search for in the page snapshot (case-insensitive substring match). Provide either text or regex, not both. | |
| regex | No | Regular expression to search for in the page snapshot. Matching is case-sensitive by default; wrap the pattern in slashes to add flags, e.g. "/error/i" for case-insensitive. Provide either text or regex, not both. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive behavior. The description adds useful behavioral detail about return format, surrounding context, path-from-root presentation, and cost characteristics. It is consistent with the annotations, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense, well-structured sentence that front-loads the action and then provides the output shape and the key trade-off. There is no filler or redundancy; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains return shape and the main use case, and annotations cover safety. However, since neither parameter is marked required in the schema, the description could more explicitly instruct the agent to provide exactly one of text or regex.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; both text and regex are already documented with mutual exclusivity and regex flag syntax. The description adds no parameter-level meaning beyond restating that either text or regex is used, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search'), a clear resource ('the accessibility snapshot of the current page'), and a well-defined result (matching snapshot nodes with surrounding context and refs). It also distinguishes itself from the whole-snapshot sibling by explaining its narrower focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear when-to-use condition: this is 'cheaper than capturing the whole snapshot when you only need to locate an element and its ref.' It implicitly contrasts with browser_snapshot but does not explicitly name the sibling or state when NOT to use this tool, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Handle a dialog
| Name | Required | Description | Default |
|---|---|---|---|
| accept | Yes | Whether to accept the dialog. | |
| promptText | No | The text of the prompt in case of a prompt dialog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and non-read-only behavior, but the description adds no useful behavioral context. It does not explain side effects of accepting, behavior for dismissed dialogs, or how promptText is used for prompt dialogs.
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 short but under-specified rather than efficiently informative. It simply restates the tool name and does not use its space to convey any additional operational meaning.
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 destructive browser action with no output schema, the description is too minimal to support correct invocation. It omits when dialog handling is needed, how promptText should be used, and what effects accepting or not accepting has.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters with 100% coverage, so the baseline applies. The description itself adds no parameter detail, but the schema already explains accept and promptText adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Handle a dialog' exactly restates the tool name/title and uses the generic verb 'handle' without explaining what handling entails. It does not clarify whether the tool accepts, dismisses, or fills in dialog text, nor does it distinguish it from other browser tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, such as when a native browser dialog appears, nor any mention of alternatives or exclusions. The description provides no practical selection context beyond what the tool name implies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hover over element on page
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false and destructiveHint=true, while the description adds no behavioral context beyond the basic action. It does not mention side effects of hovering, such as UI state changes or permission implications, but it also does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence with no filler words. It is appropriately small for a simple tool, though it borders on under-specification rather than achieving strong structural efficiency.
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 straightforward hover action, the schema and annotations cover the target parameter and safety profile. The description is missing usage guidance and behavioral effects, but the overall context is sufficient for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The description does not add extra meaning to `target` or `element`, but the schema already explains both parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb and resource ('Hover over element on page') that accurately conveys the action. It does not explicitly differentiate from sibling tools like browser_click or browser_drop, but the semantic is distinct enough for an agent to understand the intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, no exclusions, and no mention of hover-specific scenarios such as revealing tooltips or opening menus. The agent must infer usage solely from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns full details (headers and body) of a single network request, or a single part if part is set. Use the number from browser_network_requests.
| Name | Required | Description | Default |
|---|---|---|---|
| part | No | Return only this part of the request. Omit to return full details. | |
| index | Yes | 1-based index of the request, as printed by browser_network_requests. | |
| filename | No | Filename to save the result to. If not provided, output is returned as text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns headers and body and can be narrowed to one part, which is useful but not particularly deep. No contradiction or hidden destructive behavior is disclosed or left ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences carry all essential information: what is returned, how to narrow it, and where the index comes from. There is no filler, and the most important behavioral constraint is 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?
For a read-only retrieval tool, the description plus schema is largely sufficient: the user knows what to pass, where the index originates, and what kind of data to expect. The absence of an output schema is mitigated by the explicit mention of headers and body, though exact response structure is not specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains `index`, `part`, and `filename`. The description adds meaningful context by saying the index is the number from browser_network_requests and that `part` changes the result, but it does not substantially expand on 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 states a specific verb ('Returns'), a specific resource ('full details of a single network request'), and the optional scoping to a part. It is clearly distinguished from the sibling browser_network_requests, which lists requests, by saying 'Use the number from browser_network_requests.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context: the index comes from browser_network_requests, and `part` narrows the return to a single section. It does not explicitly enumerate when not to use this tool versus alternatives, but the reference to the sibling tool makes the intended workflow clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a numbered list of network requests since loading the page. Use browser_network_request with the number to get full details.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Only return requests whose URL matches this regexp (e.g. "/api/.*user"). | |
| static | Yes | Whether to include successful static resources like images, fonts, scripts, etc. Defaults to false. | |
| filename | No | Filename to save the network requests to. If not provided, requests are returned as text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false, so safety is covered without repetition. The description adds valuable behavioral context: the results are numbered, scoped to page load, and intended to be consumed by browser_network_request. Missing pagination or snapshot semantics is a minor gap given the tool's simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The first sentence front-loads the core action and temporal scope; the second sentence gives the essential follow-up instruction. 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?
For a list/detail tool with no output schema, the description sufficiently explains return shape (numbered list), scope (since page load), and the next step (pass a number to browser_network_request). The schema covers parameter details. It is complete enough, though exact text/format of the list is left implicit.
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 schema already documents filter, static, and filename. The description adds little direct parameter meaning, though the numbered-list phrasing explains how results connect to the sibling detail tool. Per baseline, this is adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Returns a numbered list of network requests since loading the page.' It also clearly differentiates itself from the sibling browser_network_request by pointing to it as the detail-fetching counterpart. An agent can immediately tell the list operation from the detail operation.
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 routes the agent to browser_network_request when full details are needed, which is the key alternative for this list/detail pair. It does not enumerate when-not-to-use conditions against unrelated browser tools, but the usage context is clear enough for correct selection.
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?
With destructiveHint=true and readOnlyHint=false, the annotations already indicate this action can mutate state. The description adds no behavioral context beyond the hint, such as possible effects like triggering shortcuts, navigation, or needing an active element.
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 filler, repetition, or unnecessary detail. It is appropriately sized for such a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with complete schema documentation and safety annotations, the description is minimally viable. However, it does not explain when to use this tool, what happens after pressing a key, or how it relates to siblings like browser_type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the only parameter (key) with a clear description and examples like ArrowLeft or a. Since schema coverage is 100%, the description does not need to add parameter meaning, and it does not provide extra detail 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 states a specific verb and resource: 'Press a key on the keyboard.' It clearly identifies the tool's function, though it does not explicitly differentiate it from siblings like browser_type or browser_click.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention cases where browser_type would be more appropriate, nor does it describe context such as focus requirements or typical use.
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 signal that this is a mutating operation (destructiveHint=true, readOnlyHint=false). The description adds no behavioral context beyond that, such as how resizing affects the viewport, whether values are in pixels, or how it affects subsequent browser interactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and easy to parse, though it earns its place mainly by restating the tool's name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that changes browser state and has no output schema, the description is too thin. It omits operational context such as whether this resizes the viewport or the outer window, any dimension limits, and how the resize affects subsequent browser actions. The schema covers parameters, but not the overall context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both width and height with 100% coverage, so the baseline of 3 applies. The description adds no extra meaning about units, constraints, or how width and height relate to each other.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and target ('Resize the browser window'), and the resizing action is unique among the sibling tools, so an agent can distinguish it from navigation, clicking, and tab management. However, it largely restates the tool name and gives no detail about the scope or effect of resizing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use browser_resize versus alternatives, when not to use it, or how it relates to other browser-control tools. The description leaves all usage decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Playwright code snippet. Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | A JavaScript function containing Playwright code to execute. It will be invoked with a single argument, page, which you can use for any page interaction. For example: `async (page) => { await page.getByRole('button', { name: 'Submit' }).click(); return await page.title(); }` | |
| filename | No | Load code from the specified file. If both code and filename are provided, code will be ignored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as destructive and not read-only. The description adds crucial context beyond the annotations by specifying that code executes in the Playwright server process and is RCE-equivalent. This clarifies the severity and location of execution, which is highly valuable.
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, information-dense sentence that leads with the action and resource, then delivers the critical safety warning. Every word earns its place, with no redundant or filler 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?
For a tool with only two parameters, rich annotations, and a 100% covered schema, the description covers the most important operational context: server-side execution, arbitrary JavaScript, and RCE risk. The lack of an explicit return-value description is minor given the code-driven return and absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'code' and 'filename' thoroughly documented, including an example for 'code'. The tool description provides no additional parameter-level detail, so the schema carries the full burden and 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 tool "Run[s] a Playwright code snippet" and identifies the dangerous nature: it "executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent." This distinguishes it from page-context tools like browser_evaluate, though it does not explicitly name a sibling.
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 strongly communicates that the tool is unsafe and RCE-equivalent, implying it should only be used when necessary. However, it does not explicitly say when to prefer this tool over alternatives such as browser_evaluate, nor does it state any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select an option in a dropdown
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| values | Yes | Array of values to select in the dropdown. This can be a single value or multiple values. | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description does not need to repeat that selecting an option mutates state. It adds no additional behavioral context beyond the action itself—it does not mention side effects like triggering change events or altering form state, nor any permission requirements. Since annotations cover the safety profile, the minimal description is acceptable but not enriching.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no wasted words. It efficiently captures the core action. It is front-loaded with the action verb. However, it is so brief that it omits potentially useful context like the fact that it handles single and multiple selections (which is already in the schema) or any notes about dropdown behavior, but for pure conciseness it scores high.
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 schema covers all parameters and annotations indicate destructiveness, the description is minimally complete. However, it lacks contextual guidance on when to use this tool (e.g., after taking a snapshot to get the target reference), any prerequisites, or post-conditions. For a destructive action, an agent might need more info about what changes occur, but the existing structured data provides the safety flags, so this is acceptable but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (target, values, element) are fully described in the input schema with clear meanings (target reference, array of values, permission description). The tool description adds no additional semantic detail beyond what the schema provides, so it meets the baseline but does not enhance understanding of parameter relationships or usage nuances.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action: 'Select an option in a dropdown' with a clear verb and resource. It is unambiguous about the tool's function and distinguishes it from sibling browser interaction tools (click, type, hover) that operate on different UI elements. However, it does not explicitly differentiate from other selection-like tools, but given the sibling list, no other tool handles dropdowns specifically, so it is clear enough.
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, nor does it mention any prerequisites or exclusions. There is no indication of when a dropdown might require this tool instead of other interaction methods (e.g., clicking the dropdown and typing). An agent would have no context to decide between this and browser_click or browser_type in some scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture accessibility snapshot of the current page, this is better than screenshot
| Name | Required | Description | Default |
|---|---|---|---|
| boxes | No | Include each element's bounding box as [box=x,y,width,height] in the snapshot. Coordinates are viewport-relative, in CSS pixels (Element.getBoundingClientRect) | |
| depth | No | Limit the depth of the snapshot tree | |
| target | No | Exact target element reference from the page snapshot, or a unique element selector | |
| filename | No | Save snapshot to markdown file instead of returning it in the response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, which are consistent with the description's 'Capture accessibility snapshot' (a read operation). The description does not contradict annotations and adds a small behavioral note that it is 'better than screenshot' (implying richer content than a visual). However, it does not disclose details like output format, performance implications, or the fact that it captures the whole page. With annotations covering the safety profile, the description adds limited extra behavioral 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?
The description is a single, efficient sentence that immediately states the tool's purpose and the key advantage over a screenshot. There is no redundant or fluff content, and the essential information is 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?
For a tool with optional parameters and no output schema, the description is relatively minimal. It does not explain the structure of the returned accessibility snapshot or when to use it in a workflow. However, the parameter schemas are thorough, and the annotations cover safety. Given the tool's simplicity, it is adequate but lacks detail about the output format and usage scenarios, leaving room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are fully documented in the input schema. The tool description itself adds no additional parameter semantics. As a result, the baseline of 3 applies because the schema handles parameter understanding entirely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Capture') and resource ('accessibility snapshot of the current page'), and adds a comparative hint ('better than screenshot') that distinguishes it from the sibling browser_take_screenshot. It does not explicitly differentiate from other siblings but is clear and specific enough to convey its core function.
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 phrase 'this is better than screenshot' implicitly suggests using it when an accessibility snapshot is preferred over a visual screenshot. However, it gives no explicit guidance on when NOT to use it or which alternative to choose otherwise. There are many sibling tools, but no reference to them, so usage context is only partially addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List, create, close, or select a browser tab.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to in the new tab, used for new. | |
| index | No | Tab index, used for close/select. If omitted for close, current tab is closed. | |
| action | Yes | Operation to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint=false, openWorldHint=true, and destructiveHint=true. The description's mention of 'close' aligns with the destructive hint, but it adds no extra behavioral context such as side effects of selecting a tab or irreversibility of close. No contradiction exists, so a baseline 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence that front-loads the key operations. Every word contributes meaning, and there is no filler or redundant restatement of the annotations or title.
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 3-parameter tool with full schema coverage, the description captures all supported operations and the schema fills in parameter specifics. It does not describe what 'list' returns and gives no guidance on when to use this tool, but the core invocation information is present.
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 schema already documents url, index, and the action enum with clear meanings. The tool description does not add parameter details, so it earns the baseline 3 for relying on 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 lists four concrete operations ('List, create, close, or select') applied to a clear resource ('browser tab'), so an agent can tell the tool manages tabs. It does not explicitly distinguish itself from sibling tools like browser_navigate or browser_close, so it misses the top score for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use browser_tabs versus sibling tools such as browser_navigate, browser_close, or browser_find. The action enum implies some usage, but the description itself provides no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of the current page. You can't perform actions based on the screenshot, use browser_snapshot for actions.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Image format for the screenshot. If unset, inferred from the filename extension, otherwise png. | |
| scale | Yes | Image resolution scale. "css" produces a screenshot sized in CSS pixels (smaller, consistent across devices). "device" produces a high-resolution screenshot using device pixels (larger, accounts for the device pixel ratio). Default is css. | css |
| target | No | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| filename | No | File name to save the screenshot to. Defaults to `page-{timestamp}.{png|jpeg|webp}` if not specified. Prefer relative file names to stay within the output directory. | |
| fullPage | No | When true, takes a screenshot of the full scrollable page, instead of the currently visible viewport. Cannot be used with element screenshots. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds a key behavioral trait: the output is not interactive ('You can't perform actions based on the screenshot'), which is not captured by annotations. This adds meaningful context about the tool's limitations beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant phrasing. The core purpose is stated first, followed by a critical limitation and alternative, maximizing informativeness per word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only screenshot tool with comprehensive schema documentation and safety annotations, the description covers the essential decision points: when to use it and when not to. It doesn't explain return formats or error handling, but those are less critical given the tool's simplicity and the annotations' coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for all 6 parameters. The description adds no parameter-specific information, and the baseline of 3 is appropriate since the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Take') and resource ('screenshot of the current page'). Explicitly distinguishes from browser_snapshot by stating what it is not for ('You can't perform actions based on the screenshot'), making it clear which tool to use for captures vs. interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-not-to-use guidance: 'You can't perform actions based on the screenshot' and directs to the alternative 'use browser_snapshot for actions'. This clearly routes an agent to the correct tool for interactive needs while implying this tool is for visual captures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into editable element
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to type into the element | |
| slowly | No | Whether to type one character at a time. Useful for triggering key handlers in the page. By default entire text is filled in at once. | |
| submit | No | Whether to submit entered text (press Enter after) | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry destructiveHint=true and readOnlyHint=false, signaling a mutating operation. The description adds only the 'editable element' scope and does not disclose behavioral traits such as replacing existing text, triggering input events, or requiring permission through the 'element' parameter.
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, front-loaded sentence with no filler or repetition. It is economical, though the brevity comes at the cost of behavioral detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Full schema coverage and annotations provide enough structured information for a basic call, and no output schema exists to explain. Still, for a destructive 5-parameter mutation tool, the description could usefully mention that typing may replace content or trigger key handlers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all five parameters are already documented with their individual purposes. The description itself introduces no additional parameter-level nuance, so it correctly sits at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete action ('Type text') and a resource ('editable element'), making the tool's function immediately understandable. It doesn't explicitly differentiate it from siblings like browser_fill_form or browser_press_key, but the verb+target phrasing is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'editable element' implies the tool is intended for text entry into input fields or contenteditable regions rather than general keyboard shortcuts. However, it doesn't provide explicit when-to-use guidance, exclusions, or comparisons with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for text to appear or disappear or a specified time to pass
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | The text to wait for | |
| time | No | The time to wait in seconds | |
| textGone | No | The text to wait for to disappear |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the three operating modes, which is useful, but it does not disclose important behavior such as polling, timeout limits, or what happens if a condition is already satisfied when the call starts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence with no filler, and the primary action ('wait for') is front-loaded. Every part of the sentence contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and the annotations cover safety, but the description leaves ambiguity about combinations of text, textGone, and time, and about what happens when none of the conditions are met. Since there are no required parameters, an agent needs more guidance on expected input combinations.
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 schema already documents each parameter. The description paraphrases the same meanings rather than adding new semantics, and it does not clarify whether parameters can be combined or are mutually exclusive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('wait') and names concrete resources: text appearing, text disappearing, and elapsed time. It clearly differentiates this tool from the other browser action siblings just by stating these three focus areas.
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 tells an agent when to use the tool: when you need to block until text appears, until text disappears, or until a duration has passed. It does not explicitly mention alternative tools, but no sibling tool fills the same waiting role, so the omission is minor.
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.80browser_clickbrowser_closebrowser_console_messagesbrowser_dragbrowser_dropbrowser_evaluatebrowser_file_uploadbrowser_fill_formbrowser_findbrowser_handle_dialogbrowser_hoverbrowser_navigatebrowser_navigate_backbrowser_network_requestbrowser_network_requestsbrowser_press_keybrowser_resizebrowser_run_code_unsafebrowser_select_optionbrowser_snapshotbrowser_tabsbrowser_take_screenshotbrowser_typebrowser_wait_forMost tools map cleanly to distinct browser actions (click, hover, drag, select, navigate, resize). The few close boundaries—browser_type vs browser_fill_form, or browser_evaluate vs browser_run_code_unsafe—are clarified by their descriptions.
All tool names use a consistent browser_ prefix and snake_case convention. Most follow a verb_noun pattern, though a few like browser_tabs, browser_snapshot, and browser_network_requests are noun-style state queries rather than actions.
At 24 tools, the set sits at the heavy end of the typical range for an MCP server. The tools are mostly non-redundant and serve a broad browser automation purpose, but the count is large enough to feel somewhat unwieldy.
The set covers the major browser automation operations well: navigation, clicking, typing, form filling, screenshots, snapshots, tabs, dialogs, network inspection, file upload, and drag-and-drop. Minor gaps like forward navigation, reload, and cookie/localStorage management can be worked around with browser_evaluate.
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.
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
Turn any webpage into a structured action manifest — clickable, fillable, submittable elements.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nludd25/playwright-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
