一个使用 Playwright 提供浏览器自动化能力的模型上下文协议（MCP）服务器。该服务器通过结构化可访问性快照使 LLM 能够与网页交互，无需使用截图或视觉调优模型。
本包为 Playwright 提供了 MCP 接口。如果你使用的是编码代理，可能会更倾向于使用 CLI+SKILLS。
CLI：现代编码代理越来越倾向于使用以 SKILL 形式暴露的 CLI 工作流，而非 MCP，因为 CLI 调用在 token 效率上更优：它们避免了将庞大的工具架构和冗长的可访问性树加载到模型上下文中，使代理能够通过简洁、目标明确的命令执行操作。这使得 CLI + SKILLS 更适合高吞吐量的编码代理，这些代理需要在有限的上下文窗口内平衡浏览器自动化与大型代码库、测试和推理。了解更多关于 Playwright CLI with SKILLS。
MCP：MCP 仍然适用于那些受益于持久状态、丰富内省和基于页面结构进行迭代推理的专业代理循环，例如探索性自动化、自我修复测试或长期运行的自主工作流——在这些场景中，维持连续浏览器上下文的重要性超过了 token 成本问题。
快速且轻量。使用 Playwright 的可访问性树，而非基于像素的输入。
对 LLM 友好。无需视觉模型，完全基于结构化数据运行。
确定性工具应用。避免了基于截图方法常见的歧义问题。
Node.js 18 或更新版本
VS Code、Cursor、Windsurf、Claude Desktop、Goose、Grok、Junie 或任何其他 MCP 客户端
首先，在你的客户端中安装 Playwright MCP 服务器。
标准配置适用于大多数工具：
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}
通过 Amp VS Code 扩展设置界面或更新 settings.json 文件添加：
"amp.mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}Amp CLI 设置：
通过以下 amp mcp add 命令添加
amp mcp add playwright -- npx @playwright/mcp@latest通过 Antigravity 设置或更新配置文件添加：
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}使用 Claude Code CLI 添加 Playwright MCP 服务器：
claude mcp add playwright npx @playwright/mcp@latest按照 MCP 安装指南操作，使用上述标准配置。
按照配置 MCP 服务器章节的说明操作。
示例：本地设置
将以下内容添加到你的 cline_mcp_settings.json 文件中：
{
"mcpServers": {
"playwright": {
"type": "stdio",
"command": "npx",
"timeout": 30,
"args": [
"-y",
"@playwright/mcp@latest"
],
"disabled": false
}
}
}使用 Codex CLI 添加 Playwright MCP 服务器：
codex mcp add playwright npx "@playwright/mcp@latest"或者，创建或编辑配置文件 ~/.codex/config.toml 并添加：
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]更多信息，请参阅 Codex MCP 文档。
使用 Copilot CLI 交互式添加 Playwright MCP 服务器：
/mcp add或者，创建或编辑配置文件 ~/.copilot/mcp-config.json 并添加：
{
"mcpServers": {
"playwright": {
"type": "local",
"command": "npx",
"tools": [
"*"
],
"args": [
"@playwright/mcp@latest"
]
}
}
}更多信息，请参阅 Copilot CLI 文档。
进入 Cursor 设置 -> MCP -> 添加新 MCP 服务器。名称可自定义，类型选择 command，命令为 npx @playwright/mcp@latest。你也可以通过点击 编辑 来验证配置或添加类似参数。
使用 Factory CLI 添加 Playwright MCP 服务器：
droid mcp add playwright "npx @playwright/mcp@latest"或者，在 Factory 机器人中输入 /mcp 打开管理 MCP 服务器的交互式界面。
更多信息，请参阅 Factory MCP 文档。
按照 MCP 安装指南操作，使用上述标准配置。
进入 高级设置 -> 扩展 -> 添加自定义扩展。名称可自定义，类型选择 STDIO，并将 命令 设置为 npx @playwright/mcp。点击 "添加扩展"。
使用 Grok CLI 添加 Playwright MCP 服务器：
grok mcp add playwright -- npx @playwright/mcp@latest或者，创建或编辑配置文件 ~/.grok/config.toml 并添加：
[mcp_servers.playwright]
command = "npx"
args = ["@playwright/mcp@latest"]更多信息，请参阅 Grok MCP 文档。
在 Junie CLI 中添加 Playwright MCP 服务器：
输入 /mcp
按 Ctrl+A 添加新的 MCP 服务器
从列表中选择 Playwright
或者，添加到 .junie/mcp/mcp.json：
{
"mcpServers": {
"Playwright": {
"command": "npx",
"args": [
"-y",
"@playwright/mcp@latest"
]
}
}
}更多信息，请参阅 Junie MCP 配置文档。
按照 MCP 服务器文档操作。例如在 .kiro/settings/mcp.json 中：
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}
进入右侧边栏的 程序 -> 安装 -> 编辑 mcp.json。使用上述标准配置。
按照 MCP 服务器文档操作。例如在 ~/.config/opencode/opencode.json 中：
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"playwright": {
"type": "local",
"command": [
"npx",
"@playwright/mcp@latest"
],
"enabled": true
}
}
}
在 VSCode 或 IntelliJ 中打开 Qodo Gen 聊天面板 → 连接更多工具 → + 添加新 MCP → 粘贴上述标准配置。
点击 保存。
按照 MCP 安装指南操作，使用上述标准配置。你也可以使用 VS Code CLI 安装 Playwright MCP 服务器：
# For VS Code
code --add-mcp '{"name":"playwright","command":"npx","args":["@playwright/mcp@latest"]}'安装后，Playwright MCP 服务器将可在 VS Code 中与你的 GitHub Copilot 代理一起使用。
进入 设置 -> AI -> 管理 MCP 服务器 -> + 添加 以添加 MCP 服务器。使用上述标准配置。
或者，在 Warp 提示符中使用斜杠命令 /add-mcp 并粘贴上述标准配置：
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest"
]
}
}
}按照 Windsurf MCP 的文档操作。使用上述标准配置。
Playwright MCP 服务器支持以下参数。它们可以在上述 JSON 配置中作为 "args" 列表的一部分提供：
选项 | 描述 |
--allowed-hosts <hosts...> | 该服务器被允许提供服务的逗号分隔的主机列表。默认为服务器绑定到的主机。传递 "*" 以禁用主机检查。环境变量 |
--allowed-origins | 允许浏览器请求的受信任来源的分号分隔列表。默认为允许所有来源。重要提示：不作为安全边界，且不影响重定向。环境变量 |
--allow-unrestricted-file-access | 允许访问工作区根目录之外的文件。也允许无限制地访问 file:// URL。默认情况下，对文件系统的访问仅限于工作区根目录（如果没有配置根目录，则为当前工作目录），并且阻止导航到 file:// URL。环境变量 |
--blocked-origins | 阻止浏览器请求的来源的分号分隔列表。阻止列表在允许列表之前评估。如果未使用允许列表，不匹配阻止列表的请求仍被允许。重要提示：不作为安全边界，且不影响重定向。环境变量 |
--block-service-workers | 阻止 Service Worker环境变量 |
--browser | 要使用的浏览器或 Chrome 频道，可能的值：chrome、firefox、webkit、msedge。环境变量 |
--caps | 要启用的附加功能的逗号分隔列表，可能的值：vision、pdf、devtools。环境变量 |
--cdp-endpoint | 要连接的 CDP 端点。环境变量 |
--cdp-header <headers...> | 随连接请求发送的 CDP 标头，可以指定多个。环境变量 |
--cdp-timeout | 连接到 CDP 端点的超时时间（毫秒），默认为 30000 毫秒环境变量 |
--codegen | 指定用于代码生成的语言，可能的值："typescript"、"python"、"java"、"csharp"、"none"。默认为 "typescript"。环境变量 |
--config | 配置文件路径。环境变量 |
--console-level | 要返回的控制台消息级别："error"、"warning"、"info"、"debug"。每个级别包括更严重级别的消息。环境变量 |
--device | 要模拟的设备，例如："iPhone 15"环境变量 |
--mobile | 模拟通用移动设备（Chromium 为 Pixel 10，WebKit 为 iPhone 17）。移动页面通常更轻量，可以节省令牌。不能与 --device 组合使用。环境变量 |
--executable-path | 浏览器可执行文件路径。环境变量 |
--extension | 连接到正在运行的浏览器实例（仅限 Edge/Chrome）。需要安装 "Playwright 扩展"。环境变量 |
--endpoint | 要连接的绑定浏览器端点。环境变量 |
--grant-permissions <permissions...> | 授予浏览器上下文的权限列表，例如 "geolocation"、"clipboard-read"、"clipboard-write"。环境变量 |
--headless | 以无头模式运行浏览器，默认带头模式环境变量 |
--host | 绑定服务器的主机。默认为 localhost。使用 0.0.0.0 绑定到所有接口。环境变量 |
--ignore-https-errors | 忽略 HTTPS 错误环境变量 |
--init-page <path...> | 要在 Playwright 页面对象上评估的 TypeScript 文件路径环境变量 |
--init-script <path...> | 要添加为初始化脚本的 JavaScript 文件路径。该脚本将在每个页面中任何页面脚本之前执行。可以多次指定。环境变量 |
--isolated | 将浏览器配置文件保留在内存中，不保存到磁盘。环境变量 |
--image-responses | 是否向客户端发送图像响应。可以是 "allow" 或 "omit"。默认为 "allow"。环境变量 |
--no-sandbox | 对所有通常被沙盒化的进程类型禁用沙盒。环境变量 |
--output-dir | 输出文件的目录路径。环境变量 |
--output-max-size | 淘汰旧输出文件的阈值，以字节为单位。环境变量 |
--port | SSE 传输的监听端口。环境变量 |
--proxy-bypass | 绕过代理的逗号分隔的域名，例如 ".com,chromium.org,.domain.com"环境变量 |
--proxy-server | 指定代理服务器，例如 "http://myproxy:3128" 或 "socks5://myproxy:8080"环境变量 |
--sandbox | 对所有通常不被沙盒化的进程类型启用沙盒。环境变量 |
--save-session | 是否将 Playwright MCP 会话保存到输出目录中。环境变量 |
--secrets | 包含符合 dotenv 格式的密钥的文件路径环境变量 |
--shared-browser-context | 在所有连接的 HTTP 客户端之间重复使用相同的浏览器上下文。环境变量 |
--snapshot-boxes | 在快照中，将每个元素的边界框包含为 [box=x,y,width,height]。坐标相对于视口，以 CSS 像素为单位。环境变量 |
--snapshot-mode | 为响应拍摄快照时，指定要使用的模式。可以是 "full" 或 "none"。默认为 "full"。环境变量 |
--storage-state | 用于隔离会话的存储状态文件路径。环境变量 |
--test-id-attribute | 指定用于测试 ID 的属性，默认为 "data-testid"环境变量 |
--timeout-action | 指定操作超时时间（毫秒），默认为 5000 毫秒环境变量 |
--timeout-navigation | 指定导航超时时间（毫秒），默认为 60000 毫秒环境变量 |
--timeout-settle | 每次操作后等待触发的工作稳定下来的时间（毫秒），默认为 500 毫秒环境变量 |
--user-agent | 指定用户代理字符串环境变量 |
--user-data-dir | 用户数据目录路径。如果未指定，将创建一个临时目录。环境变量 |
--viewport-size | 指定浏览器视口大小（像素），例如 "1280x720"环境变量 |
您可以像常规浏览器（默认）一样使用持久配置文件运行 Playwright MCP，在测试会话的隔离上下文中运行，或使用浏览器扩展连接到现有浏览器。
持久配置文件
所有登录信息将存储在持久配置文件中，您可以在会话之间删除它以清除离线状态。
持久配置文件位于以下位置，您可以使用 --user-data-dir 参数覆盖它。
# Windows
%USERPROFILE%\AppData\Local\ms-playwright\mcp-{channel}-{workspace-hash}
# macOS
- ~/Library/Caches/ms-playwright/mcp-{channel}-{workspace-hash}
# Linux
- ~/.cache/ms-playwright/mcp-{channel}-{workspace-hash}{workspace-hash} 源自 MCP 客户端的工作区根目录，因此不同项目会自动获得独立的配置文件。
[!IMPORTANT] 一个持久配置文件一次只能被一个浏览器实例使用，因此共享同一工作区的并发 MCP 客户端会发生冲突。要并行运行多个客户端，请为每个额外的客户端使用
--isolated启动，或将其指向不同的--user-data-dir。
隔离模式
在隔离模式下，每个会话都在隔离配置文件中启动。每次您要求 MCP 关闭浏览器时，会话关闭，该会话的所有存储状态都会丢失。您可以通过配置的 contextOptions 或通过 --storage-state 参数向浏览器提供初始存储状态。在此处了解有关存储状态的更多信息 here。
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": [
"@playwright/mcp@latest",
"--isolated",
"--storage-state={path/to/storage.json}"
]
}
}
}浏览器扩展
Playwright MCP Chrome 扩展允许您连接到现有浏览器标签页，并利用您已登录的会话和浏览器状态。请参阅 microsoft/playwright › packages/extension 获取安装和设置说明。
有多种方法可以向浏览器上下文或页面提供初始状态。
对于存储状态，您可以：
使用 --user-data-dir 参数从用户数据目录开始。这将在会话之间持久保存所有浏览器数据。
使用 --storage-state 参数从存储状态文件开始。这将从文件加载 cookies 和本地存储到隔离的浏览器上下文中。
对于页面状态，您可以使用：
--init-page 指向一个 TypeScript 文件，该文件将在 Playwright 页面对象上执行。这允许您运行任意代码来设置页面。
// init-page.ts
export default async ({ page }) => {
await page.context().grantPermissions(['geolocation']);
await page.context().setGeolocation({ latitude: 37.7749, longitude: -122.4194 });
await page.setViewportSize({ width: 1280, height: 720 });
};--init-script 指向一个 JavaScript 文件，该文件将作为初始化脚本添加。该脚本将在每个页面中的任何页面脚本之前执行。这对于覆盖浏览器 API 或设置环境非常有用。
// init-script.js
window.isPlaywrightMCP = true;Playwright MCP 服务器可以使用 JSON 配置文件进行配置。您可以使用 --config 命令行选项指定配置文件：
npx @playwright/mcp@latest --config path/to/config.json{
/**
* The browser to use.
*/
browser?: {
/**
* The type of browser to use.
*/
browserName?: 'chromium' | 'firefox' | 'webkit';
/**
* Keep the browser profile in memory, do not save it to disk.
*/
isolated?: boolean;
/**
* Path to a user data directory for browser profile persistence.
* Temporary directory is created by default.
*/
userDataDir?: string;
/**
* Launch options passed to
* @see https://playwright.dev/docs/api/class-browsertype#browser-type-launch-persistent-context
*
* This is useful for settings options like `channel`, `headless`, `executablePath`, etc.
*/
launchOptions?: playwright.LaunchOptions;
/**
* Context options for the browser context.
*
* This is useful for settings options like `viewport`.
*/
contextOptions?: playwright.BrowserContextOptions;
/**
* Chrome DevTools Protocol endpoint to connect to an existing browser instance in case of Chromium family browsers.
*/
cdpEndpoint?: string;
/**
* CDP headers to send with the connect request.
*/
cdpHeaders?: Record<string, string>;
/**
* Timeout in milliseconds for connecting to CDP endpoint. Defaults to 30000 (30 seconds). Pass 0 to disable timeout.
*/
cdpTimeout?: number;
/**
* Remote endpoint to connect to an existing Playwright server. May be a
* WebSocket URL string, or a [ConnectOptions] object that mirrors the
* `connectOptions` shape used by the test runner. When passed as an object,
* `exposeNetwork`, `headers`, `slowMo`, and `timeout` are forwarded to the
* underlying connect call.
*/
remoteEndpoint?: string | playwright.ConnectOptions & { endpoint: string };
/**
* Paths to TypeScript files to add as initialization scripts for Playwright page.
*/
initPage?: string[];
/**
* Paths to JavaScript files to add as initialization scripts.
* The scripts will be evaluated in every page before any of the page's scripts.
*/
initScript?: string[];
},
/**
* Connect to a running browser instance (Edge/Chrome only). If specified, `browser`
* config is ignored.
* Requires the "Playwright Extension" to be installed.
*/
extension?: boolean;
server?: {
/**
* The port to listen on for SSE or MCP transport.
*/
port?: number;
/**
* The host to bind the server to. Default is localhost. Use 0.0.0.0 to bind to all interfaces.
*/
host?: string;
/**
* The hosts this server is allowed to serve from. Defaults to the host server is bound to.
* This is not for CORS, but rather for the DNS rebinding protection.
*/
allowedHosts?: string[];
},
/**
* List of enabled tool capabilities. Possible values:
* - 'core': Core browser automation features.
* - 'pdf': PDF generation and manipulation.
* - 'vision': Coordinate-based interactions.
* - 'devtools': Developer tools features.
*/
capabilities?: ToolCapability[];
/**
* Whether to save the Playwright session into the output directory.
*/
saveSession?: boolean;
/**
* Reuse the same browser context between all connected HTTP clients.
*/
sharedBrowserContext?: boolean;
/**
* Secrets are used to replace matching plain text in the tool responses to prevent the LLM
* from accidentally getting sensitive data. It is a convenience and not a security feature,
* make sure to always examine information coming in and from the tool on the client.
*/
secrets?: Record<string, string>;
/**
* The directory to save output files.
*/
outputDir?: string;
/**
* Threshold for evicting old output files, in bytes.
*/
outputMaxSize?: number;
console?: {
/**
* The level of console messages to return. Each level includes the messages of more severe levels. Defaults to "info".
*/
level?: 'error' | 'warning' | 'info' | 'debug';
},
network?: {
/**
* List of origins to allow the browser to request. Default is to allow all. Origins matching both `allowedOrigins` and `blockedOrigins` will be blocked.
*
* Supported formats:
* - Full origin: `https://example.com:8080` - matches only that origin
* - Wildcard port: `http://localhost:*` - matches any port on localhost with http protocol
*/
allowedOrigins?: string[];
/**
* List of origins to block the browser to request. Origins matching both `allowedOrigins` and `blockedOrigins` will be blocked.
*
* Supported formats:
* - Full origin: `https://example.com:8080` - matches only that origin
* - Wildcard port: `http://localhost:*` - matches any port on localhost with http protocol
*/
blockedOrigins?: string[];
};
/**
* Specify the attribute to use for test ids, defaults to "data-testid".
*/
testIdAttribute?: string;
timeouts?: {
/*
* Configures default action timeout: https://playwright.dev/docs/api/class-page#page-set-default-timeout. Defaults to 5000ms.
*/
action?: number;
/*
* Configures default navigation timeout: https://playwright.dev/docs/api/class-page#page-set-default-navigation-timeout. Defaults to 60000ms.
*/
navigation?: number;
/**
* Configures default expect timeout: https://playwright.dev/docs/test-timeouts#expect-timeout. Defaults to 5000ms.
*/
expect?: number;
/**
* How long to wait after each action for triggered work (navigations, requests) to settle before responding. Defaults to 500ms.
*/
settle?: number;
};
/**
* Whether to send image responses to the client. Can be "allow", "omit", or "auto". Defaults to "auto", which sends images if the client can display them.
*/
imageResponses?: 'allow' | 'omit';
snapshot?: {
/**
* When taking snapshots for responses, specifies the mode to use.
*/
mode?: 'full' | 'none';
/**
* Whether to include each element's bounding box as [box=x,y,width,height] in snapshots.
* Coordinates are viewport-relative, in CSS pixels (Element.getBoundingClientRect).
*/
boxes?: boolean;
};
/**
* allowUnrestrictedFileAccess acts as a guardrail to prevent the LLM from accidentally
* wandering outside its intended workspace. It is a convenience defense to catch unintended
* file access, not a secure boundary; a deliberate attempt to reach other directories can be
* easily worked around, so always rely on client-level permissions for true security.
*/
allowUnrestrictedFileAccess?: boolean;
/**
* Specify the language to use for code generation.
*/
codegen?: 'typescript' | 'python' | 'java' | 'csharp' | 'none';
}在没有显示器的系统上或从 IDE 的工作进程运行有头浏览器时，请从具有 DISPLAY 的环境中运行 MCP 服务器，并传递 --port 标志以启用 HTTP 传输。
npx @playwright/mcp@latest --port 8931然后在 MCP 客户端配置中，将 url 设置为 HTTP 端点：
{
"mcpServers": {
"playwright": {
"url": "http://localhost:8931/mcp"
}
}
}Related MCP server: Playwright MCP Server
Playwright MCP 不是安全边界。请参阅 MCP 安全最佳实践 获取保护部署的指导。
注意： 目前 Docker 实现仅支持无头 Chromium。
{
"mcpServers": {
"playwright": {
"command": "docker",
"args": ["run", "-i", "--rm", "--init", "--pull=always", "mcr.microsoft.com/playwright/mcp"]
}
}
}或者，如果您希望将容器作为长期运行的服务运行，而不是让 MCP 客户端生成它，请使用：
docker run -d -i --rm --init --pull=always \
--entrypoint node \
--name playwright \
-p 8931:8931 \
mcr.microsoft.com/playwright/mcp \
/app/cli.js --headless --browser chromium --no-sandbox --port 8931 --host 0.0.0.0服务器将在主机端口 8931 上监听，任何 MCP 客户端都可以访问。
您可以自行构建 Docker 镜像。
docker build -t mcr.microsoft.com/playwright/mcp .import http from 'http';
import { createConnection } from '@playwright/mcp';
import { SSEServerTransport } from '@modelcontextprotocol/sdk/server/sse.js';
http.createServer(async (req, res) => {
// ...
// Creates a headless Playwright MCP server with SSE transport
const connection = await createConnection({ browser: { launchOptions: { headless: true } } });
const transport = new SSEServerTransport('/messages', res);
await connection.connect(transport);
// ...
});browser_click
标题：点击
描述：在网页上执行点击操作
参数：
element (字符串，可选)：用于获取与元素交互权限的人类可读元素描述
target (字符串)：页面快照中的精确目标元素引用，或唯一的元素选择器
doubleClick (布尔值，可选)：是否执行双击而不是单击
button (字符串，可选)：要点击的按钮，默认为左键
modifiers (数组，可选)：要按下的修饰键
只读：false
browser_close
标题：关闭浏览器
描述：关闭页面
参数：无
只读：false
browser_console_messages
标题：获取控制台消息
描述：返回所有控制台消息
参数：
level (字符串)：要返回的控制台消息级别。每个级别包括更严重级别的消息。默认为 "info"。
all (布尔值，可选)：返回自会话开始以来的所有控制台消息，而不仅仅是自上次导航以来的消息。默认为 false。
filename (字符串，可选)：保存控制台消息的文件名。如果未提供，消息将以文本形式返回。
只读：true
browser_drag
标题：拖拽鼠标
描述：在两个元素之间执行拖放操作
参数：
startElement (字符串，可选)：用于获取与元素交互权限的人类可读源元素描述
startTarget (字符串)：页面快照中的精确目标元素引用，或唯一的元素选择器
endElement (字符串，可选)：用于获取与元素交互权限的人类可读目标元素描述
endTarget (字符串)：页面快照中的精确目标元素引用，或唯一的元素选择器
只读：false
browser_drop
标题：将文件或数据拖放到元素上
描述：将文件或 MIME 类型的数据拖放到元素上，就像从页面外部拖拽一样。必须至少提供 "paths" 或 "data" 之一。
参数：
element (字符串，可选)：用于获取与元素交互权限的人类可读元素描述
target (字符串)：页面快照中的精确目标元素引用，或唯一的元素选择器
paths (数组，可选)：要拖放到元素上的文件的绝对路径。
data (对象，可选)：要拖放的数据，作为 MIME 类型到字符串值的映射（例如 {"text/plain": "hello", "text/uri-list": "https://example.com"}）。
只读：false
browser_evaluate
标题：评估 JavaScript
描述：在页面或元素上评估 JavaScript 表达式
参数：
element (字符串，可选)：用于获取与元素交互权限的人类可读元素描述
target (字符串，可选)：页面快照中的精确目标元素引用，或唯一的元素选择器
function (字符串)：() => { /* 代码 / } 或 (element) => { / 代码 */ }（当提供元素时）
filename (字符串，可选)：保存结果的文件名。如果未提供，结果将以文本形式返回。
只读：false
browser_file_upload
标题：上传文件
描述：上传一个或多个文件
参数：
paths (数组，可选)：要上传的文件的绝对路径。可以是单个文件或多个文件。如果省略，则取消文件选择器。
只读：false
browser_fill_form
标题：填写表单
描述：填写多个表单字段
参数：
fields (数组)：要填写的字段
只读：false
browser_find
标题：在页面快照中查找
描述：在当前页面的无障碍快照中搜索文本或正则表达式。返回匹配的快照节点，并附带几行上下文（如搜索片段），每个节点显示在其从树根开始的路径下，这比在只需要定位元素及其引用时捕获整个快照更经济。
参数：
text (字符串，可选)：要在页面快照中搜索的纯文本（不区分大小写的子字符串匹配）。提供 text 或 regex，不能同时提供。
regex (字符串，可选)：要在页面快照中搜索的正则表达式。默认区分大小写；将模式包裹在斜杠中以添加标志，例如 "/error/i" 表示不区分大小写。提供 text 或 regex，不能同时提供。
只读：true
browser_handle_dialog
标题：处理对话框
描述：处理对话框
参数：
accept (布尔值)：是否接受对话框。
promptText (字符串，可选)：如果是提示对话框，则为提示文本。
只读：false
browser_hover
标题：悬停鼠标
描述：悬停在页面元素上
参数：
element (字符串，可选)：用于获取与元素交互权限的人类可读元素描述
target (字符串)：页面快照中的精确目标元素引用，或唯一的元素选择器
只读：false
browser_navigate
标题：导航到 URL
描述：导航到 URL
参数：
url (字符串)：要导航到的 URL
只读：false
browser_navigate_back
标题：返回
描述：返回历史记录中的上一页
参数：无
只读：false
browser_network_request
标题：显示网络请求详情
描述：返回单个网络请求的完整详细信息（标头和正文），如果设置了 part，则返回单个部分。使用 browser_network_requests 中的编号。
参数：
index (整数)：请求的基于 1 的索引，如 browser_network_requests 所打印。
part (字符串，可选)：仅返回请求的此部分。省略以返回完整详细信息。
filename (字符串，可选)：保存结果的文件名。如果未提供，输出将以文本形式返回。
只读：true
browser_network_requests
标题：列出网络请求
描述：返回自加载页面以来的编号网络请求列表。使用 browser_network_request 和编号获取完整详细信息。
参数：
static (布尔值)：是否包括成功的静态资源，如图像、字体、脚本等。默认为 false。
filter (字符串，可选)：仅返回 URL 匹配此正则表达式的请求（例如 "/api/.*user"）。
filename (字符串，可选)：保存网络请求的文件名。如果未提供，请求将以文本形式返回。
只读：true
browser_press_key
标题：按下按键
描述：按下键盘上的一个键
参数：
key（字符串）：要按下的键名称或要生成的字符，例如 ArrowLeft 或 a
只读：false
browser_resize
标题：调整浏览器窗口大小
描述：调整浏览器窗口的大小
参数：
width（数字）：浏览器窗口的宽度
height（数字）：浏览器窗口的高度
只读：false
browser_run_code_unsafe
标题：运行 Playwright 代码（不安全）
描述：运行一段 Playwright 代码片段。不安全：在 Playwright 服务器进程中执行任意 JavaScript，等同于远程代码执行（RCE）。
参数：
code（字符串，可选）：一个包含要执行的 Playwright 代码的 JavaScript 函数。它将通过一个参数 page 被调用，你可以使用它进行任何页面交互。例如：async (page) => { await page.getByRole('button', { name: 'Submit' }).click(); return await page.title(); }
filename（字符串，可选）：从指定文件加载代码。如果同时提供了 code 和 filename，则 code 将被忽略。
只读：false
browser_select_option
标题：选择选项
描述：在下拉菜单中选择一个选项
参数：
element（字符串，可选）：用于获取与元素交互权限的人类可读元素描述
target（字符串）：来自页面快照的精确目标元素引用，或唯一的元素选择器
values（数组）：要在下拉菜单中选择的值数组。可以是单个值或多个值。
只读：false
browser_snapshot
标题：页面快照
描述：捕获当前页面的无障碍快照，这比截图更好
参数：
target（字符串，可选）：来自页面快照的精确目标元素引用，或唯一的元素选择器
filename（字符串，可选）：将快照保存到 markdown 文件，而不是在响应中返回。
depth（数字，可选）：限制快照树的深度
boxes（布尔值，可选）：在快照中包含每个元素的边界框，格式为 [box=x,y,width,height]。坐标相对于视口，以 CSS 像素为单位（Element.getBoundingClientRect）
只读：true
browser_take_screenshot
标题：截图
描述：截取当前页面的屏幕截图。你不能基于截图执行操作，请使用 browser_snapshot 进行操作。
参数：
element（字符串，可选）：用于获取与元素交互权限的人类可读元素描述
target（字符串，可选）：来自页面快照的精确目标元素引用，或唯一的元素选择器
type（字符串，可选）：截图的图像格式。如果未设置，则从文件扩展名推断，否则为 png。
filename（字符串，可选）：保存截图的文件名。如果未指定，默认为 page-{timestamp}.{png|jpeg|webp}。建议使用相对文件名以保持在输出目录内。
fullPage（布尔值，可选）：如果为 true，则截取整个可滚动页面的截图，而不是当前可见的视口。不能与元素截图一起使用。
scale（字符串）：图像分辨率比例。"css" 生成以 CSS 像素为单位的截图（较小，跨设备一致）。"device" 生成使用设备像素的高分辨率截图（较大，考虑设备像素比）。默认为 css。
只读：true
browser_type
标题：输入文本
描述：在可编辑元素中输入文本
参数：
element（字符串，可选）：用于获取与元素交互权限的人类可读元素描述
target（字符串）：来自页面快照的精确目标元素引用，或唯一的元素选择器
text（字符串）：要输入到元素中的文本
submit（布尔值，可选）：是否提交输入的文本（之后按 Enter）
slowly（布尔值，可选）：是否一次输入一个字符。用于触发页面中的按键处理程序。默认情况下，整个文本会一次性填入。
只读：false
browser_wait_for
标题：等待
描述：等待文本出现或消失，或等待指定时间过去
参数：
time（数字，可选）：等待的时间（秒）
text（字符串，可选）：要等待出现的文本
textGone（字符串，可选）：要等待消失的文本
只读：false
browser_tabs
标题：管理标签页
描述：列出、创建、关闭或选择一个浏览器标签页。
参数：
action（字符串）：要执行的操作
index（数字，可选）：标签页索引，用于关闭/选择。如果关闭时省略，则关闭当前标签页。
url（字符串，可选）：新标签页中导航到的 URL，用于新建标签页。
只读：false
browser_get_config
标题：获取配置
描述：获取合并 CLI 选项、环境变量和配置文件后的最终解析配置。
参数：无
只读：true
browser_network_state_set
标题：设置网络状态
描述：将浏览器网络状态设置为在线或离线。离线时，所有网络请求将失败。
参数：
state（字符串）：设置为 "offline" 以模拟离线模式，"online" 以恢复网络连接
只读：false
browser_route
标题：模拟网络请求
描述：设置路由以模拟匹配 URL 模式的网络请求
参数：
pattern（字符串）：要匹配的 URL 模式（例如 "/api/users"、"/*.{png,jpg}"）
status（数字，可选）：返回的 HTTP 状态码（默认：200）
body（字符串，可选）：响应体（文本或 JSON 字符串）
contentType（字符串，可选）：Content-Type 标头（例如 "application/json"、"text/html"）
headers（数组，可选）：以 "名称: 值" 格式添加的标头
removeHeaders（字符串，可选）：要从请求中移除的标头名称列表，以逗号分隔
只读：false
browser_route_list
标题：列出网络路由
描述：列出所有活动的网络路由
参数：无
只读：true
browser_unroute
标题：移除网络路由
描述：移除匹配某个模式的网络路由（如果未指定模式，则移除所有路由）
参数：
pattern（字符串，可选）：要取消路由的 URL 模式（省略则移除所有路由）
只读：false
browser_cookie_clear
标题：清除 Cookie
描述：清除所有 Cookie
参数：无
只读：false
browser_cookie_delete
标题：删除 Cookie
描述：删除特定的 Cookie
参数：
name（字符串）：要删除的 Cookie 名称
只读：false
browser_cookie_get
标题：获取 Cookie
描述：按名称获取特定的 Cookie
参数：
name（字符串）：要获取的 Cookie 名称
只读：true
browser_cookie_list
标题：列出 Cookie
描述：列出所有 Cookie（可选地按域名/路径过滤）
参数：
domain（字符串，可选）：按域名过滤 Cookie
path（字符串，可选）：按路径过滤 Cookie
只读：true
browser_cookie_set
标题：设置 Cookie
描述：设置一个带有可选标志（域名、路径、过期时间、httpOnly、secure、sameSite）的 Cookie
参数：
name（字符串）：Cookie 名称
value（字符串）：Cookie 值
domain（字符串，可选）：Cookie 域名
path（字符串，可选）：Cookie 路径
expires（数字，可选）：Cookie 过期时间（Unix 时间戳）
httpOnly（布尔值，可选）：Cookie 是否仅 HTTP
secure（布尔值，可选）：Cookie 是否安全
sameSite（字符串，可选）：Cookie 的 SameSite 属性
只读：false
browser_localstorage_clear
标题：清除 localStorage
描述：清除所有 localStorage
参数：无
只读：false
browser_localstorage_delete
标题：删除 localStorage 项
描述：删除一个 localStorage 项
参数：
key（字符串）：要删除的键
只读：false
browser_localstorage_get
标题：获取 localStorage 项
描述：按键获取一个 localStorage 项
参数：
key（字符串）：要获取的键
只读：true
browser_localstorage_list
标题：列出 localStorage
描述：列出所有 localStorage 键值对
参数：无
只读：true
browser_localstorage_set
标题：设置 localStorage 项
描述：设置一个 localStorage 项
参数：
key（字符串）：要设置的键
value（字符串）：要设置的值
只读：false
browser_sessionstorage_clear
标题：清除 sessionStorage
描述：清除所有 sessionStorage
参数：无
只读：false
browser_sessionstorage_delete
标题：删除 sessionStorage 项
描述：删除一个 sessionStorage 项
参数：
key（字符串）：要删除的键
只读：false
browser_sessionstorage_get
标题：获取 sessionStorage 项
描述：按键获取一个 sessionStorage 项
参数：
key（字符串）：要获取的键
只读：true
browser_sessionstorage_list
标题：列出 sessionStorage
描述：列出所有 sessionStorage 键值对
参数：无
只读：true
browser_sessionstorage_set
标题：设置 sessionStorage 项
描述：设置一个 sessionStorage 项
参数：
key (string)：要设置的键
value (string)：要设置的值
只读：false
browser_set_storage_state
标题：恢复存储状态
描述：从文件恢复存储状态（cookies、localStorage）。恢复前会清除现有的 cookies 和 localStorage。
参数：
filename (string)：要恢复的存储状态文件路径
只读：false
browser_storage_state
标题：保存存储状态
描述：将存储状态（cookies、localStorage）保存到文件以供后续重用
参数：
filename (string, optional)：保存存储状态的文件名。未指定时默认为 storage-state-{timestamp}.json。
只读：true
browser_annotate
标题：为当前页面添加注释
描述：以注释模式打开当前页面的 Playwright Dashboard，并等待用户绘制注释。返回带注释的截图、ARIA 快照和注释列表。
参数：无
只读：true
browser_hide_highlight
标题：隐藏元素高亮
描述：移除之前为元素添加的高亮覆盖层。
参数：
element (string, optional)：添加高亮时使用的人类可读元素描述；必须与传递给 browser_highlight 的值匹配。
target (string, optional)：页面快照中的精确目标元素引用，或唯一的元素选择器
只读：true
browser_highlight
标题：高亮元素
描述：在页面上元素周围显示一个持久的高亮覆盖层。
参数：
element (string, optional)：用于获取与元素交互权限的人类可读元素描述
target (string)：页面快照中的精确目标元素引用，或唯一的元素选择器
style (string, optional)：应用于高亮覆盖层的额外内联 CSS，例如 "outline: 2px dashed red"。
只读：true
browser_resume
标题：恢复暂停的脚本执行
描述：在脚本执行暂停后恢复执行。当 step 设置为 true 时，执行将在下一个动作之前再次暂停。
参数：
step (boolean, optional)：当为 true 时，执行将在下一个动作之前再次暂停，允许逐步调试。
location (string, optional)：在特定的 <文件>:<行号> 处暂停执行，例如 "example.spec.ts:42"。
只读：false
browser_start_tracing
标题：开始追踪
描述：开始记录追踪
参数：无
只读：true
browser_start_video
标题：开始视频
描述：开始录制视频
参数：
filename (string, optional)：保存视频的文件名。
size (object, optional)：视频尺寸
只读：true
browser_stop_tracing
标题：停止追踪
描述：停止记录追踪
参数：无
只读：true
browser_stop_video
标题：停止视频
描述：停止录制视频
参数：无
只读：true
browser_video_chapter
标题：视频章节
描述：为视频录制添加章节标记。显示全屏章节卡片，带有模糊背景。
参数：
title (string)：章节标题
description (string, optional)：章节描述
duration (number, optional)：章节卡片显示时长（毫秒）
只读：true
browser_video_hide_actions
标题：隐藏动作覆盖层
描述：停止为页面上执行的动作添加注释。
参数：无
只读：true
browser_video_show_actions
标题：显示动作覆盖层
描述：为页面上后续执行的动作添加注释，显示一个标注框，标明动作名称并高亮目标元素。在视频录制或屏幕录制时有用。
参数：
duration (number, optional)：每个动作注释在屏幕上停留的时间（毫秒）。默认为 500。
position (string, optional)：动作标题相对于页面的放置位置。默认为右上角。
cursor (string, optional)：指针动作的光标装饰。"pointer"（默认）模拟鼠标指针从前一个动作点移动到下一个；"none" 禁用光标装饰。
只读：true
browser_mouse_click_xy
标题：点击
描述：在指定位置点击鼠标按钮
参数：
x (number)：X 坐标
y (number)：Y 坐标
button (string, optional)：要点击的按钮，默认为左键
clickCount (number, optional)：点击次数，默认为 1
delay (number, optional)：按下鼠标和释放鼠标之间的等待时间（毫秒），默认为 0
只读：false
browser_mouse_down
标题：按下鼠标
描述：按下鼠标按钮
参数：
button (string, optional)：要按下的按钮，默认为左键
只读：false
browser_mouse_drag_xy
标题：拖动鼠标
描述：将鼠标左键拖动到指定位置
参数：
startX (number)：起始 X 坐标
startY (number)：起始 Y 坐标
endX (number)：结束 X 坐标
endY (number)：结束 Y 坐标
只读：false
browser_mouse_move_xy
标题：移动鼠标
描述：将鼠标移动到指定位置
参数：
x (number)：X 坐标
y (number)：Y 坐标
只读：false
browser_mouse_up
标题：释放鼠标
描述：释放鼠标按钮
参数：
button (string, optional)：要释放的按钮，默认为左键
只读：false
browser_mouse_wheel
标题：滚动鼠标滚轮
描述：滚动鼠标滚轮
参数：
deltaX (number)：X 方向增量
deltaY (number)：Y 方向增量
只读：false
browser_pdf_save
标题：另存为 PDF
描述：将页面保存为 PDF
参数：
filename (string, optional)：保存 PDF 的文件名。未指定时默认为 page-{timestamp}.pdf。建议使用相对文件名以保持在输出目录内。
只读：true
browser_generate_locator
标题：为元素创建定位器
描述：为给定元素生成定位器，以便在测试中使用
参数：
element (string, optional)：用于获取与元素交互权限的人类可读元素描述
target (string)：页面快照中的精确目标元素引用，或唯一的元素选择器
只读：true
browser_verify_element_visible
标题：验证元素可见
描述：验证元素在页面上是否可见
参数：
role (string)：元素的 ROLE（角色）。可以在快照中找到，例如：- {ROLE} "Accessible Name":
accessibleName (string)：元素的 ACCESSIBLE_NAME（可访问名称）。可以在快照中找到，例如：- role "{ACCESSIBLE_NAME}"
只读：false
browser_verify_list_visible
标题：验证列表可见
描述：验证列表在页面上是否可见
参数：
element (string)：人类可读的列表描述
target (string)：指向列表的精确目标元素引用
items (array)：要验证的项目
只读：false
browser_verify_text_visible
标题：验证文本可见
描述：验证文本在页面上是否可见。如果可能，优先使用 browser_verify_element_visible。
参数：
text (string)：要验证的 TEXT（文本）。可以在快照中找到，例如：- role "Accessible Name": {TEXT} 或 - text: {TEXT}
只读：false
browser_verify_value
标题：验证值
描述：验证元素的值
参数：
type (string)：元素类型
element (string)：人类可读的元素描述
target (string)：页面快照中的精确目标元素引用
value (string)：要验证的值。对于复选框，使用 "true" 或 "false"。
只读：false
Perform click on a web page
| Name | Required | Description | Default |
|---|---|---|---|
| button | No | Button to click, defaults to left | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| modifiers | No | Modifier keys to press | |
| doubleClick | No | Whether to perform a double click instead of a single click |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=true, indicating the tool mutates state and can be destructive. The description adds no further behavioral disclosure, such as possible navigation or permission requirements. It does not contradict annotations, but provides no value beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. However, it is terse and omits useful context that could be added without bloat, such as the requirement for a snapshot target. It is appropriately sized but not front-loaded with any distinguishing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, no output schema), the description alone is minimally sufficient because the schema fully describes parameters. However, it lacks context about return values, when to use click vs other actions, and potential side effects. The schema covers parameter semantics, so a score of 3 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with every parameter documented (e.g., target is 'Exact target element reference from the page snapshot, or a unique element selector'). The description itself adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Perform click') and the resource ('web page'), which is specific enough. However, it does not differentiate from sibling interaction tools like browser_hover or browser_drag; the agent must infer that 'click' is a distinct action without additional context. It is unambiguous about the core operation but lacks detail on the target element requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites such as needing a page snapshot to obtain a valid target, nor does it contrast with browser_hover or browser_drag. An agent receives no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close the page
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already indicates destructiveHint=true, so the agent knows the action is destructive. The description simply repeats that by saying 'close' without adding any extra context about side effects (e.g., whether it closes just the current tab, loses unsaved state, or affects other tabs). It does not contradict the annotation, but it adds no new behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using only three words. It communicates the essential action and target without any fluff, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description is functional but lacks completeness. It leaves open the scope of 'close'—does it close the current page/tab, or the entire browser? In a context with sibling tools like browser_tabs, this ambiguity could be problematic. More detail would improve it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is trivially complete at 100%. The description does not need to explain any parameter semantics, and the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Close the page' clearly states the action (close) and the resource (page), making it unambiguous. It is distinct from sibling tools like browser_navigate or browser_snapshot, so an agent can easily identify it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention potential alternatives (e.g., using browser_tabs to manage multiple pages) or any conditions that would make closing appropriate. The context is minimal and leaves the decision entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns all console messages
| Name | Required | Description | Default |
|---|---|---|---|
| all | No | Return all console messages since the beginning of the session, not just since the last navigation. Defaults to false. | |
| level | Yes | Level of the console messages to return. Each level includes the messages of more severe levels. Defaults to "info". | info |
| filename | No | Filename to save the console messages to. If not provided, messages are returned as text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint true and destructiveHint false, so the description adds no conflicting side-effect information. It does not elaborate on behavior such as saving to a file, but that is covered by parameter descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundancy, front-loading the verb and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with full schema coverage, the description is adequate, though it omits explicit use-case guidance and output format details beyond what the schema provides.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions, so the tool description itself does not add meaning beyond the schema, but no parameter meaning is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'Returns' and identifies the resource 'console messages' with scope 'all', making the tool's purpose clear and distinct from sibling tools such as network request retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like browser_network_requests or browser_snapshot, nor does it mention filtering or filename-saving scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform drag and drop between two elements
| Name | Required | Description | Default |
|---|---|---|---|
| endTarget | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| endElement | No | Human-readable target element description used to obtain the permission to interact with the element | |
| startTarget | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| startElement | No | Human-readable source element description used to obtain the permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the destructive nature is covered. The description adds no extra behavioral context such as side effects on the DOM or event firing, but it does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and provides the core information without any irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action with well-described parameters and no output schema, the description is mostly complete. It does not mention any return values or wait behavior, but the lack of output schema makes this acceptable. It could have added a note about the order of start and end parameters, but the parameter names and descriptions handle that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all four parameters described. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (perform drag and drop) and the resource (between two elements), distinguishing it from sibling tools like browser_click, browser_hover, and browser_drop. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It does not mention conditions such as needing to move an element or triggering drag-and-drop events, nor does it reference sibling tools like browser_drop or browser_click.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Drop files or MIME-typed data onto an element, as if dragged from outside the page. At least one of "paths" or "data" must be provided.
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | Data to drop, as a map of MIME type to string value (e.g. {"text/plain": "hello", "text/uri-list": "https://example.com"}). | |
| paths | No | Absolute paths to files to drop onto the element. | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey destructive and non-read-only behavior, so the description does not need to repeat that. The description adds useful semantic context about simulating an external drag, but does not disclose any side effects beyond the basic drop action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that concisely explains both the action and the key parameter requirement. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description, combined with the detailed schema and annotations, provides enough information to invoke the tool correctly. There is no output schema, so return-value details are not required, and the parameter permission explanation is handled by the 'element' field description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have clear schema descriptions. The tool description adds an important cross-parameter constraint that at least one of 'paths' or 'data' must be provided, which is not otherwise expressed in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: dropping files or MIME-typed data onto an element. It uses a specific verb and resource, and distinguishes itself from in-page drag operations by specifying 'as if dragged from outside the page'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a useful usage constraint ('At least one of paths or data must be provided') and hints at external drag context, but it does not explicitly name sibling tools or state when to prefer this over browser_file_upload or browser_drag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate JavaScript expression on page or element
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| filename | No | Filename to save the result to. If not provided, result is returned as text. | |
| function | Yes | () => { /* code */ } or (element) => { /* code */ } when element is provided |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag destructiveHint=true and readOnlyHint=false, so the agent knows this can modify state. The description adds minimal context beyond that—it mentions 'on page or element' but doesn't warn about the power of arbitrary JS execution or potential side effects. Since the annotation covers the destructive nature, the description's lack of extra detail keeps it at a baseline 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no redundant words. The action is front-loaded and easy to parse. This is appropriately concise for a tool whose parameter details are already in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this tool executes arbitrary JavaScript with destructive potential, the description is too sparse. It doesn't mention that the function can modify the page, that results can be saved to a file (though schema covers it), or that there is a separate unsafe variant (browser_run_code_unsafe) that might be more appropriate for certain tasks. The description lacks the context an agent needs to safely and correctly use this tool, especially when annotations already warn about destructiveness but the description provides no additional guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are documented in the schema itself. The description does not add any meaning beyond what the schema provides—it doesn't elaborate on the function syntax, target usage, or filename behavior. With high schema coverage, the baseline is 3, and the description contributes nothing extra.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Evaluate' and the resource 'JavaScript expression on page or element', making the core purpose obvious. However, it doesn't distinguish from the sibling browser_run_code_unsafe, which might also execute code, so it loses a point for not differentiating between similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like browser_run_code_unsafe or when to avoid it. No context about prerequisites (e.g., page must be loaded) or scenarios that favor this tool over others. The description simply states the action without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload one or multiple files
| Name | Required | Description | Default |
|---|---|---|---|
| paths | No | The absolute paths to the files to upload. Can be single file or multiple files. If omitted, file chooser is cancelled. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructive behavior and non-read-only semantics, so the description does not need to restate those. However, the description does not mention side effects beyond uploading, such as navigating away, opening or cancelling a file chooser, or potential overwrite behavior, though the parameter description partially covers the cancellation case.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and free of filler. Every word contributes meaning, and the parameter description adds necessary details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description and parameter comment cover the essential input and basic behavior. However, it does not describe what happens after the upload, what success or failure looks like, or how this fits into the broader browser automation workflow, leaving some practical context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines an array of strings, but the parameter description adds important meaning: paths must be absolute, multiple files are allowed, and omitting the parameter cancels the file chooser. This goes beyond the raw schema and helps an agent use the parameter correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Upload') and the resource ('files'), and specifies 'one or multiple'. It does not explicitly state the destination or context, but the tool name and sibling set make the browser file-upload intent sufficiently clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as browser_drop or other browser interaction tools. It also does not mention prerequisites like whether the file chooser must already be open or how paths should be formatted beyond 'absolute'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill multiple form fields
| Name | Required | Description | Default |
|---|---|---|---|
| fields | Yes | Fields to fill in |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=false and destructiveHint=true, so the write and potentially destructive nature is covered. The description adds the 'multiple form fields' detail but does not disclose additional behavior such as overwriting values or submitting the form.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundant words or boilerplate. It is appropriately short and easy to parse, though it sacrifices deeper context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The rich schema fully documents the nested field objects, including target references, type-specific value behavior, and permission-related element descriptions. Combined with the read-only and destructive annotations, the description is sufficient for correct invocation; only alternative-selection guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the fields array and its nested target, name, type, value, and element properties all have descriptive text. The description itself does not add parameter-level meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Fill multiple form fields' clearly identifies the action and resource, and the word 'multiple' helps distinguish it from single-field tools like browser_type. It does not explicitly contrast with sibling tools, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool instead of alternatives such as browser_type, browser_select_option, or browser_click. The term 'multiple' implies batch usage, but there is no explicit when-to-use or exclusion context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the accessibility snapshot of the current page for text or a regular expression. Returns matching snapshot nodes with a few lines of surrounding context (like search snippets), each shown under its path from the root of the tree, which is cheaper than capturing the whole snapshot when you only need to locate an element and its ref.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Plain text to search for in the page snapshot (case-insensitive substring match). Provide either text or regex, not both. | |
| regex | No | Regular expression to search for in the page snapshot. Matching is case-sensitive by default; wrap the pattern in slashes to add flags, e.g. "/error/i" for case-insensitive. Provide either text or regex, not both. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and non-destructive behavior. The description adds useful behavioral detail about return format, surrounding context, path-from-root presentation, and cost characteristics. It is consistent with the annotations, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense, well-structured sentence that front-loads the action and then provides the output shape and the key trade-off. There is no filler or redundancy; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains return shape and the main use case, and annotations cover safety. However, since neither parameter is marked required in the schema, the description could more explicitly instruct the agent to provide exactly one of text or regex.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; both text and regex are already documented with mutual exclusivity and regex flag syntax. The description adds no parameter-level meaning beyond restating that either text or regex is used, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Search'), a clear resource ('the accessibility snapshot of the current page'), and a well-defined result (matching snapshot nodes with surrounding context and refs). It also distinguishes itself from the whole-snapshot sibling by explaining its narrower focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear when-to-use condition: this is 'cheaper than capturing the whole snapshot when you only need to locate an element and its ref.' It implicitly contrasts with browser_snapshot but does not explicitly name the sibling or state when NOT to use this tool, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Handle a dialog
| Name | Required | Description | Default |
|---|---|---|---|
| accept | Yes | Whether to accept the dialog. | |
| promptText | No | The text of the prompt in case of a prompt dialog. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate readOnlyHint=false and destructiveHint=true, covering the main safety aspect. However, the description adds no detail about side effects, such as submitting a form or canceling a prompt, beyond what the parameter names imply. It does not clearly disclose the consequences of accepting or rejecting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and lacks necessary detail, making it under-specified. It is terse but not informative enough to guide an agent effectively, similar to a placeholder like 'Process'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or additional context is provided. The description does not explain what happens after handling the dialog, how the parameters interact, or any post-conditions. This is insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both 'accept' (boolean) and 'promptText' (string for prompt dialogs). The description does not add extra meaning, but the schema already provides adequate parameter semantics, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Handle a dialog' identifies the action and resource but is vague. It does not specify the type of dialog (alert, confirm, prompt) or the precise effect, though the 'accept' parameter implies accept/dismiss. It is distinct from sibling tools, but the purpose is under-specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool, such as after a dialog appears or in contrast to other browser actions. The description gives no context for the appropriate situation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hover over element on page
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=true, so the description doesn't need to re-state them. The description adds no extra behavioral detail about side effects (e.g., triggering JavaScript events, potential menu changes). With annotations present, the bar is lower, but there's still room for more transparency about outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—six words, no redundancy, and perfectly focused on the action. It follows a clear verb-object structure with no extra fluff, making it easy to parse and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple interaction tool, the description, alongside the parameter schema and annotations, is adequate. It lacks details on return values (but no output schema exists) and does not mention any prerequisites or setup. Given the simplicity, it covers essential context without being overlong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (target and element) have descriptions in the schema, achieving 100% coverage. The tool description does not add further meaning beyond the schema; it simply restates the action. Since schema coverage is complete, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (hover) and the target (element on page). It distinguishes itself from sibling tools like click, drag, and type by specifying the hover action. However, it lacks detail about what the hover does (e.g., showing tooltips or hover menus), but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use hover versus other interactions. While it's intuitive that hover is for mouse-over actions, the description doesn't mention edge cases or alternative tools (e.g., use click for activating, hover for previews). It provides minimal implicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns full details (headers and body) of a single network request, or a single part if part is set. Use the number from browser_network_requests.
| Name | Required | Description | Default |
|---|---|---|---|
| part | No | Return only this part of the request. Omit to return full details. | |
| index | Yes | 1-based index of the request, as printed by browser_network_requests. | |
| filename | No | Filename to save the result to. If not provided, output is returned as text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds that it returns headers and body and can filter to a part, but does not elaborate on output structure or edge cases. Given annotation coverage, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant wording. The main purpose is front-loaded, the part option is explained, and the source of the index is given. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only retrieval tool with full schema coverage and annotations, the description is sufficient. It explains the return type (full details or part) and the index source. It lacks explicit output format details, but the enum values for 'part' are self-explanatory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters, so the schema already documents them. The description adds critical value by explaining that 'index' comes from browser_network_requests, which is not in the schema, enhancing clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns full details of a single network request, with an optional 'part' parameter to narrow down. It distinguishes from the sibling tool browser_network_requests by referencing its index, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Use the number from browser_network_requests' explicitly guides when to use this tool—after obtaining a listing. It does not explicitly mention alternatives or exclusions, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a numbered list of network requests since loading the page. Use browser_network_request with the number to get full details.
| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Only return requests whose URL matches this regexp (e.g. "/api/.*user"). | |
| static | Yes | Whether to include successful static resources like images, fonts, scripts, etc. Defaults to false. | |
| filename | No | Filename to save the network requests to. If not provided, requests are returned as text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable context about the temporal scope ('since loading the page') and the numbered list format, which goes beyond annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundancy. The primary action is front-loaded, and the companion tool reference is placed efficiently at the end. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description tells the agent what the tool returns (a numbered list) and how to proceed for details. Since there is no output schema, this is essential. It does not describe potential error cases or edge scenarios, but for a read-only list tool with strong schema coverage, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have schema descriptions covering 100% of the input schema. The tool description does not add any additional meaning to the parameters themselves, so the baseline of 3 applies; it neither enhances nor detracts from what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a numbered list of network requests since page load, and explicitly differentiates from the sibling tool browser_network_request by instructing to use that tool for details. This is a specific verb+resource with a clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage pattern: first call this tool to get a list, then use browser_network_request with the number for full details. This is clear guidance on when to use it versus its companion, though it does not mention any other alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Press a key on the keyboard
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Name of the key to press or a character to generate, such as `ArrowLeft` or `a` |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not mention any side effects, such as triggering keyboard events or potential destructive behavior. The annotations indicate destructiveHint: true, but the description adds no additional behavioral context beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise — a single sentence that directly conveys the action. No unnecessary information or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action with a single well-defined parameter, the description is adequate. It lacks mention of when to use this tool (e.g., for shortcuts or navigation keys) but is otherwise complete for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'key' is fully described in the schema with examples, and schema coverage is 100%. The description adds minimal extra meaning ('on the keyboard') but doesn't clarify key formats or special keys, which is already covered by the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (press) and the resource (key on the keyboard). It is distinct from broader actions like navigate or click, though it does not explicitly differentiate from browser_type (typing) or browser_click (clicking).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings (e.g., browser_type for text entry or browser_click for mouse actions). The description lacks any contextual cues for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resize the browser window
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | Width of the browser window | |
| height | Yes | Height of the browser window |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the bare action. Annotations already indicate it is not read-only and is destructive, but the description adds no extra context about side effects like layout reflows or potential viewport changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short declarative sentence with no unnecessary words. It is perfectly concise and well-structured for the simple action it describes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description is adequate, but it lacks any extra context such as units (e.g., pixels), constraints, or when resizing might be appropriate. Given the simplicity and schema coverage, it is minimally complete but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (width and height), achieving 100% coverage. The description adds no additional meaning about the parameters, so it stays at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (resize) and the resource (browser window), making it distinct from sibling tools like navigate or click. However, it lacks any nuance about whether it resizes the viewport or the entire window, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention scenarios like adjusting viewport for responsive testing or any conditions that would make it preferable to other navigation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Playwright code snippet. Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent.
| Name | Required | Description | Default |
|---|---|---|---|
| code | No | A JavaScript function containing Playwright code to execute. It will be invoked with a single argument, page, which you can use for any page interaction. For example: `async (page) => { await page.getByRole('button', { name: 'Submit' }).click(); return await page.title(); }` | |
| filename | No | Load code from the specified file. If both code and filename are provided, code will be ignored. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so the description's 'Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent' adds specific severity and mechanism beyond the generic flags. This enhances transparency without contradicting annotations, though it could also mention side effects or sandboxing if any.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs purpose and a crucial warning. It front-loads the action and immediately follows with the risk, maximizing information density with zero filler. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (arbitrary code execution) and the lack of an output schema, the description does not mention the return value or error behavior. The example in the code parameter shows a return, but that's in the schema. For an advanced tool, this is a notable gap, but the core purpose and danger are clear. A 3 reflects the missing return semantics and operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with detailed descriptions, including the precedence rule for code vs filename. The tool description adds no additional parameter meaning beyond the schema, so a baseline of 3 is appropriate. The schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Run a Playwright code snippet.' It specifies the resource (Playwright code) and immediately flags the critical distinction from siblings with 'Unsafe: executes arbitrary JavaScript ... RCE-equivalent.' This unambiguous verb+resource plus the danger label leaves no ambiguity about what the tool does and separates it from all other browser tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a strong warning about safety ('Unsafe', 'RCE-equivalent') but does not explicitly state when to use it versus alternatives. It implies it's for advanced custom logic, but there is no direct 'use this only if...' or mention of safer alternatives. The warning serves as a caution but not a full usage guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select an option in a dropdown
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| values | Yes | Array of values to select in the dropdown. This can be a single value or multiple values. | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive=true, so the description does not contradict that. But the description adds no further behavioral detail (e.g., side effects on the page). With annotations present, the bar is lower, and the description is neutral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is well-structured and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema covers all parameters. The description is short but sufficient for a basic understanding. It does not specify whether values are labels or values, but that is a minor omission given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions for target and values. The tool description itself does not explain parameters beyond what the schema already provides, so it adds no extra semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (select) and the target (option in a dropdown), distinguishing it from more general actions like click or type. However, it does not explicitly contrast with sibling tools, so it misses a bit of distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when selecting is appropriate or when other actions (e.g., click, type) might be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture accessibility snapshot of the current page, this is better than screenshot
| Name | Required | Description | Default |
|---|---|---|---|
| boxes | No | Include each element's bounding box as [box=x,y,width,height] in the snapshot. Coordinates are viewport-relative, in CSS pixels (Element.getBoundingClientRect) | |
| depth | No | Limit the depth of the snapshot tree | |
| target | No | Exact target element reference from the page snapshot, or a unique element selector | |
| filename | No | Save snapshot to markdown file instead of returning it in the response. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds 'capture' but no further behavioral detail beyond what annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. The phrase 'this is better than screenshot' adds some comparative value but could be considered slightly extraneous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and the description does not explain what format the snapshot takes, how parameters like depth or target affect the result, or what kind of accessibility information is included. This leaves important context missing for an agent deciding whether and how to call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 4 parameters with descriptions, so the baseline is 3. The description does not add any additional parameter meaning or usage notes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear action ('capture') and object ('accessibility snapshot of the current page'), and distinguishes itself from screenshot with a comparative remark, though 'better than screenshot' is somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives minimal guidance by saying 'better than screenshot', but does not explicitly state when to use this tool over alternatives like browser_evaluate or browser_console_messages, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List, create, close, or select a browser tab.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to navigate to in the new tab, used for new. | |
| index | No | Tab index, used for close/select. If omitted for close, current tab is closed. | |
| action | Yes | Operation to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is known. However, the description adds no behavioral context beyond what the schema provides (e.g., index omission for close closes current tab is in schema). No mention of side effects like tab switching or browser-level changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists all supported actions. It is front-loaded with verbs and avoids unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has multiple actions and a required action parameter. The description lists the actions but does not explain action-specific requirements (e.g., URL required for new, index for close/select) or edge cases like closing the last tab. Given the schema covers parameter details, the description is adequate but not rich. With no output schema, the agent must infer return values from the action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter having a description (url, index, action with enum). The tool description adds no parameter-level detail, so it does not go beyond schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs (list, create, close, select) and a specific resource (browser tab). It distinguishes from siblings like browser_close (closes the entire browser) and browser_navigate (navigates current tab) by focusing on tab operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the list of actions but provides no explicit when-to-use guidance or exclusions. Given siblings like browser_close (closes the entire browser) and browser_navigate (navigates current tab), an agent might benefit from explicit differentiation, but the actions themselves are clear enough that usage is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a screenshot of the current page. You can't perform actions based on the screenshot, use browser_snapshot for actions.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Image format for the screenshot. If unset, inferred from the filename extension, otherwise png. | |
| scale | Yes | Image resolution scale. "css" produces a screenshot sized in CSS pixels (smaller, consistent across devices). "device" produces a high-resolution screenshot using device pixels (larger, accounts for the device pixel ratio). Default is css. | css |
| target | No | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element | |
| filename | No | File name to save the screenshot to. Defaults to `page-{timestamp}.{png|jpeg|webp}` if not specified. Prefer relative file names to stay within the output directory. | |
| fullPage | No | When true, takes a screenshot of the full scrollable page, instead of the currently visible viewport. Cannot be used with element screenshots. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds a key behavioral trait: the output is not interactive ('You can't perform actions based on the screenshot'), which is not captured by annotations. This adds meaningful context about the tool's limitations beyond the structured data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant phrasing. The core purpose is stated first, followed by a critical limitation and alternative, maximizing informativeness per word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only screenshot tool with comprehensive schema documentation and safety annotations, the description covers the essential decision points: when to use it and when not to. It doesn't explain return formats or error handling, but those are less critical given the tool's simplicity and the annotations' coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with detailed descriptions for all 6 parameters. The description adds no parameter-specific information, and the baseline of 3 is appropriate since the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Take') and resource ('screenshot of the current page'). Explicitly distinguishes from browser_snapshot by stating what it is not for ('You can't perform actions based on the screenshot'), making it clear which tool to use for captures vs. interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-not-to-use guidance: 'You can't perform actions based on the screenshot' and directs to the alternative 'use browser_snapshot for actions'. This clearly routes an agent to the correct tool for interactive needs while implying this tool is for visual captures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into editable element
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to type into the element | |
| slowly | No | Whether to type one character at a time. Useful for triggering key handlers in the page. By default entire text is filled in at once. | |
| submit | No | Whether to submit entered text (press Enter after) | |
| target | Yes | Exact target element reference from the page snapshot, or a unique element selector | |
| element | No | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true and readOnlyHint=false already signal that this tool can modify state, so the description does not contradict that. However, the main description adds no additional behavioral context beyond the annotations, such as whether typing overwrites existing content or triggers page events. The parameter descriptions do mention key-handler triggering and Enter submission, but the main description itself stays shallow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or repetition. It front-loads the verb and object, making the tool's primary purpose immediately obvious.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with several closely related siblings (fill_form, press_key, click), the description is too thin to fully orient an agent. It lacks any mention of when typing is appropriate, how the target is resolved, or what side effects to expect, so the agent must rely on parameter descriptions and external context to make a confident choice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3 because the input schema already documents all five parameters. The main description, 'Type text into editable element,' adds no meaning beyond the schema's parameter descriptions, which already define text, slowly, submit, target, and element clearly enough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Type text') and a clear target ('editable element'), which distinguishes it from many sibling tools at a high level. It is slightly vague about whether 'editable element' includes textareas, contenteditable regions, or only input fields, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to prefer this tool over sibling tools such as browser_fill_form or browser_press_key. It does not mention exclusions, prerequisites, or scenarios where typing would be inappropriate, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for text to appear or disappear or a specified time to pass
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | The text to wait for | |
| time | No | The time to wait in seconds | |
| textGone | No | The text to wait for to disappear |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral detail beyond the readOnlyHint by explaining that it waits for text appearance/disappearance or a time delay. However, it does not specify what happens if multiple parameters are provided or if none are provided, so behavior is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and conditions. It contains no unnecessary words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple wait tool with no output schema, the description covers the main use cases, but it omits edge cases such as default behavior when no parameters are supplied, timeout behavior, or error conditions. These gaps make it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions already cover each parameter individually, and the tool description mostly restates them. It does not clarify the relationship between text, textGone, and time (e.g., whether they are mutually exclusive or combinable), so minimal semantic value is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool waits for a condition: text to appear, text to disappear, or a specified time to pass. This distinguishes it from sibling tools like click, navigate, or type, and its purpose is immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when waiting for page state or a delay), but it does not explicitly state when to prefer this over alternatives or how to choose among text, textGone, and time parameters. It provides functional guidance but lacks explicit usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.0.79browser_clickbrowser_closebrowser_console_messagesbrowser_dragbrowser_dropbrowser_evaluatebrowser_file_uploadbrowser_fill_formbrowser_findbrowser_handle_dialogbrowser_hoverbrowser_navigatebrowser_navigate_backbrowser_network_requestbrowser_network_requestsbrowser_press_keybrowser_resizebrowser_run_code_unsafebrowser_select_optionbrowser_snapshotbrowser_tabsbrowser_take_screenshotbrowser_typebrowser_wait_forScored across 24 tools
Each tool has a clearly distinct purpose, covering actions like navigation, clicking, typing, screenshots, network requests, file upload, and dialog handling. Even similar tools like browser_snapshot and browser_take_screenshot are differentiated by their intended use (actions vs. visual capture).
All tools share the 'browser_' prefix, and most follow a verb_noun or verb pattern (e.g., browser_click, browser_fill_form). However, a few are noun-based (e.g., browser_network_requests, browser_tabs) which breaks the verb-first convention slightly, but the overall pattern remains predictable.
With 24 tools, the set is extensive but well-scoped for a full browser automation server. Each tool addresses a specific operation, and the count is appropriate for the domain, though it borders on the heavier side.
The toolset covers core browser automation workflows: navigation, clicks, forms, network, screenshots, accessibility, dialogs, file upload, and tabs. Minor gaps exist (e.g., no direct tool for scrolling or getting current URL), but these do not significantly hinder common agent tasks.
E2LLM gives your AI eyes and hands in a real browser: structured perception (SiFR) plus action.
Official Browserless MCP server: browser automation, scraping, screenshots and PDFs for AI agents.
Control a real browser from AI agents: navigate, click, type, screenshot, read the page.
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.