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 my Gmail and read the latest email from my boss"
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.
Browser MCP is an MCP server + Chrome extension that allows you to automate your browser using AI applications like VS Code, Claude, Cursor, and Windsurf.
Related MCP server: Browser MCP
⚡ Fast: Automation happens locally on your machine, resulting in better performance without network latency.
🔒 Private: Since automation happens locally, your browser activity stays on your device and isn't sent to remote servers.
👤 Logged In: Uses your existing browser profile, keeping you logged into all your services.
🥷🏼 Stealth: Avoids basic bot detection and CAPTCHAs by using your real browser fingerprint.
This repo builds and runs standalone. The internal monorepo packages the upstream
code depends on (@repo/* and @r2r/messaging) are reconstructed under
vendor/ and wired up through tsconfig.json path aliases, so no
private workspace packages are required.
npm install # installs deps and builds dist/ via the prepare hook
npm run build # (re)build dist/index.js
node dist/index.jsThe server communicates over stdio using the Model Context Protocol and opens a
WebSocket server on port 9009 that the Browser MCP Chrome extension connects
to. To use it with an MCP client, register the built binary — for example:
{
"mcpServers": {
"browsermcp": {
"command": "node",
"args": ["/absolute/path/to/dist/index.js"]
}
}
}After installing the Browser MCP Chrome extension, click its icon and press Connect on the tab you want to automate.
This repo contains all the core MCP code for Browser MCP. It was originally
developed inside a monorepo and depended on shared utils and types packages;
those have been vendored (see vendor/) so the project can be built
and run on its own.
Browser MCP was adapted from the Playwright MCP server in order to automate the user's browser rather than creating new browser instances. This allows using the user's existing browser profile to use logged-in sessions and avoid bot detection mechanisms that commonly block automated browser use.
Perform click on a web page
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Exact target element reference from the page snapshot | |
| element | Yes | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It simply states 'Perform click' without describing side effects, requirements, or potential outcomes such as page navigation. This is insufficient for an action that could trigger significant UI changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action. It contains no unnecessary words and is easy to parse, though it sacrifices depth for brevity. It earns its place by stating the tool's purpose clearly.
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?
Despite the simplicity of a click action, the description is incomplete. It fails to mention that a page snapshot is required, that clicking may cause navigation or other side effects, or any constraints. There is no output schema or annotations to compensate, leaving the description inadequately contextualized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (ref and element) with detailed descriptions, and schema description coverage is 100%. The description adds no additional parameter semantics, but the schema already provides the necessary meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'click' and identifies the resource as a web page, which clearly distinguishes it from sibling tools like browser_hover, browser_type, and browser_press_key. It unambiguously states the action and target.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites (e.g., needing a snapshot) or context in which clicking is appropriate, leaving the agent without useful decision-making information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the console logs from the browser
| 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 only states the action without revealing what format the logs are returned in, whether logs are cleared after retrieval, or any side effects. This is minimal and lacks behavioral nuance.
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 directly communicates the tool's purpose. Every word is necessary and there is no redundancy or filler. It is optimally concise.
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 with no parameters or output schema. The description states the core function but omits details about the return value (e.g., format, structure, or whether it represents an array of messages). While this may be acceptable for such a simple tool, the lack of return information leaves the description slightly 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?
The tool has zero parameters, and the input schema is empty with high coverage by definition. The baseline for zero parameters is 4. The description adds no extra parameter semantics, but none are required since there are no parameters to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the console logs from the browser'. It uses a specific verb and resource, and it is distinct from all sibling tools that handle navigation, interaction, or screenshots. This is a precise and unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving browser console logs, but it does not explicitly state when to use this tool versus others, nor does it mention any prerequisites or exclusions. Given the absence of alternative log-related tools, the intended context is somewhat implied but not formally stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Go back to the previous page
| 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 full responsibility for behavioral disclosure. It only states the core action without mentioning state-changing effects, error conditions (e.g., no previous page), or implications like page unload or form data loss. This is a navigation action that modifies browser state, so more transparency is needed.
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 or repetition. It gets straight to the point, which is ideal for such a simple tool. Front-loaded with the verb 'Go back', it is highly efficient.
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, no annotations), the one-sentence description is mostly sufficient. It clearly explains the action. However, it omits edge-case behavior (e.g., failure when at the first page) and does not mention that this is a state-changing navigation operation. Still, for this simple tool, the description is largely 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 schema is empty, so schema coverage is 100%. Per the rubric, a baseline of 4 applies for zero-parameter tools. The description correctly avoids adding nonexistent parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Go back to the previous page' uses a specific verb ('go back') and resource ('previous page') that clearly identifies the browser history navigation action. It distinguishes from sibling tools like browser_go_forward (opposite direction) and browser_navigate (URL-specific), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when the agent needs to return to the previous page in browser history. However, it provides no explicit guidance on when not to use this tool or mentions alternatives (e.g., browser_go_forward or browser_navigate). The context is clear but lacks explicit differentiation criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Go forward to the next page
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic action. It does not disclose what happens when there is no forward history (e.g., error, no-op), whether it waits for page load, or other behavioral traits. This leaves the agent potentially unaware of edge cases.
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 fully expresses the tool's purpose. No filler words or redundant information. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description is largely complete for a basic navigation action. However, it would be more complete if it mentioned behavior when no forward history exists, but this is a minor gap for such a simple operation.
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 is trivially 100% covered. The description does not need to explain parameters. With 0 params, the baseline is 4, and there is no additional requirement for the description to compensate.
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 'Go forward to the next page' clearly states the action (go forward) and the target (next page in browser history). It distinguishes itself from siblings like browser_go_back and browser_navigate by specifying a distinct navigation direction.
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 usage is implied by the name and description: it moves forward in browsing history. However, there is no explicit guidance on when to use it versus alternatives, nor any mention of prerequisites (e.g., must have gone back first) 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 element on page
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Exact target element reference from the page snapshot | |
| element | Yes | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Hover over element on page' and does not mention any side effects, state changes, whether a snapshot is required, or what happens after hovering. This is a significant transparency gap for a tool that can trigger UI changes via hover events.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that is front-loaded with the action. It is concise and has no unnecessary words. However, it is so brief that it sacrifices important behavioral context, but for pure conciseness it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must provide complete context. It only states the basic action and lacks information about prerequisites, effects, or edge cases. For a tool that interacts with a live page, this is insufficient for an agent to fully understand its impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'ref' and 'element' well-described in the schema. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function as 'Hover over element on page', which is a specific verb+resource. It distinguishes itself from sibling tools like browser_click and browser_type by the action 'hover'. However, it does not explicitly call out differences from siblings, 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention typical scenarios (e.g., triggering tooltips, dropdowns) or any exclusions. The usage is only implicitly conveyed by the action itself, which is not enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Press a key on the keyboard
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Name of the key to press or a character to generate, such as `ArrowLeft` or `a` |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the literal action and says nothing about focus requirements, potential side effects (e.g., triggering form submission), or whether key combinations are supported.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant words or irrelevant details. It is appropriately sized for a simple one-parameter 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?
While the schema is rich and covers the parameter well, the description lacks usage context and behavioral details. It is adequate for a basic tool but leaves gaps in when to use it and what side effects may occur.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the 'key' parameter with examples such as 'ArrowLeft' or 'a', providing 100% coverage. The description adds no additional semantic meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Press a key on the keyboard' uses a specific verb and resource, clearly indicating the action. It does not explicitly differentiate from sibling tools like browser_type, but the action is distinct enough by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as browser_type for typing text or browser_click. No exclusions or alternative recommendations are mentioned.
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
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only states the action itself and discloses no behavioral details such as whether the screenshot is saved to a file, returned as base64, captures the full page or viewport, or any side effects. This is essentially a tautology of the function name.
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 is immediately clear and front-loaded. Every word earns its place with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for the action itself but lacks crucial context about what the output or result will be. With no output schema, the agent is left wondering whether the screenshot is returned directly, stored, or requires retrieval. This is a significant gap for a tool with minimal structured metadata.
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 is empty. The description does not need to explain parameter semantics. Per the rubric, a score of 4 is the baseline for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Take a screenshot') and the resource ('current page'). It is specific and unambiguous. However, it does not distinguish this from the sibling tool browser_snapshot, which could potentially be interpreted as a similar capture 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 provided about when to use this tool versus alternatives, or any exclusions. The description simply states the operation without context. For example, it does not clarify whether this should be used for visual debugging, documentation, or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Select an option in a dropdown
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Exact target element reference from the page snapshot | |
| values | Yes | Array of values to select in the dropdown. This can be a single value or multiple values. | |
| element | Yes | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not disclose prerequisites (e.g., a visible dropdown, a prior snapshot), side effects (e.g., triggering change events), or behavior with multi-select. For a simple interaction, this minimal info leaves gaps about runtime 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 concise sentence with no fluff. It is appropriately sized for the tool's simplicity, though it could include a brief usage tip without becoming verbose. It is well-structured and immediately comprehensible.
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, 100% schema coverage, and no output schema, the description is minimally adequate. However, it lacks guidance on when to use it versus sibling tools, and it does not mention multi-select behavior or prerequisites such as a snapshot. These are clear gaps, but not severe given the straightforward nature of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all three parameters (ref, values, element). The description adds no additional meaning beyond the schema, so the baseline score of 3 applies. It does not clarify how 'values' interacts with multi-select or how ref is obtained.
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 'Select an option in a dropdown' uses a specific verb ('select') + resource ('option in a dropdown'), clearly distinguishing it from sibling tools like browser_click, browser_type, and browser_press_key. There is no ambiguity about what operation it performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that it should be used specifically for dropdown elements, nor does it exclude scenarios where browser_click might be more appropriate. There is no explicit comparison or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture accessibility snapshot of the current page. Use this for getting references to elements to interact with.
| 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 transparency burden. 'Capture accessibility snapshot' implies a non-destructive read operation, but it does not explicitly state side effects, return format, or limitations. It adds some context about the purpose (references for interaction) but lacks deeper behavioral disclosure.
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, front-loaded with the primary action, and contains no filler. Every word adds value by conveying what the tool does and why to use it.
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 has no parameters and no output schema, the description adequately covers its purpose and usage. It does not detail the snapshot's format or content, but for a simple read-only tool with no inputs, this is acceptable. The context relative to siblings is clear enough for an agent to decide when to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage (empty properties object), so the schema fully documents parameters. The description adds meaning by explaining the tool's output is used for interaction references, which is useful beyond the schema. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures an accessibility snapshot of the current page, which is a specific verb+resource. This distinguishes it from siblings like browser_screenshot (visual) and browser_navigate (navigation), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this for getting references to elements to interact with,' providing clear context for when to use the tool. It does not mention when not to use it or name specific alternatives, but the usage context is directly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into editable element
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Exact target element reference from the page snapshot | |
| text | Yes | Text to type into the element | |
| submit | Yes | Whether to submit entered text (press Enter after) | |
| element | Yes | Human-readable element description used to obtain permission to interact with the element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Type text into editable element' without revealing whether text is appended or replaced, how the 'element' permission field works, or any error or side-effect behavior. This is minimal and leaves significant gaps.
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 wasted words, front-loading the core action. However, it is under-specified, which slightly detracts from its overall value despite being concise.
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 part of a browser automation suite, but the description fails to mention that 'ref' comes from a page snapshot, the role of the human-readable 'element' description, or the behavior of the 'submit' flag. With no output schema or annotations, these contextual details are necessary 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 100% (all four parameters have descriptions), so the schema handles parameter semantics. The description adds no additional meaning beyond the schema, which meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Type') and target ('editable element'), clearly distinguishing it from sibling tools like browser_click or browser_press_key. It states exactly what the tool does without 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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., obtaining a ref from a snapshot), nor any exclusions or comparisons with browser_press_key or other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for a specified time in seconds
| Name | Required | Description | Default |
|---|---|---|---|
| time | Yes | The time to wait in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only states the basic function. It does not disclose that the wait is blocking, whether it returns a value, or how invalid inputs are handled. The description essentially restates the schema parameter description, adding no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential information without any fluff. It is appropriately sized 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?
The tool is simple with one well-described parameter, so the description covers the core functionality. However, it lacks details about return behavior, potential blocking nature, and differentiation from browser_wait_for_text. These gaps prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with a clear description for the single 'time' parameter ('The time to wait in seconds'). The tool description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Wait') and the target ('time in seconds'), making the tool's purpose unmistakable. It also distinguishes from sibling tools like browser_wait_for_text by specifying a fixed time delay rather than waiting for a condition.
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. While the tool name and description imply a time-based wait, there is no explicit mention of browser_wait_for_text or other context, 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.3browser_clickbrowser_get_console_logsbrowser_go_backbrowser_go_forwardbrowser_hoverbrowser_navigatebrowser_press_keybrowser_screenshotbrowser_select_optionbrowser_snapshotbrowser_typebrowser_waitScored across 12 tools
Each tool targets a distinct browser action: navigation (navigate, go_back, go_forward), interaction (click, hover, type, select_option, press_key), state reading (snapshot, get_console_logs, screenshot), and waiting (wait). No two tools overlap in purpose, making selection unambiguous.
All tools follow a consistent verb_noun snake_case pattern with a uniform 'browser_' prefix. Verbs clearly describe actions (navigate, click, type, wait), making the naming predictable and easy to infer.
12 tools is a well-scoped set for a browser automation server. Each tool serves a distinct, essential function without unnecessary bloat or missing core capabilities, fitting the typical 3-15 range.
The tool set covers the full browser automation lifecycle: navigation, element interaction, state inspection, and output. Minor gaps exist such as no explicit 'get URL/title' or tab management, but the snapshot tool provides sufficient page state, so agents can work around these gaps.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
AI-powered web automation. Navigate websites using AI agents for one page or a thousand
