Which integrations are available for this server?

Enables AI assistants to control the Arc browser via MCP, supporting navigation, clicking, form filling, JavaScript execution, screenshots, and content extraction. Enables AI assistants to control the Brave browser via MCP, supporting navigation, clicking, form filling, JavaScript execution, screenshots, and content extraction. Enables AI assistants to control the Opera browser via MCP, supporting navigation, clicking, form filling, JavaScript execution, screenshots, and content extraction. Enables AI assistants to control the Vivaldi browser via MCP, supporting navigation, clicking, form filling, JavaScript execution, screenshots, and content extraction.

How do I use Browser Bridge MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Browser Bridge MCP Go to google.com and search for MCP servers" 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 Bridge MCP

by adbarc92

Overview Schema Related Servers Score Discussions

TypeScript

Local

Browser Bridge MCP

npm version

MCP server that gives AI coding assistants direct control of a real Chrome browser — navigate, click, fill forms, run JavaScript, take screenshots, and read page content. It exists so your assistant can see what you see, instead of you alt-tabbing to copy-paste errors and describe UI state in words.

MCP Client ←(stdio)→ mcp-browser-bridge ←(WebSocket :7483)→ Browser Extension ←(Chrome APIs)→ Browser

Works with any MCP-compatible client: Claude Code, Cursor, Windsurf, Cline, and others.

Quick Start

1. Install the extension

Load it as an unpacked extension:

Download or clone this repo.
Open chrome://extensions and enable Developer mode.
Click Load unpacked and select the extension/ folder.

Works in any Chromium browser: Chrome, Brave, Edge, Arc, Vivaldi, Opera.

2. Add to your MCP client

Run:

claude mcp add browser-bridge -- npx -y mcp-browser-bridge

Or add to .mcp.json:

{
  "mcpServers": {
    "browser-bridge": {
      "command": "npx",
      "args": ["-y", "mcp-browser-bridge"]
    }
  }
}

Add to .cursor/mcp.json:

{
  "mcpServers": {
    "browser-bridge": {
      "command": "npx",
      "args": ["-y", "mcp-browser-bridge"]
    }
  }
}

Add to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "browser-bridge": {
      "command": "npx",
      "args": ["-y", "mcp-browser-bridge"]
    }
  }
}

In the Cline pane, open MCP Servers → Configure MCP Servers to edit cline_mcp_settings.json, and add:

{
  "mcpServers": {
    "browser-bridge": {
      "command": "npx",
      "args": ["-y", "mcp-browser-bridge"]
    }
  }
}

Use npx -y mcp-browser-bridge as the server command in your client's MCP configuration. The server communicates over stdio.

3. Verify

Start your MCP client. The extension popup should show a green Connected indicator. Call the browser_status tool to confirm.

Related MCP server: mcp-browser-kit

Available Tools

All tools accept an optional tabId parameter. When omitted, they target the active tab.

Tool	Description
`browser_status`	Check if the extension is connected and get active tab info
`browser_navigate`	Navigate a tab to a URL
`browser_screenshot`	Capture a screenshot of the visible area of a tab
`browser_evaluate`	Execute JavaScript in a tab and return the result
`browser_click`	Click an element by CSS selector
`browser_fill`	Fill a form field by CSS selector (React-compatible)
`browser_get_content`	Get the text or HTML of a page or element
`browser_get_tabs`	List all open browser tabs
`browser_get_console`	Get captured console log entries from a tab
`browser_wait_for`	Wait for a CSS selector to appear on the page
`browser_send_message`	Send a custom message to the extension

Included Prompts

The server ships two MCP prompts that provide guided workflows to any connected client:

Prompt	Description
`browse`	General-purpose browser interaction — navigating, clicking, filling forms, screenshotting, running JS. Accepts an optional `task` argument.
`qa-runner`	Structured QA checklist execution — drives the browser through test scenarios defined in markdown and reports pass/fail results. Accepts an optional `checklist` path.

In Claude Code, these appear as slash commands: /browser-bridge:browse and /browser-bridge:qa-runner.

Configuration

The WebSocket port defaults to 7483. To change it:

Server side: Set the BRIDGE_WS_PORT environment variable in your MCP config.
Extension side: Change the port in the extension popup and click Reconnect.

Security

WebSocket binds to 127.0.0.1 only — no network exposure.
Connections restricted to browser extension origins.
Single extension client at a time.

Troubleshooting

Extension shows "Disconnected" Check that the MCP server is running and the port is free:

# macOS/Linux
lsof -i :7483

# Windows
netstat -aon | findstr :7483

Tools return "No extension connected" Open the extension popup and click Reconnect.

Screenshots fail The target tab must be visible and focused. Background or minimized tabs cannot be captured.

browser_evaluate returns unexpected results Results must be JSON-serializable. Promises return {} — use synchronous expressions or await inside an IIFE and return a plain value.

Development

git clone https://github.com/adbarc92/mcp-browser-bridge.git
cd mcp-browser-bridge
npm install
npm run build
npm test                 # 57 tests via Vitest

Load the extension locally via chrome://extensions → Load unpacked → select extension/.

The repo includes a .mcp.json configured for local development.

License

MIT

Available Tools

11 tools

browser_clickB

Click an element on the page identified by a CSS selector

ParametersJSON Schema

Name	Required	Description	Default
`tabId`	No	Tab ID (defaults to active tab)
`selector`	Yes	CSS selector for the element to click

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description does not disclose essential behavioral traits: whether the click triggers navigation, waits for page load, throws errors for missing elements, or what the return value is. With no annotations, the description carries the full burden, but it fails to provide these details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence of 11 words, which is concise but lacks necessary details for an agent to fully understand the tool's behavior. It is front-loaded with the key action but leaves gaps.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (2 parameters, no output schema), the description should at least mention return type or behavior (e.g., 'returns success status'). Currently, it omits this context, making it incomplete for an agent to rely on.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes both parameters (tabId and selector) with 100% coverage. The description adds no new meaning beyond what's in the schema, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Click') and the resource ('an element on the page') with the method of identification ('CSS selector'). It distinguishes this tool from siblings like browser_fill (which fills form fields) or browser_screenshot (which captures images).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 (e.g., browser_fill might also involve clicking, but not addressed). There's no mention of prerequisites, limitations, or cases where this tool is preferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_evaluateB

Execute JavaScript in the context of a browser tab and return the result

ParametersJSON Schema

Name	Required	Description	Default
`tabId`	No	Tab ID (defaults to active tab)
`expression`	Yes	JavaScript expression to evaluate

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations provided, and the description does not disclose side effects (e.g., whether the JavaScript execution is read-only or can modify the page), permissions required, or error behavior. This is a significant gap for a tool that executes arbitrary code.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that concisely conveys the core functionality. It is front-loaded and contains no filler, though it could benefit from a bit more structure.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description should clarify the return format (e.g., JSON serialization, error behavior). The tool has 11 siblings, yet no contextualization is provided. The description feels incomplete for a JavaScript evaluation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides descriptions for both parameters (tabId and expression) with 100% coverage. The description adds no additional meaning beyond 'execute JavaScript', so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Execute JavaScript'), the target ('in the context of a browser tab'), and the outcome ('return the result'). It is specific and distinguishes from siblings like browser_get_content or browser_click.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives such as browser_get_content or browser_click. The description does not mention prerequisites, limitations, 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.

browser_fillB

Fill a form field with the specified value

ParametersJSON Schema

Name	Required	Description
`tabId`	No	Tab ID (defaults to active tab)
`value`	Yes	Value to fill in
`selector`	Yes	CSS selector for the input element

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and description lacks details on behavioral aspects such as whether it triggers events, clears existing content, or works with all input types.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no unnecessary words, front-loaded with action and target.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a browser interaction tool, description omits critical context like return behavior, error handling, and interaction with page events.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema covers all 3 parameters with descriptions, so description adds no extra value. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb ('Fill') and resource ('form field'), and is distinct from sibling tools like browser_click or browser_navigate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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., browser_click or browser_send_message) or any prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_get_consoleB

Get captured console log entries from a tab

ParametersJSON Schema

Name	Required	Description	Default
`clear`	No	Clear logs after retrieval (default: false)
`tabId`	No	Tab ID (defaults to active tab)

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It implies a read operation but does not disclose whether retrieving logs is destructive by default (the 'clear' parameter is optional). It also fails to mention if logs are only available after navigation or if the tool clears logs automatically before returning.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no unnecessary words. It is front-loaded with the core action and resource, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so the description should explain what the agent receives (e.g., array of log entries, each with message, level, timestamp). It does not. Also, it does not clarify behavior when no logs exist or when the tab is closed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters have descriptions in the schema, so baseline is 3. The description adds no extra meaning beyond the parameter names and schema; e.g., it does not clarify what 'console log entries' includes (errors, warnings, logs) or the format of the returned data.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get') and the resource ('captured console log entries') with context ('from a tab'). Among the sibling tools (e.g., browser_get_content, browser_evaluate), none duplicate this purpose, making it distinct and specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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_evaluate for runtime expressions or browser_get_content for page source. The description does not mention prerequisites like enabling console capture or tab activity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_get_contentA

Get the HTML or text content of a page or specific element

ParametersJSON Schema

Name	Required	Description
`tabId`	No	Tab ID (defaults to active tab)
`format`	No	Content format (default: text)
`selector`	No	CSS selector to get content of (defaults to body)

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so description carries full burden. It mentions HTML/text format and element selection but does not disclose behavior for missing elements, error conditions, or performance implications. Basic transparency, but significant gaps remain.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with action and resource. Every word carries meaning. No wasted content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, description could mention return value format (string). It covers basic functionality but omits return type and behavior for invalid selectors. Minor gaps for a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (all parameters documented in schema). Description adds context by specifying 'page or specific element' and implying default values (body selector, text format). Adds meaning beyond schema, e.g., that selector is optional and defaults to body.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the action 'Get' and the resource 'content of a page or specific element'. It distinguishes from siblings like browser_screenshot (visual capture) and browser_evaluate (JavaScript evaluation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance. Usage is implied but no alternatives or exclusions mentioned. The description is minimal and does not help differentiate from related tools like browser_evaluate or browser_get_console.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_get_tabsA

List all open browser tabs

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description gives basic behavior (lists tabs) but lacks detail on output format or limitations (e.g., which window/tabs are included). Adequate for a simple read-only tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence efficiently conveys the tool's entire purpose without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter tool with no output schema, the description is mostly complete. It could specify the return format (e.g., list of tab titles/URLs), but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, and schema coverage is 100%. Baseline is 4 per guidelines; description adds no parameter info, which is acceptable here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (list) and resource (open browser tabs), distinguishing it from other browser tools like navigate, click, or screenshot.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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. The description only states what it does, not when it should be preferred or avoided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_navigateB

Navigate a browser tab to the specified URL

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL to navigate to
`tabId`	No	Tab ID (defaults to active tab)

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must cover behavior. It only states the basic action, omitting details like whether page load is awaited, error handling, or impact on browser state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no waste, directly conveys the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple navigation tool with no output schema, the description is minimally adequate but lacks behavioral detail and does not compensate for missing annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions already cover both parameters (url, tabId) with clear explanations. The description adds no additional meaning, so baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Navigate') and the target ('browser tab to the specified URL'), distinguishing it from sibling tools like browser_screenshot or browser_click.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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, no prerequisites or exclusions provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_screenshotB

Capture a screenshot of the visible area of a browser tab

ParametersJSON Schema

Name	Required	Description
`tabId`	No	Tab ID (defaults to active tab)
`format`	No	Image format (default: png)
`quality`	No	JPEG quality (0-100, only for jpeg format)

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic action, omitting details about permissions, error handling (e.g., tab not visible), return format (image data), 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with clear, front-loaded action. No wasted words; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description should compensate with behavioral and usage details. It fails to explain return type, default behavior (active tab), or constraints (visible area only). Incomplete for a tool with 3 optional parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the parameter descriptions already provide meaning. The tool description adds no extra context beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Capture a screenshot') and the target ('visible area of a browser tab'). It is specific and distinguishes from sibling tools like browser_get_content (which retrieves HTML) and browser_status (which checks tab state).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like browser_get_content for page content or browser_evaluate for JavaScript. The description lacks context about prerequisites (e.g., tab must exist) or scenarios where screenshot is inappropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_send_messageC

Send a custom message to the Chrome extension for extensibility

ParametersJSON Schema

Name	Required	Description	Default
`data`	No	Optional data payload
`type`	Yes	Custom message type

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must fully disclose behavioral traits. It only states 'custom message' without mentioning side effects, state changes, destructive potential, or permission requirements. The phrase 'for extensibility' is too vague to inform an agent about consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, front-loaded with action and resource. No redundancy. Although brief, it earns its place by being direct. Could be slightly expanded for better guidance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high schema coverage and lack of output schema, the description is minimally adequate. However, it lacks context on typical use, error behavior, or interaction with other browser tools. An agent may not know when or how to invoke it effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with both parameters documented. The description adds 'custom message type' and 'optional data payload', but these merely echo schema descriptions. No additional meaning or constraints are provided beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states verb 'Send' and resource 'custom message to the Chrome extension', with purpose 'for extensibility'. It distinguishes from siblings like browser_navigate or browser_click by being a generic message-sending tool. However, it doesn't specify what types of messages are possible or their effects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 like browser_evaluate or browser_get_content. The description lacks context about use cases, prerequisites, or conditions under which sending a custom message is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_statusA

Check if the Chrome extension is connected and get active tab info

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, but the description discloses the tool's read-only nature and what it does (check connection, get tab info). It lacks details on error behavior or permissions, but for a simple status check, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence that efficiently conveys the tool's function without extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is sufficiently complete given the tool's simplicity (no parameters, no output schema). It covers two aspects (connection check, active tab info), but could optionally clarify what 'active tab info' includes, such as URL or title.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With no parameters, the schema provides no behavioral clues. The description adds essential meaning by explaining the tool's purpose, which is critical for agent selection.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks extension connection and retrieves active tab info, with a specific verb ('check', 'get') and resource, distinguishing it from action-oriented siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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 like browser_get_tabs, nor does it provide when-not-to-use guidance; it only implicitly suggests usage for status verification.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

browser_wait_forB

Wait for an element matching a CSS selector to appear on the page

ParametersJSON Schema

Name	Required	Description
`tabId`	No	Tab ID (defaults to active tab)
`timeout`	No	Timeout in milliseconds (default: 30000)
`selector`	Yes	CSS selector to wait for

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must cover behavior. It states 'wait for an element...to appear' but omits critical details: what happens on timeout, whether it blocks until presence, return value, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no redundant words. Purpose is front-loaded and immediately understandable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description should provide more context about behavior (timeout, blocking) and usage context (e.g., for page load). It falls short for a wait-based tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the parameter descriptions in the schema are sufficient. The description does not add extra meaning beyond the schema, meeting the baseline expectation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('wait for') and the target ('an element matching a CSS selector'). It distinguishes itself from sibling tools like browser_click or browser_navigate by specifying the waiting behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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., polling with browser_evaluate). No mention of prerequisites or typical scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

11 tool updatesv1.2.1Jul 30, 2026
- First observedbrowser_click
- First observedbrowser_evaluate
- First observedbrowser_fill
- First observedbrowser_get_console
- First observedbrowser_get_content
- First observedbrowser_get_tabs
- First observedbrowser_navigate
- First observedbrowser_screenshot
- First observedbrowser_send_message
- First observedbrowser_status
- First observedbrowser_wait_for

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose, such as navigating, clicking, filling, taking screenshots, evaluating JavaScript, etc. There is no overlap or ambiguity between tool functions.

Naming Consistency5/5

All tools follow a consistent 'browser_<verb>' pattern (e.g., browser_navigate, browser_click), making the naming predictable and easy to understand.

Tool Count5/5

With 11 tools, the server covers essential browser automation actions without being overwhelming. The count is well-scoped for the domain.

Completeness4/5

The tool set covers core browser operations (navigation, content retrieval, interaction, screenshots, JavaScript evaluation, tab listing, waiting, console logs). However, minor gaps like back/forward navigation, tab closing, or cookie management are missing, which prevents a perfect score.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

sncro A
io.github.scottconfusedgorilla
Live browser debugging for AI assistants — DOM, console, network via MCP.
Browser Automation Developer Tools Monitoring
2
mintqa-mcp
io.github.adamgusky
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
Testing & QA Tools CI/CD & DevOps
2
autobrowserapproval-mcp
com.clauxel.autobrowserapproval
A paid remote MCP for AI agent browser approval MCP, built to return verdicts, receipts, usage logs,
Browser Automation Agent Orchestration
2
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24

Related MCP Servers

real-browser-mcp
Browser Automation Web Scraping Developer Tools
ofershap
A
license
A
quality
C
maintenance
MCP server + Chrome extension that gives AI coding agents control of your real browser with existing sessions, logins, and cookies. Works with Cursor, Claude, Windsurf.
Updated 13 days ago (2026-08-24 13:08 UTC)
18
104
49
MIT
mcp-browser-kit
Browser Automation Web Scraping App Automation
ndthanhdev
A
license
Not graded
quality
B
maintenance
An MCP Server that enables AI assistants to interact with your local browsers.
Updated 3 days ago (2026-09-03 13:03 UTC)
3,607
54
MIT
BrowserGenie MCP Server
Browser Automation Web Scraping
BrowserGenie
A
license
B
quality
C
maintenance
An MCP server that provides AI models with full browser automation capabilities through Chrome. It enables navigation, interaction, screenshots, and complete DevTools access by bridging AI clients with a companion Chrome extension.
Updated 3 months ago (2026-06-10 10:01 UTC)
99
16
3
Apache 2.0
mcp-browser-server
Browser Automation Web Scraping
mehranakila56-ops
A
license
A
quality
D
maintenance
A MCP server that gives AI assistants full browser control, enabling navigation, clicking, form filling, and screenshots via any MCP client.
Updated 6 months ago (2026-03-01 21:17 UTC)
8
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/adbarc92/mcp-browser-bridge'

If you have feedback or need assistance with the MCP directory API, please join our Discord server