一个模型上下文协议 (MLM) 服务器，利用 BrowserCat 的云浏览器服务提供浏览器自动化功能。该服务器使 LLM 能够在真实的浏览器环境中与网页交互、截取屏幕截图并执行 JavaScript，而无需在本地安装浏览器。
browsercat_navigate
导航到浏览器中的任意 URL
输入： url （字符串）
browsercat_screenshot
捕获整个页面或特定元素的屏幕截图
输入：
name （字符串，必需）：屏幕截图的名称
selector （字符串，可选）：要截图的元素的 CSS 选择器
width （数字，可选，默认值：800）：屏幕截图宽度
height （数字，可选，默认值：600）：屏幕截图高度
browsercat_click
点击页面上的元素
输入： selector （字符串）：要点击元素的 CSS 选择器
browsercat_hover
悬停页面上的元素
输入： selector （字符串）：用于悬停元素的 CSS 选择器
browsercat_fill
填写输入字段
输入：
selector （字符串）：输入字段的 CSS 选择器
value （字符串）：要填充的值
browsercat_select
从下拉菜单中选择一个选项
输入：
selector （字符串）：选择元素的 CSS 选择器
value （字符串）：要选择的值
browsercat_evaluate
在浏览器控制台中执行 JavaScript
输入： script （字符串）：要执行的 JavaScript 代码
服务器提供两种类型资源的访问：
控制台日志（ console://logs ）
浏览器控制台以文本格式输出
包括来自浏览器的所有控制台消息
屏幕截图（ screenshot://<name> ）
截图的 PNG 图像
可通过捕获期间指定的屏幕截图名称访问
Related MCP server: Puppeteer MCP Server
基于云的浏览器自动化
无需安装本地浏览器
控制台日志监控
截图功能
JavaScript 执行
基本网络交互（导航、点击、表单填写）
BrowserCat MCP 服务器需要以下环境变量：
BROWSERCAT_API_KEY ：您的 BrowserCat API 密钥（必需）。您可以从https://browsercat.xyz/mcp免费获取。
{
"mcpServers": {
"browsercat": {
"command": "npx",
"args": ["-y", "@browsercatco/mcp-server"],
"env": {
"BROWSERCAT_API_KEY": "your-api-key-here"
}
}
}
}此 MCP 服务器采用 MIT 许可证。这意味着您可以自由使用、修改和分发该软件，但须遵守 MIT 许可证的条款和条件。更多详情，请参阅项目仓库中的 LICENSE 文件。
Click an element on the page
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for element to click |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It does not disclose any behavioral details such as waiting, scrolling, error handling, or side effects.
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?
Extremely concise single sentence with no extraneous words. However, it may be too minimal, lacking 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 simplicity (1 param, no output schema), the description is incomplete. It does not explain return values, errors, or interaction 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 100% schema coverage, the schema already documents the selector parameter clearly. Description adds no additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (click) and the target (element on the page). It is distinct from sibling tools like fill, hover, navigate, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use click versus alternatives like hover or evaluate. The description does not provide context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute JavaScript in the browser console
| Name | Required | Description | Default |
|---|---|---|---|
| script | Yes | JavaScript code to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits such as whether the script can modify the DOM, access cookies, survive navigation, or require specific permissions. With no annotations, the burden on the description is high, and it fails to meet it.
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 unnecessary words. It is appropriately front-loaded for quick understanding.
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 is a JavaScript execution tool with no output schema and no annotations, the description is too minimal. It omits critical information like return values, error handling, and side effects, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameter is already documented. The description adds minor context ('in the browser console') beyond the parameter label, but does not explain syntax, format, or execution context in detail.
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 ('Execute JavaScript') and the target ('in the browser console'). It is specific and distinct from sibling tools like clicking or navigating, though it does not explicitly differentiate itself.
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. There is no mention of context, prerequisites, or limitations compared to other browser automation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill out an input field
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for input field | |
| value | Yes | Value to fill |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral details beyond the action-name. It does not mention whether the field is cleared first, if events are triggered, or error handling. With no annotations, 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?
The description is extremely concise with one sentence, which is appropriate for a simple action. No unnecessary words, but could benefit from slightly more structure (e.g., stating the effect).
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 covers the bare minimum. However, it lacks context on what happens on success/failure, and its behavioral impact (e.g., triggering events). Incomplete for a fully autonomous agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters already have descriptions. The tool description adds no new meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Fill out') and the target ('input field'), which distinguishes it from sibling tools like click, hover, navigate, etc. 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?
No guidance on when to use this tool versus alternatives (e.g., when to fill vs. click or select). The description does not mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hover over an element on the page
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for element to hover |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden but only states the basic action. It fails to mention key behaviors like whether it waits for hover effects, returns any result, or handles errors for invisible elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core action. However, its brevity sacrifices completeness, especially in behavioral and contextual aspects.
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 (1 param, no output schema), the description is incomplete. It omits details about post-hover state, potential side effects, and error handling, which are critical for reliable agent 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 sole parameter 'selector' is fully described in the schema (100% coverage). The description adds no additional meaning beyond the schema, so it meets the baseline but provides no extra insight.
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 resource (element on the page), making the purpose unambiguous. However, it does not differentiate from sibling tools like browsercat_click or browsercat_select, which could lead to confusion.
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 hover versus other actions (e.g., click, select). The description lacks context about triggers for hover events or alternatives, leaving the agent without decision support.
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 or a specific element
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name for the screenshot | |
| selector | No | CSS selector for element to screenshot | |
| width | No | Width in pixels (default: 800) | |
| height | No | Height in pixels (default: 600) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the basic behavior (taking a screenshot) but lacks details about side effects, output format, or file handling. The behavior is minimally 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?
A single, clear sentence with no unnecessary words. Every part contributes to understanding the core functionality.
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 4 parameters and no output schema, the description is adequate but incomplete. It explains the main function and hints at element selection, but omits details about return values, error handling, and default behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters have schema descriptions (100% coverage). The description adds context by implying two modes (whole page vs. element), but the schema already describes the selector parameter. The added value is moderate.
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 'Take a screenshot of the current page or a specific element' clearly states the action and resource, distinguishing it from sibling tools like click, navigate, etc. However, it does not explicitly differentiate when to use this tool versus others beyond the action itself.
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 or avoid this tool, nor are any alternatives mentioned. The description simply states what the tool does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select an option from a dropdown menu
| Name | Required | Description | Default |
|---|---|---|---|
| selector | Yes | CSS selector for select element | |
| value | Yes | Value to select |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility, but it only states the basic action. It does not mention behavior like triggering change events, handling visibility, or what happens if the option is not found.
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 fluff. It is appropriately brief and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more context, such as whether 'value' refers to the option's text or value attribute, or how to handle dynamic dropdowns. It is incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters are described. The tool description does not add any extra meaning beyond what the schema provides, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Select' and the resource 'option from a dropdown menu', making the tool's purpose immediately obvious. It distinguishes itself from siblings like browsercat_click or browsercat_fill.
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 instead of alternatives, such as using browsercat_click for non-select elements or when a dropdown is not involved. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0browsercat_clickbrowsercat_evaluatebrowsercat_fillbrowsercat_hoverbrowsercat_navigatebrowsercat_screenshotbrowsercat_selectScored across 7 tools
Each tool has a clearly distinct purpose with no overlap: click, evaluate, fill, hover, navigate, screenshot, and select target specific browser automation actions. An agent can easily distinguish between them based on their unique functions.
All tools follow a consistent 'browsercat_verb' pattern with snake_case, using descriptive verbs like click, evaluate, fill, hover, navigate, screenshot, and select. This predictable naming makes the set easy to understand and use.
With 7 tools, this server is well-scoped for browser automation, covering essential actions like navigation, interaction, and capture. Each tool earns its place without feeling too sparse or bloated for the domain.
The toolset covers core browser automation workflows including navigation, element interaction, and screenshot capture. Minor gaps exist, such as missing tools for scrolling, waiting, or handling alerts, but agents can work around these with the provided tools.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Provides cloud browser automation capabilities using Stagehand and Browserbase, enabling LLMs to i…
A Model Context Protocol server for Wix AI tools
Undetectable cloud browser sessions for AI agents and scrapers. Navigate, extract, click, captcha.