Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@browser-mcp open google.com and search for MCP"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
将浏览器自动化框架封装为标准 MCP Server，使 AI 编程工具（Cursor、Windsurf、Cline/Roo Code）能通过 MCP 协议调用浏览器能力。
分享文档：
English: docs/usage-guide-en.md
提供四个 MCP Tool：
工具 | 功能 |
| 在持久页面上执行简化自然语言操作，支持多轮互动 |
| 提取网页结构化 UI 信息（清洗后的 DOM + 无障碍树） |
| 嗅探页面网络 API 请求与响应 |
| 获取页面全页截图（Base64 编码） |
核心特性：
默认优先使用浏览器 CDP 可见模式（自动探测 9222）
支持 stdio 和 SSE 双传输模式
Docker 容器化一键部署
会话持久化（跨调用保持登录状态）
playwright-stealth 反检测集成
上下文压缩（控制返回数据量，避免超出 AI 上下文窗口）
Related MCP server: Browser Automation MCP
# 克隆项目
git clone <repo-url>
cd browser-use-mcp-server
# 启动服务（SSE 模式，监听 8000 端口）
docker-compose up -d
# 查看日志
docker-compose logs -f容器启动后会自动检测 Chromium 浏览器是否可用，检测通过后以 SSE 模式启动 MCP Server。
如果本机 Chrome 已用 --remote-debugging-port=9222 启动，服务会默认接管该可见浏览器。
# 安装依赖
pip install -e '.[dev]'
# 安装 Playwright 浏览器
playwright install chromium
# 以 stdio 模式启动（默认）
python -m src
# 或以 SSE 模式启动
MCP_TRANSPORT=sse python -m src适用于本地 IDE 直接集成。IDE 以子进程方式启动 MCP Server，通过标准输入输出通信。
python -m src
# 默认 MCP_TRANSPORT=stdio适用于 Docker 部署或远程访问。MCP Server 启动 HTTP 服务，通过 Server-Sent Events 通信。
MCP_TRANSPORT=sse MCP_PORT=8000 python -m src
# SSE 端点: http://localhost:8000/sse默认会优先自动探测 127.0.0.1:9222 和 host.docker.internal:9222 的 CDP 端口。
如果需要手动指定，可设置 MCP_CDP_ENDPOINT。
将以下内容添加到 Cursor 的 MCP 配置中（参考 configs/cursor_mcp.json）：
stdio 模式（本地运行）：
{
"mcpServers": {
"browser-use-mcp-server": {
"command": "python",
"args": ["-m", "src"],
"env": {
"MCP_TRANSPORT": "stdio"
}
}
}
}SSE 模式（连接 Docker 容器）：
{
"mcpServers": {
"browser-use-mcp-server-sse": {
"url": "http://localhost:8000/sse"
}
}
}参考 configs/windsurf_mcp_config.json：
stdio 模式：
{
"mcpServers": {
"browser-use-mcp-server": {
"command": "python",
"args": ["-m", "src"],
"env": {
"MCP_TRANSPORT": "stdio"
}
}
}
}SSE 模式：
{
"mcpServers": {
"browser-use-mcp-server-sse": {
"serverUrl": "http://localhost:8000/sse"
}
}
}参考 configs/cline_mcp.json：
stdio 模式：
{
"mcpServers": {
"browser-use-mcp-server": {
"command": "python",
"args": ["-m", "src"],
"env": {
"MCP_TRANSPORT": "stdio"
}
}
}
}SSE 模式：
{
"mcpServers": {
"browser-use-mcp-server-sse": {
"url": "http://localhost:8000/sse"
}
}
}变量名 | 说明 | 默认值 |
| 传输模式： | 本地: |
| 监听地址（SSE 模式） |
|
| 监听端口（SSE 模式） |
|
| 日志级别 |
|
| 会话存储路径 | 本地: |
| 默认超时时间（秒） |
|
| 默认最大 Token 数 |
|
| CDP 地址，默认 |
|
新增 browser_action tool，适合 MCP 多轮互动。默认 session_id="default"，会持续复用同一个页面。
示例：
{"instruction":"打开网址 baidu.com"}{"instruction":"搜索A股行情，打开第二个网址"}返回示例：
{
"success": true,
"message": "Browser action executed successfully",
"session_id": "default",
"actions": ["searched A股行情", "opened result 2"],
"page_title": "...",
"current_url": "..."
}提取网页结构化 UI 信息，包括清洗后的 DOM 和无障碍树。
参数：
参数 | 类型 | 必填 | 说明 |
| string | 是 | 目标 URL |
| string | 否 | 页面交互指令（如点击、滚动等） |
| string | 否 | CSS 选择器，限定提取范围 |
| bool | 否 | 是否启用 CSS 还原（默认 false） |
| string | 否 | 会话 ID，用于跨调用保持状态 |
| int | 否 | 超时秒数（默认 120） |
| int | 否 | 最大 Token 数（默认 8000） |
返回格式：
{
"cleaned_html": "<div>...</div>",
"accessibility_tree": "...",
"page_title": "页面标题",
"current_url": "https://example.com",
"estimated_tokens": 3500,
"truncated": false
}嗅探页面网络 API 请求与响应，自动过滤静态资源，仅保留 XHR/Fetch 数据接口。
参数：
参数 | 类型 | 必填 | 说明 |
| string | 是 | 目标 URL |
| string | 是 | 页面交互指令（触发 API 调用） |
| string | 否 | 会话 ID |
| int | 否 | 超时秒数（默认 120） |
| int | 否 | 最大 Token 数（默认 8000） |
返回格式：
{
"api_calls": [
{
"url": "https://api.example.com/data",
"method": "GET",
"request_payload": null,
"response_body": {"key": "value"},
"status_code": 200,
"truncated": false
}
],
"estimated_tokens": 1200,
"truncated": false
}注：单个 API 响应体超过 50KB 时会被截断，
truncated标记为true。
获取页面全页截图，以 Base64 编码返回，适用于多模态 AI 视觉核对。
参数：
参数 | 类型 | 必填 | 说明 |
| string | 是 | 目标 URL |
| string | 否 | 页面交互指令 |
| string | 否 | 会话 ID |
| int | 否 | 超时秒数（默认 120） |
返回格式：
{
"screenshot_base64": "iVBORw0KGgo...",
"page_title": "页面标题",
"current_url": "https://example.com"
}所有工具在异常情况下返回统一的错误结构：
{
"error": true,
"error_type": "timeout | navigation | blocked | internal",
"error_message": "错误描述",
"blocked": false,
"screenshot_base64": null,
"partial_result": null
}navigation：URL 无法访问、DNS 解析失败
timeout：操作超时，partial_result 中包含已完成的部分数据
blocked：被反爬拦截，screenshot_base64 中包含拦截页面截图
internal：服务内部异常
# 安装开发依赖
pip install -e '.[dev]'
# 运行测试
pytest
# 运行测试（含覆盖率）
pytest --cov=src
# 仅运行属性测试
pytest tests/test_*_properties.pybrowser-use-mcp-server/
├── src/
│ ├── __main__.py # 启动入口
│ ├── server.py # MCP Server，Tool 注册与传输配置
│ ├── config.py # 配置管理（环境变量）
│ ├── models.py # 核心数据结构
│ ├── tools/ # 三个 MCP Tool 实现
│ │ ├── map_and_extract_ui.py
│ │ ├── intercept_network_api.py
│ │ └── visual_inspect.py
│ └── services/ # 共享服务模块
│ ├── session_manager.py
│ ├── dom_cleaner.py
│ ├── context_compressor.py
│ └── stealth.py
├── configs/ # IDE 配置示例
├── Dockerfile
├── docker-compose.yml
├── pyproject.toml
└── tests/MIT
Call a raw Chrome DevTools Protocol method. params are passed as kwargs.
| Name | Required | Description | Default |
|---|---|---|---|
| method | Yes | ||
| params | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. It discloses the action ('Call') but not side effects, validation behavior, possible errors, authentication needs, or response format. Calling a raw CDP method can mutate browser state, but the description does not warn about this.
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 filler. The main purpose is front-loaded, and the note about `params` as kwargs is directly relevant and compact.
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?
Although the input schema is simple, the absence of annotations, output schema, and usage context makes the description thin. It does not explain return values, errors, or when this raw tool should be preferred over the dedicated sibling tools, so the agent is left under-informed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds one useful semantic detail: `params` are passed as keyword arguments. However, it provides no guidance on `method` values, how to construct params, or the relationship between the two, leaving meaningful gaps.
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 specifies the exact verb ('Call') and resource ('raw Chrome DevTools Protocol method'), and the word 'raw' clearly distinguishes it from the high-level sibling tools like browser_click or browser_navigate. An agent can immediately understand this is a low-level passthrough rather than a convenience operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given for when to use this tool versus the many provided browser helpers. There is no mention of 'use this when no high-level tool exists' or any warning about when it is inappropriate, leaving 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.
Click at screen coordinates (x, y). button is 'left'/'right'/'middle'.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | ||
| y | Yes | ||
| button | No | left | |
| clicks | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose the core action and button options. However, it never clarifies the coordinate system (viewport vs. page, device vs. CSS pixels), the side effects of clicking (navigation, form submission), or the behavior of the `clicks` parameter, leaving meaningful ambiguity for a mutating 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?
Two short sentences, action first, with no wasted words. It is appropriately front-loaded, though it is lean enough to omit the `clicks` parameter entirely, which a slightly expanded description could have covered without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (4 params, no output schema), so the description only needs to enable a correct basic call — which it does for x/y and button. But since there are no annotations and no output schema, the description is the sole behavioral source, and its silence on `clicks` semantics and the coordinate-system meaning leaves gaps an agent could trip on.
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 0%, so the description must compensate; it does add meaning to x/y ('screen coordinates') and to `button` (left/right/middle). But `clicks`, an integer parameter with default 1, is never explained — the agent cannot tell whether it means double-click or repeat count — and no ranges or pixel semantics are given for x/y.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource — 'Click at screen coordinates (x, y)' — which is unambiguous and tells the agent this is a coordinate-based mouse action rather than an element- or key-based one. It also adds meaning to `button` by enumerating 'left'/'right'/'middle'. It stops short of a 5 because it never names sibling tools (e.g., browser_js or browser_press) to explicitly carve out its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to choose this tool over alternatives: browser_js/browser_cdp can trigger clicks programmatically, browser_press handles key presses, and browser_fill targets form fields, yet none of these routing decisions are addressed. There are no prerequisites, exclusions, or context hints, so the agent gets no information beyond the tool's own name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close a tab. Without target, closes the active tab.
| Name | Required | Description | Default |
|---|---|---|---|
| target | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the destructive action and the active-tab default, but it does not explain whether closing is reversible, what happens if it is the last tab, or what response the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The main action and the default behavior are stated directly and concisely, with the most important conditional behavior front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The default invocation is fully described and the operation is simple. However, for non-default usage with a target, the agent is left guessing about the target value's format, and with no output schema there is no stated expectation of return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage for target, the description must compensate. It adds meaning by explaining the null case ('closes the active tab'), but it does not define what a string target value should be or where to obtain it, such as a tab ID.
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 the exact verb and resource: 'Close a tab.' It immediately clarifies the default behavior ('Without target, closes the active tab'), which also distinguishes it from tab-creation and navigation siblings like browser_new_tab and browser_switch_tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear invocation context by explaining what happens when target is omitted. It does not explicitly name alternatives or when-not-to-use conditions, but the intended usage is unambiguous for this simple operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the active tab's targetId, url and title.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states what is returned, but does not mention potential side effects (likely none) or error conditions (e.g., no active tab). For a simple read operation this is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the tool's purpose. There is no unnecessary information, and the key output fields are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no parameters, no output schema), the description provides enough information: it lists the three return fields. It does not elaborate on types or edge cases, but for a straightforward getter, 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?
The tool has zero parameters, and the baseline for such cases is 4. The description does not need to explain parameters, and the schema is already empty. No additional parameter semantics are required.
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 (Return) and the resource (the active tab's targetId, url, title). It is specific and distinct from siblings like browser_list_tabs (lists all tabs) and browser_page_info (likely more detailed page info). The 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 usage when you need current tab metadata, but it does not explicitly state when to prefer this over alternatives or when not to use it. No exclusions or alternative references are provided, though the context of 'active tab' makes the primary use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch to a real (non-internal) tab if the current one is chrome:// or stale.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly discloses the conditional tab switch, but leaves 'stale' undefined and does not explain what happens if no real tab exists or how the replacement tab is chosen. Core behavior is stated, but side-effect details are thin.
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 sentence carries the action, target, and trigger condition with no filler. It is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema utility, the description supplies the key context: when to run it and what it accomplishes. Slight ambiguity in 'stale' is the only notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics for the description to add. The 100% schema coverage makes this trivially complete, and the baseline of 4 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 uses a specific verb ('Switch') with a clear resource ('real (non-internal) tab') and an explicit condition ('if the current one is chrome:// or stale'). This distinguishes it from browser_switch_tab and other navigation tools. The purpose is immediately obvious.
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 states exactly when to invoke the tool: when the current tab is an internal chrome:// page or is stale. It does not name alternatives or state when not to use it, so it falls short of a full 5, but the trigger condition is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill an input matched by selector with text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| selector | Yes | ||
| clear_first | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the basic fill operation but does not mention side effects (e.g., clearing the field, triggering events), behavior on missing selectors, or whether it replaces existing text. The clear_first parameter is not mentioned, so the agent is unaware of the default clearing behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no fluff. It is front-loaded with the action and key parameters. However, it could be slightly more structured to include parameter details without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description is still incomplete. It lacks information about the optional clear_first parameter, error handling, and differentiation from siblings like browser_type. With no output schema and no annotations, the agent has insufficient context to call the tool reliably.
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 has 0% description coverage, so the description must compensate. It explains selector and text implicitly but omits clear_first entirely. It also does not specify selector syntax (CSS, XPath) or any constraints on text. This leaves a required parameter undocumented in any form.
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 (fill), the resource (an input matched by selector), and the payload (text). It is a specific verb+resource but does not distinguish from sibling browser_type, which might also interact with inputs. Still, the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like browser_type. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Navigate the current tab to url. Returns the navigation result.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'Returns the navigation result' but provides no details on whether it waits for page load, error handling, or side effects like history updates. The tool mutates state (navigation), yet the description gives no safety or blocking information. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action and the return value efficiently. 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?
Given the tool's complexity (simple navigation) and lack of annotations and output schema, the description is inadequate. It omits critical details like whether navigation blocks until page load, what the 'navigation result' contains, and how errors are surfaced. The existence of sibling browser_wait_for_load suggests this tool may not wait, but that's not clarified. An agent would need more context to use it reliably.
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 0%, so the description must compensate. It says 'Navigate the current tab to `url`', which adds that the parameter is the destination. However, this is essentially restating the parameter name and adds no format, constraints, or examples. The description barely adds meaning beyond the parameter name itself.
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 ('Navigate') on a specific resource ('current tab') and specifies the target as 'url'. This distinguishes it from siblings like browser_new_tab (which opens a new tab) and browser_switch_tab (which changes focus). No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for navigating the current tab to a URL, but does not explicitly state when to prefer it over alternatives (e.g., browser_new_tab, browser_switch_tab). There is no exclusion or guidance on when not to use it, leaving the agent to infer based on the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
HTTP GET url (browser-less). Returns the response body. Optional
headers dict for authentication or custom request headers.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| headers | No | ||
| timeout | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden, and it does disclose the key trait: the request is browser-less and returns the response body. It could go further by noting redirect/error-handling or non-rendering behavior, but for a simple GET tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no filler. The core action and key behavioral distinction are front-loaded, and the optional headers purpose is stated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with only three scalar parameters and no output schema, the description covers the URL, browser-less nature, return value, and header usage. Timeout behavior such as redirects/status handling is not described, but the schema default covers the only remaining parameter and an agent can call this successfully.
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 0%, so the description must compensate, and it does add meaning for `headers` ('for authentication or custom request headers'). However, it never mentions the `timeout` parameter, whose meaning is left entirely to its schema name and default value, so the compensation is partial.
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 opens with a specific action and resource: 'HTTP GET `url`', immediately followed by the qualifier 'browser-less' that separates it from the browser-navigation siblings. It also states the return value, so an agent can distinguish this raw HTTP fetch tool from browser_goto or browser_page_info without opening the schema.
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 'browser-less' qualifier gives clear context that this tool should be used for direct HTTP requests rather than through the browser automation flow. It does not explicitly name sibling alternatives or state when not to use it, but that is not a major gap given the sibling list makes the distinction obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate a JavaScript expression in the current tab (or an iframe target_id).
| Name | Required | Description | Default |
|---|---|---|---|
| target_id | No | ||
| expression | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of disclosing behavior. It says the expression is evaluated but does not mention that JavaScript can mutate the page, whether a result is returned, how asynchronous expressions are handled, or what errors may surface. For an arbitrary-JS-execution tool this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence with no filler. It front-loads the core operation and handles the iframe variant in a parenthetical, with every word earning 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?
With no annotationsaint, no output schema, and incomplete parameter semantics, the description is too sparse for an eval tool. It omits the return behavior, constraints on expressions, and the exact meaning of `target_id`. An agent could call it safely only by guessing at these important 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?
Schema description coverage is 0%, so the description must compensate. It adds that `target_id` refers to an iframe, but it does not clarify whether `target_id` is an id, a selector, or a frame reference, nor does it explain how `expression` results are returned or formatted. The addition is marginal beyond the schema's own property titles.
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 ('Evaluate') and a clear resource ('a JavaScript expression in the current tab'), with an explicit iframe variant via `target_id`. This distinguishes the tool from browser-level sibling tools such as browser_goto or browser_cdp.
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 clearly scopes the tool to the current tab and identifies the iframe condition via `target_id`. It does not explicitly name alternatives or when not to use it, but the intended context is clear enough for an agent to select it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List open page tabs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry behavioral disclosure. 'List' conveys a read-only operation with no side effects, but it does not describe the return shape or whether the current tab is identified. More detail would reduce ambiguity.
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 four-word sentence states the operation with no filler. It is front-loaded and easily parsed by an agent.
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 zero-parameter, non-destructive list operation, the description is largely complete for invocation. The lack of an output schema means a note on return format (e.g., tab IDs/titles, active tab) would be a minor improvement, but nothing necessary to call the tool 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?
The tool has zero parameters, so the description has no parameter burden. The baseline of 4 applies because there is nothing to document beyond the already-complete empty 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 uses a specific verb ('List') and a clear resource ('open page tabs'), making the operation unambiguous. The plural phrasing distinguishes it from sibling tools like browser_current_tab and browser_switch_tab, even without naming them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: call it when a list of all open tabs is needed. However, it gives no explicit guidance about when to prefer browser_current_tab or browser_switch_tab, or any exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a new browser tab. Returns the new tab's targetId.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | about:blank |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It states the return value (targetId) but does not explain whether the new tab becomes active, whether it opens in the background, what happens with invalid URLs, or any side effects on the current tab. For a tool with no annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, direct sentence with no filler. The key action and return value are front-loaded. Optimal length for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is simple (one optional parameter, no output schema, no annotations), the description is minimally adequate. It states the action and the return. However, it lacks context on how the new tab interacts with the existing browsing session (e.g., does it become active? is it added to the tab list?). For an agent that needs to manage multiple tabs, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% – the 'url' parameter has no description in the schema. The description does not mention the parameter at all, leaving the agent to infer that 'url' is the address to open. Since it is optional and defaults to 'about:blank', the agent might not know the meaning or format expected. The description adds no value 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 specific verb 'Open' and resource 'a new browser tab'. Clearly distinguishes from sibling tools like browser_goto (which navigates existing tab) and browser_switch_tab (which switches to an existing tab). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for creating a new tab, but does not explicitly state when to use it versus alternatives (e.g., when you want to keep the current tab intact). It does not mention that this is the tool to use for a fresh browsing context or that it should be used when you need a separate targetId for later operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return current tab metadata: url, title, viewport and scroll sizes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of disclosing side effects. It correctly implies a read-only operation but does not explicitly state that it makes no changes to the page or that it may fail if no tab is loaded. It only lists return fields without addressing error handling or edge cases, but for a simple metadata fetch the essential behavior is conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero filler. The purpose and returned data are in the first clause, making it immediately scannable. 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?
Given the tool's simplicity (no parameters, no output schema), the description sufficiently covers what an agent needs to call it: it names the exact data items returned. It does not specify the output structure (e.g., nested vs flat), but that is a minor gap for a metadata retrieval tool, and the listed fields imply a clear contract.
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 schema coverage is trivially 100%. The description correctly adds no parameter information because there is nothing to document. Per the rubric, a zero-parameter tool earns a baseline of 4, and the description does not detract from that.
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 ('Return') and the target ('current tab metadata'), and enumerates the specific data fields it provides (url, title, viewport, scroll sizes). This unambiguously differentiates it from sibling tools like browser_screenshot or browser_list_tabs, which serve different purposes.
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 timing or alternative-selection guidance. It does not mention when to prefer this over browser_current_tab, browser_list_tabs, or any other sibling, nor does it state any prerequisites (e.g., an open tab). An agent must infer its use case solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Press a key. modifiers is a bitfield: 1=Alt, 2=Ctrl, 4=Meta, 8=Shift.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| modifiers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral implications, but it only says 'Press a key' and defines modifiers. It does not state that the key press targets the focused element, may trigger navigation or shortcuts, or whether it waits for resulting page 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 extremely concise, leads with the core action, and every word is informative. 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?
For a tool with no annotations and no output schema, this description is too thin. It lacks usage context, key-value guidance, and behavioral expectations, leaving an agent to guess at critical details for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It fully explains the modifiers bitfield values (1=Alt, 2=Ctrl, 4=Meta, 8=Shift), which is valuable, but it does not specify accepted key strings or syntax for the required key parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Press a key' clearly identifies the action as a keyboard key press, which distinguishes it from siblings like click, type, and fill at a basic level. However, it does not explicitly state that it acts on the current page or name alternatives, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided; the description never mentions alternatives like browser_type or browser_click. An agent must infer when browser_press is appropriate instead of being told.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a PNG screenshot. If path is omitted, a temp file is used.
Set max_dim to downscale results larger than that dimension.
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | ||
| path | No | ||
| max_dim | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does add useful detail: the output is a PNG, a temp file is used when `path` is omitted, and `max_dim` downscales large results. However, it omits what `full` does, how the temp file path is returned, and whether the page must be loaded, so transparency is only partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler, front-loads the core action, and every sentence contributes useful 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?
There is no output schema and no annotations, so the description must explain return/behavior context. It does not clarify the `full` parameter, how the agent learns the temp file path, or what a successful call returns, leaving important operational details unspecified.
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 0%, so the description must compensate. It explains `path` and `max_dim`, but leaves `full` completely undocumented. This is meaningful but incomplete parameter guidance.
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 and resource: 'Capture a PNG screenshot.' This is specific enough to identify the tool's purpose among the browser_* siblings, though it does not explicitly contrast itself with other 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, nor any exclusions or prerequisites. The description focuses on parameter behavior rather than selection context, so an agent receives no help deciding when screenshotting is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scroll the wheel at (x, y) by dy vertical / dx horizontal pixels.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | ||
| y | Yes | ||
| dx | No | ||
| dy | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden. It does state the core behavior (scroll at a point by pixel deltas), but it does not clarify the coordinate system (viewport vs. page), scroll direction sign convention beyond pixel deltas, or what happens if coordinates are out of bounds. This is adequate but not rich.
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 entire description is one front-loaded sentence that states the action, location, and units without filler. Every clause adds operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter, no-output-schema action tool, the description covers the core invocation but leaves the coordinate basis and edge-case behavior implied. An agent might call it correctly in a common case, but would not know viewport semantics or whether the wheel event is relative to the current scroll position.
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 0%, so the description compensates by naming all four parameters and explaining their roles: x/y as the scroll position and dx/dy as horizontal/vertical pixel amounts. It stops short of describing coordinate space and defaults (already in schema), but it provides meaning the bare integer schema does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Scroll') and identifies the exact target ('wheel at (x, y)') plus the units of action (`dy` vertical / `dx` horizontal pixels). This makes the tool's function immediately distinguishable from the other browser action siblings such as browser_click or browser_js.
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 states what the tool does but gives no guidance on when to prefer it over alternatives or any prerequisites/context. There is no 'use when...' or 'for other scrolling behavior use...' note, so an agent must 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.
Start recording actions to a local directory.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| title | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states that recording starts and writes to a local directory, but does not explain what gets captured, how the recording session ends, whether existing recordings are overwritten, or what side effects occur.
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, but it is under-specified rather than efficiently complete. Key behavioral and parameter information is missing while the existing sentence could have been expanded without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and two undocumented optional parameters, the description leaves a state-changing recording workflow largely unexplained. It omits the lifecycle relationship with browser_stop_recording and the meaning of the parameters, making it incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the optional name and title parameters at all. An agent has no way to know what values to provide or how these parameters affect the recording, so the description adds no semantic value beyond the property names.
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 names a specific action (start recording) and target (local directory), distinguishing it from the browser interaction tools. It does not explicitly contrast with browser_stop_recording, but the start/stop pairing is inferable from the tool name and sibling list.
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 when-to-use guidance, alternatives, or prerequisites are provided. The description does not mention that this should be paired with browser_stop_recording or that a browser session should be active, so usage must be inferred entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the active recording and return its directory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the stop action and the return of a directory, but does not disclose side effects (e.g., whether the recording is saved, whether it is resumable, what happens if no active recording exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It states the action and the return value with zero 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 zero-parameter tool, the description is largely adequate: it states the action and return value. However, it does not mention whether an active recording is required or what happens if one is absent, leaving minor ambiguity in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema has 100% coverage of nothing, so the description adds no parameter semantics—but none are needed. The baseline of 4 applies because there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Stop') and resource ('active recording') and clearly distinguishes from the sibling tool browser_start_recording, which is the inverse action. It is unambiguous and tells an agent exactly what operation is performed.
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 wording implies the tool should be used when a recording is already active, likely after browser_start_recording, but it does not explicitly state prerequisites, exclusions, or alternatives. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch to tab by targetId or URL substring. Returns the sessionId.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the return value ('Returns the sessionId') but does not disclose what happens if the target is not found, whether the switch is synchronous, or whether the sessionId refers to the new tab's session. The behavior of matching by URL substring is ambiguous (e.g., case sensitivity, partial match).
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 target format. It earns its place by adding the URL substring option and the return value, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and a single parameter with 0% schema coverage, the description is too thin. It does not explain error behavior, how to obtain a targetId (e.g., via browser_list_tabs), or what the sessionId is used for. An agent would likely need to experiment or consult other tools to use this correctly.
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 0%, so the description must compensate. It does clarify that `target` can be a `targetId` or URL substring, which adds meaning beyond the bare schema. However, it does not explain how to distinguish a targetId from a URL substring, what format a targetId takes, or how the substring matching works.
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 ('Switch') and resource ('tab'), and identifies the two accepted target formats: `targetId` or URL substring. It clearly distinguishes this from sibling tools like browser_new_tab and browser_close_tab, though it doesn't explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when the agent needs to change the active tab and has a targetId or URL substring. However, it does not explicitly state when not to use it or mention alternatives like browser_list_tabs for finding the targetId or browser_current_tab for checking the active tab.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Insert text into the focused element.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. 'Insert text into the focused element' states the basic behavior but omits important behavioral traits such as whether it types keystrokes, appends at the cursor, clears existing content, or triggers input events. The term 'insert' is ambiguous relative to browser_fill.
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 redundant restatement of the tool name. It front-loads the action and target effectively and earns every 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 tool with no annotations, no output schema, and a large sibling set, more context is needed. It does not tell the agent about the required focused state, how to set that state, or how this differs from browser_fill and browser_press, so the description alone is incomplete.
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 0% and the only parameter is a string named 'text'. The description confirms the text is what gets inserted, adding a bit of meaning beyond the schema, but it offers no extra details like encoding, newline handling, or length limits. This is adequate, not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('insert text') and resource ('the focused element'), so the tool's core purpose is unambiguous. It does not explicitly contrast with sibling tools like browser_fill or browser_press, but 'focused element' is a distinguishing qualifier.
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 over browser_fill, browser_press, or browser_click. It also does not mention whether the element must already be focused or whether this tool focuses it first, leaving selection and sequencing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set files on a file input matched by selector. path is the local file.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | ||
| selector | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not state whether the file path must be absolute, whether the tool waits for the upload to complete, whether it triggers change events, or what happens if the selector does not match a file input. The description is minimal and leaves key behaviors unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It front-loads the action and resource. However, it is so brief that it sacrifices useful detail, which is a minor structural tradeoff.
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 no annotations, no output schema, and 0% schema description coverage, the description is too thin. An agent needs to know whether the path is local-only, whether the upload is synchronous, and what success/failure looks like. The sibling set includes many browser interaction tools, and this one lacks the context needed to use it reliably.
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 0%, so the description must compensate. It explains that `path` is 'the local file' and `selector` matches the file input, which adds some meaning beyond the bare schema. However, it does not clarify the expected format of `path` (absolute vs relative), whether it supports URLs, or the selector syntax (CSS vs XPath).
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 ('Set files') and resource ('a file input matched by `selector`'), which clearly distinguishes it from sibling tools like browser_click or browser_type. It could be slightly clearer that this is for uploading files via an <input type=file> element, 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 given on when to use this tool versus alternatives like browser_type or browser_fill. The description does not mention prerequisites (e.g., the page must be loaded, the input must be visible) or exclusions (e.g., not for drag-and-drop uploads). An agent must infer usage from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for seconds.
| Name | Required | Description | Default |
|---|---|---|---|
| seconds | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral transparency, but it only says 'Wait for seconds.' It does not disclose whether this blocks the page, whether it returns a value, or whether it has side effects. The behavior is implied but not elaborated.
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 with no filler. The essential information, the wait duration, is front-loaded and every word contributes to meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool, the description is minimally viable: an agent knows to wait for the given seconds. However, with no annotations, no output schema, and sibling tools that wait for specific conditions, the description leaves some context gaps about exact behavior and when to prefer this over alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats the parameter name 'seconds' and indicates it is the wait duration, which adds minimal semantic value. However, schema description coverage is 0%, and the description does not provide constraints like minimum/maximum values or behavior when the default is used.
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 operation: wait for a specified number of seconds. It distinguishes this as a time-based wait, but it does not explicitly differentiate itself from sibling tools like browser_wait_for_load or browser_wait_for_element, so it misses the top score.
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 a fixed delay vs. waiting for a load event or an element. There are no alternatives, conditions, or exclusions mentioned, leaving the choice of tool to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for an element matching selector to appear. Set visible=True to
also require it to be rendered.
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No | ||
| visible | No | ||
| selector | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It explains the visible toggle but omits what happens on timeout, whether it polls or uses events, and what a successful/failed wait returns or raises.
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 clean sentences with no filler. The core behavior is front-loaded and the visible nuance is added in the second sentence.
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 wait tool with no annotations and no output schema, the missing timeout outcome and return/error contract are significant. An agent cannot predict what happens if the element never appears, so the definition is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning for selector and visible, explaining that visible requires rendering. It leaves timeout with only a default value and no unit or behavior, so compensation for the schema gap is partial.
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 action: wait for an element matching a selector to appear, with an optional visibility requirement. It is clear about the resource, but does not explicitly contrast with sibling browser_wait or browser_wait_for_load.
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 described behavior implies when to use it: when an agent needs to block until an element exists (and optionally is visible). However, it gives no explicit guidance on choosing this over browser_wait or browser_wait_for_load, and no conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait until the current tab's readyState is 'complete'.
| Name | Required | Description | Default |
|---|---|---|---|
| timeout | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the wait condition but does not disclose what happens on timeout (error? return?), whether it polls or uses an event, whether it returns any value, or whether it blocks indefinitely. The timeout parameter is in the schema but the description doesn't explain its behavior (e.g., default 15 seconds, what happens when exceeded).
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 behavior. It earns its place with no filler, though it could have added a brief note about timeout behavior without becoming bloated.
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 one optional parameter and no output schema, the description is close to adequate, but the missing timeout semantics and lack of failure behavior leave an agent uncertain about edge cases. Given the sibling set includes browser_wait and browser_wait_for_element, a brief differentiation would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented 'timeout' parameter. The description does not mention the timeout parameter at all, leaving the agent to infer its units (seconds? milliseconds?) and behavior from the schema's default of 15. This is a clear gap.
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 ('Wait') and a precise condition (readyState is 'complete'), which clearly identifies the tool's function. It is distinguishable from siblings like browser_wait and browser_wait_for_element because it targets page load state rather than a fixed delay or element presence, though it doesn't explicitly name those alternatives.
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: call this after navigation to ensure the page has finished loading. However, it does not explicitly state when to use this versus browser_wait or browser_wait_for_element, nor does it mention that it may be unnecessary for some SPAs or that readyState 'complete' may not mean all resources are loaded. The context is clear but exclusions/alternatives are not stated.
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.1.0browser_cdpbrowser_clickbrowser_close_tabbrowser_current_tabbrowser_ensure_real_tabbrowser_fillbrowser_gotobrowser_http_getbrowser_jsbrowser_list_tabsbrowser_new_tabbrowser_page_infobrowser_pressbrowser_screenshotbrowser_scrollbrowser_start_recordingbrowser_stop_recordingbrowser_switch_tabbrowser_typebrowser_upload_filebrowser_waitbrowser_wait_for_elementbrowser_wait_for_loadScored across 23 tools
Most tools target distinct browser concerns—tabs, navigation, input, waiting, and screenshots—so an agent can usually pick the right one. The main overlaps are browser_type versus browser_fill for text entry and browser_current_tab versus browser_page_info for tab metadata, but their descriptions mostly clarify the intended use.
All tools share the browser_ prefix and use lowercase snake_case, creating a recognizable family pattern. However, not all names follow the verb_noun convention, with noun-phrase names like browser_page_info and browser_current_tab and bare abbreviations like browser_js and browser_cdp.
At 23 tools, the surface sits in the 16-25 range that feels heavy for an MCP server. Most tools earn their place, but a few niche or parallel helpers such as browser_ensure_real_tab, browser_http_get, and the recording pair could be considered auxiliary.
The toolset covers tab management, navigation, input actions, waiting, screenshots, uploads, JavaScript evaluation, and raw CDP access. Common browser operations like back, forward, reload, hover, and select are missing but can be worked around via browser_js or browser_cdp, so there are no blocking dead ends.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
Live browser debugging for AI assistants — DOM, console, network via MCP.
A paid remote MCP for AI agent browser approval MCP, built to return verdicts, receipts, usage logs,
