Supports targeting web page elements using CSS selectors for actions like screenshots, clicks, hover effects, and form interactions.
Enables execution of JavaScript code in a browser environment through the browsercat_evaluate tool, allowing interaction with web pages and manipulation of web content.
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., "@BrowserCat MCP Server (Browser Automation) take a screenshot of the homepage and name it 'homepage_screenshot'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server that provides browser automation capabilities using BrowserCat's cloud browser service. This server enables LLMs to interact with web pages, take screenshots, and execute JavaScript in a real browser environment without needing to install browsers locally.
browsercat_navigate
Navigate to any URL in the browser
Input: url (string)
browsercat_screenshot
Capture screenshots of the entire page or specific elements
Inputs:
name (string, required): Name for the screenshot
selector (string, optional): CSS selector for element to screenshot
width (number, optional, default: 800): Screenshot width
height (number, optional, default: 600): Screenshot height
browsercat_click
Click elements on the page
Input: selector (string): CSS selector for element to click
browsercat_hover
Hover elements on the page
Input: selector (string): CSS selector for element to hover
browsercat_fill
Fill out input fields
Inputs:
selector (string): CSS selector for input field
value (string): Value to fill
browsercat_select
Select an option from a dropdown menu
Inputs:
selector (string): CSS selector for select element
value (string): Value to select
browsercat_evaluate
Execute JavaScript in the browser console
Input: script (string): JavaScript code to execute
The server provides access to two types of resources:
Console Logs (console://logs)
Browser console output in text format
Includes all console messages from the browser
Screenshots (screenshot://<name>)
PNG images of captured screenshots
Accessible via the screenshot name specified during capture
Related MCP server: Puppeteer MCP Server
Cloud-based browser automation
No local browser installation required
Console log monitoring
Screenshot capabilities
JavaScript execution
Basic web interaction (navigation, clicking, form filling)
The BrowserCat MCP server requires the following environment variable:
BROWSERCAT_API_KEY: Your BrowserCat API key (required). You can get one for free at https://browsercat.xyz/mcp.
{
"mcpServers": {
"browsercat": {
"command": "npx",
"args": ["-y", "@browsercatco/mcp-server"],
"env": {
"BROWSERCAT_API_KEY": "your-api-key-here"
}
}
}
}This MCP server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.
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.