Click on "Install 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: byob
⚡ 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, the description carries the full burden of disclosing side effects. It only states 'Perform click' without mentioning that clicks can trigger navigation, open new tabs, or require a stable page state. No behavioral traits beyond the literal action are disclosed.
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, which is concise and free of fluff. However, it is under-specified to the point of being nearly a restatement of the tool name, so it does not fully earn its place by adding 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?
As part of a browser automation suite with no output schema and no annotations, the description should explain the tool's role in the workflow (e.g., that it follows a snapshot and uses the ref). It provides none of this context, making it incomplete for reliable agent 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?
The input schema already provides detailed descriptions for both required parameters, covering 100% of them. The tool description adds no additional parameter meaning, so the schema properly handles semantic explanation; 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 identifies the action (perform click) and the target (web page), making the core purpose understandable. However, it does not differentiate from sibling interaction tools beyond the verb itself, and it is quite terse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as browser_hover or browser_press_key. It also fails to mention the prerequisite of obtaining the element reference from a browser_snapshot, leaving the agent without critical context for correct invocation.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It states a 'get' action, implying read-only, but does not explain whether logs are cleared after retrieval, whether all logs are returned, or what format the output takes. This is insufficient for a tool that may have 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?
The description is a single, clear sentence that is appropriately sized for a simple tool. It front-loads the action and resource without unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description should clarify what the returned console logs contain (e.g., message, level, timestamp). It does not, leaving the agent to guess the return format. For such a simple tool, additional detail on expected output would be valuable.
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 has zero parameters, and the baseline for 0 params is 4. The description adds no parameter information, but none is needed. The tool is parameterless, so there is no ambiguity to resolve.
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 ('get') and resource ('console logs') with clear scope ('from the browser'). It distinguishes from sibling tools like browser_snapshot or browser_navigate, 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?
No guidance is provided about when to use this tool versus alternatives. There is no mention of typical use cases, prerequisites, or exclusions. The description simply states the function without context.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without explaining potential edge cases (e.g., behavior when no previous page exists) or side effects like clearing forward history, providing minimal transparency beyond the name itself.
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 unnecessary words. It is perfectly concise and front-loaded with the action.
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 is mostly complete for an agent to understand its purpose. However, it omits any context about limitations or failure conditions, which would add 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?
The tool has zero parameters and schema coverage is 100%, so the description does not need to explain any parameter semantics. The baseline of 4 for a zero-parameter tool 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 'Go back to the previous page' uses a specific verb and resource, making the action immediately clear. It also implicitly distinguishes itself from sibling tools like browser_go_forward and browser_navigate by focusing on backward navigation.
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 explicit guidance on when to use this tool versus its alternatives (e.g., browser_navigate, browser_go_forward). There is no mention of prerequisites like existing browser history or scenarios where this tool should not be used.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to mention what happens when there is no next page (e.g., no-op, error), whether it preserves state, or if it has any side effects. The simple statement lacks crucial 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 one short, clear sentence with no unnecessary words. It is appropriately sized for a zero-parameter navigation action, achieving maximum conciseness without losing intended 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?
Given the simplicity of the tool (no params, no output schema), the description is minimally acceptable but incomplete. It does not specify that 'forward' refers to browser history, nor does it mention behavior when no forward entry exists. This context would help the agent use the tool 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?
The tool has zero parameters and the schema properties are empty, so the baseline is 4. The description adds no parameter details, but none are needed. The schema already covers parameter semantics fully.
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' uses a specific verb and resource, and the sibling tool 'browser_go_back' helps clarify that 'forward' refers to browser history navigation. However, it does not explicitly mention 'history', which could cause slight ambiguity with general 'next page' concepts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like 'browser_navigate' or 'browser_go_back'. The tool name implies forward history navigation, but the description does not state any conditions 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.
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 states 'hover over element' but does not explain whether this triggers JavaScript events, whether it's a read-only operation, or what the result/return value is. The agent cannot assess side effects or requirements.
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 redundant wording. It's appropriately brief for a simple action, though extremely terse. It doesn't waste words but also provides minimal information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is minimally complete, but it lacks important context such as how to obtain the 'ref' from a snapshot, whether hover may cause page state changes, or typical use cases. The absence of an output schema and annotations leaves gaps that the description does not fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with explicit descriptions for 'ref' and 'element'. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'hover' and identifies the resource as 'element on page', making the core action clear. However, it doesn't specify how the element is selected or what distinguishes this from other interaction tools beyond the action itself, so it's adequate but not particularly informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like browser_click or browser_type. There is no mention of hover being useful for revealing tooltips or prerequisite for other actions, leaving the agent to infer usage from the verb alone.
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?
Annotations are absent, so the description carries full burden, but it only states the basic action. It does not disclose details such as whether the key press is applied to the focused element, whether modifiers (e.g., Ctrl, Shift) are supported, or any side effects like triggering navigation. The description adds no behavioral context beyond the minimal action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is concise, though it could have been enriched with usage context without being verbose. Overall, it is appropriately sized 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?
The tool is simple (one parameter, no output schema) and the description conveys the core action. However, it lacks usage guidance and behavioral context such as modifiers or page focus requirements, making it minimally adequate but not fully complete for an agent to understand when and how to invoke 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 input schema has 100% coverage of the 'key' parameter with a clear description, so the schema already explains the parameter meaning. The tool description adds no additional parameter semantics, but the baseline of 3 is appropriate given high schema 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 'Press a key on the keyboard' uses a specific verb and resource, clearly distinguishing this tool from siblings like browser_type (which types text) and browser_click. It is concise 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 is provided on when to use this tool versus alternatives. For example, it does not mention use cases like keyboard shortcuts, navigation keys, or contrast with browser_type. The description is purely declarative with no contextual usage direction.
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?
With no annotations available, the description carries the entire burden of behavioral disclosure. It only states what the tool does but gives no information about return format (e.g., file path, base64 data), side effects, or how the screenshot relates to the page state. This is a minimal description that fails to expose any behavioral traits.
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 gets straight to the point. It is appropriately scaled for a tool with no parameters, and every word adds 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 simple tool, the description is adequately clear, but it lacks important context such as what the screenshot output looks like (since there is no output schema) and how it differs from browser_snapshot. These gaps make the description minimally viable but 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?
The tool has zero parameters and the schema coverage is 100% (empty schema). The description does not need to add parameter information, and the baseline for 0-parameter tools is 4. There is not much to add beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (take a screenshot) and the resource (the current page). It is specific and understandable, but it does not distinguish itself from the sibling tool browser_snapshot, which likely has a similar 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?
No guidance is provided on when to use this tool versus alternative tools like browser_snapshot. There is no mention of prerequisites, use cases, or exclusions, leaving agents without direction for selecting the appropriate tool.
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 provided, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not describe how the selection is performed, whether multi-select is supported, or what side effects occur (e.g., navigation or event firing). The absence of behavioral detail leaves the agent uncertain about the tool's operational traits.
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, immediately front-loaded with the action and target. It contains no filler or redundancy, every word earns its place, and it is appropriately sized for a simple interaction 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 has no output schema, no annotations, and a terse description. While the input schema explains parameters, the description does not convey when to use it relative to siblings, nor does it mention required snapshots or return behavior. This is minimally complete for a simple tool but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all three parameters with clear descriptions (ref, values, element), achieving 100% schema_description_coverage. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Select an option in a dropdown' clearly states the action and target resource with a specific verb. It distinguishes this tool from siblings like browser_click and browser_type by focusing on dropdown selection, making its 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 provides no guidance on when to use this tool versus alternatives such as browser_click or browser_type. It lacks context about prerequisites (e.g., needing an expanded dropdown or a page snapshot) and does not mention exclusions or alternative tools.
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 provided, the description carries the full burden of behavioral disclosure. It implies a read-only operation by saying 'snapshot' and 'current page', but it does not explicitly state side-effect safety, what happens if the page is not fully loaded, or the exact nature of the returned references. This leaves some behavioral 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?
The description is two concise sentences. The first states the core action, the second explains the use case. There is no extraneous information, making it highly efficient 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 tool's simplicity—no parameters and no output schema—the description is largely adequate. It covers what the tool does and when to use it. However, it lacks detail on the exact format or structure of the snapshot (e.g., whether it returns the full accessibility tree or just element references), which 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?
The tool has zero parameters, so the schema provides complete coverage. According to the rubric, the baseline is 4 for zero-parameter tools. The description adds context about the return value ('references to elements') which is helpful for understanding what the snapshot provides, but there are no parameter semantics to clarify.
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, with a specific verb and resource. It distinguishes itself from siblings like browser_screenshot by emphasizing use for 'getting references to elements to interact with', which is a unique purpose among the listed browser automation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this for getting references to elements to interact with', providing clear guidance on when to employ this tool. It doesn't explicitly name alternatives or state when not to use it, but the sibling list makes the differentiation apparent.
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. It only states the basic function and does not disclose potential side effects (e.g., replacing existing text, focusing the element), the need for a valid element reference, or that submit can press Enter. This is minimal 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 a single, front-loaded sentence with no wasted words. It is concise and efficient, though slightly under-specified, but earns its place by stating the core function 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?
Given four required parameters, no annotations, no output schema, and sibling tools with overlapping behavior, the description is incomplete. It does not explain how parameters like 'element' and 'ref' relate, nor does it provide usage context such as the need for a snapshot or when to set submit to true.
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 provides 100% coverage with descriptions for all four parameters, so the baseline is 3. The tool description adds no extra parameter meaning beyond what the schema already explains.
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 (type text) and the target resource (editable element). It distinguishes the tool from siblings like browser_click and browser_press_key by specifying text input into editable fields.
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 such as browser_press_key or browser_click. There is no mention of prerequisites (e.g., taking a snapshot first) or exclusions.
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?
No annotations are provided, so the description carries the behavioral burden. It transparently states the operation (waiting a specified number of seconds), but does not add context such as whether it blocks execution or is a fixed sleep rather than a condition wait. The described behavior is simple and complete as-is.
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 conveys the purpose without any unnecessary words or repetition. It is perfectly 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?
Given the tool's simplicity—one parameter, no output schema, no complex side effects—the description provides sufficient information. It could optionally mention blocking behavior or intended usage context, but these are implied and not critical for such a minimal tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage: the 'time' parameter is already explained as 'The time to wait in seconds'. The tool description adds no additional semantic meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Wait') and the resource (specified time in seconds), making it distinct from sibling navigation and interaction tools. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, but the use case (delaying execution) is implied by the action. Since there are no alternative wait tools among siblings, the lack of explicit guidance is acceptable.
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. Dates show when Glama detected each change.
v0.1.3browser_clickbrowser_get_console_logsbrowser_go_backbrowser_go_forwardbrowser_hoverbrowser_navigatebrowser_press_keybrowser_screenshotbrowser_select_optionbrowser_snapshotbrowser_typebrowser_waitEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/financieramoodfit-code/browsermcp-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
