Controls the Firefox browser via a WebSocket bridge and browser extension, providing tools for page navigation, DOM inspection, JavaScript execution, and user interaction.
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., "@open-browser-control Search for MCP on Google and click the first result"
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.
Give AI agents control of your browser — Chrome or Firefox. Works with Kiro, Claude Code, Claude Desktop, Cursor, and any MCP client.
The AI uses your real browser — your cookies, sessions, and logins. When it hits something it can't handle (sign-in, CAPTCHA, MFA), it asks you to step in, then continues where it left off.
Install either the Chrome or the Firefox extension — the MCP server speaks the same protocol to both.
Add to your MCP client's config:
Kiro — add to .kiro/settings/mcp.json (workspace) or ~/.kiro/settings/mcp.json (global):
{
"mcpServers": {
"browser": {
"command": "npx",
"args": ["-y", "open-browser-control"]
}
}
}claude mcp add browser -- npx -y open-browser-controlAdd to your MCP config file:
{
"mcpServers": {
"browser": {
"command": "npx",
"args": ["-y", "open-browser-control"]
}
}
}Pick whichever browser you'd like the AI to drive.
Chrome — install from the Chrome Web Store:
Open Browser Control on the Chrome Web Store
Unpack the extension and load it in Firefox:
npx -y open-browser-control --extension firefoxThis prints a path like ~/open-browser-control-extension-firefox. Then:
Open about:debugging#/runtime/this-firefox
Click Load Temporary Add-on…
Pick the manifest.json inside that folder
Firefox clears unsigned temporary add-ons on restart. For a permanent install, use Firefox Developer Edition (
xpinstall.signatures.required=false) or sign the extension via AMO.
The extension is auto-installed to ~/open-browser-control-extension/ on first run. Load it in Chrome:
Open chrome://extensions/
Enable Developer mode (toggle in top right)
Click Load unpacked
Select the folder: ~/open-browser-control-extension/
Done. The extension auto-connects when your agent starts. No servers to run, no buttons to click.
Related MCP server: byob
AI Agent MCP Server Browser Extension
(Kiro, ◄──► (npx open-browser- ◄──► (Chrome: CDP, or
Claude, ..) control) Firefox: scripting API)
stdio ws://localhost:9334 auto-connectYour agent starts the MCP server automatically (from the config above)
MCP server starts a WebSocket bridge on localhost:9334
The browser extension (Chrome or Firefox) auto-connects (polls every 2s until it finds the bridge)
Agent sends tool calls → extension executes (via Chrome DevTools Protocol on Chrome, or the WebExtensions scripting API on Firefox) → results flow back
Both extensions implement the same JSON protocol over WebSocket, so the MCP server, bridge, and agents never need to know which browser is on the other end.
Mode | What happens |
Collaborative (default) | Both user and AI interact with the page |
AI Control | AI drives, user watches |
User Control | AI paused, user takes over |
AI browsing → hits login page → calls browser_request_user("Please sign in")
→ user signs in → clicks "Done" in side panel → AI continues, now authenticated19 tools available to the AI:
Tool | What it does |
| Go to a URL |
| Get interactive elements with positions and text (primary way to read pages) |
| URL, title, dimensions, scroll position |
| Run JavaScript in page context |
| Click by selector, text, or coordinates |
| Type text, optionally clear first or press Enter |
| Scroll up/down/left/right |
| Press any key with modifiers |
| Hover over an element |
| Pick from a dropdown |
| Wait for element, text, or fixed time |
| Capture page as PNG (use sparingly — DOM tools are faster) |
| Ask user to take over (sign in, CAPTCHA, etc.) |
| Create a named tab group for a task |
| Open a new tab in the current group |
| Close a tab |
| Switch to a tab by ID |
| List all open tabs in this session |
| Set the session name (shown on tab group) |
If you're not using an MCP client:
npx -y open-browser-control --bridge # starts WebSocket bridge onlyConnect your agent to ws://localhost:9334 and send JSON messages:
{"type": "action", "action": "navigate", "id": "1", "params": {"url": "https://example.com"}}
{"type": "action", "action": "click", "id": "2", "params": {"text": "Sign In"}}
{"type": "action", "action": "get_dom", "id": "3"}npx -y open-browser-control # Start MCP server (default)
npx -y open-browser-control --bridge # Standalone WebSocket bridge
npx -y open-browser-control --extension # Print extension install path
npx -y open-browser-control --port 9000 # Custom port
npx -y open-browser-control --help # Helpgit clone https://github.com/smankoo/open-browser-control
cd open-browser-control
npm install
npm run build # builds both browsers → dist/chrome, dist/firefox
# and packages to extension/ and extension-firefox/
npm run dev # watch mode
npm start # run MCP server locallyChrome 116+ or Firefox 128+
Node.js 18+
Click on a page element. Specify by CSS selector, visible text, or x/y coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | X coordinate to click | |
| y | No | Y coordinate to click | |
| text | No | Visible text of element to click | |
| button | No | Mouse button (default: left) | |
| selector | No | CSS selector of element to click |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only states basic functionality, omitting side effects (e.g., navigation, popups), error handling, or waiting 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?
Single sentence, no fluff. Purpose and key targeting options are front-loaded. Excellent conciseness.
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?
Lacks details on return value (no output schema), error cases, preconditions (page loaded, element present), and behavioral side effects. For a click action, these are critical for correct agent usage.
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 covers 100% of parameters with descriptions. The description adds context that selector, text, or coordinates are alternative targeting methods, but does not explain ordering, priority, or coordinate origin.
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 clicks a page element and specifies targeting methods (CSS selector, visible text, coordinates). This distinguishes it from siblings like browser_hover, but does not explicitly differentiate when to use click vs hover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like browser_hover or browser_type. Missing context on prerequisites (e.g., element must be visible, page must be loaded).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute JavaScript in the page context and return the result. Useful for extracting specific data, reading computed styles, or interacting with page APIs — often more precise than screenshots for getting exact values.
| Name | Required | Description | Default |
|---|---|---|---|
| expression | Yes | JavaScript expression to evaluate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It mentions 'interact with page APIs' but does not disclose potential side effects (e.g., state modification, CSP restrictions, error behavior). Lacks critical behavioral details for a JS execution tool.
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?
Two sentences, front-loaded with action and result, no wasted words. Efficient and clear.
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?
Covers basic purpose and use cases but omits details on return format, error handling, and async behavior. Adequate but lacks depth for a complex 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?
Schema coverage is 100% with parameter 'expression' described. Description adds no extra meaning beyond the schema, earning baseline 3.
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?
Clearly states it executes JavaScript in page context and returns result, with specific use cases (extracting data, reading computed styles, interacting with APIs). Distinguishes from siblings like browser_screenshot and browser_get_dom.
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?
Provides context on when to use (extracting precise data, computed styles) and contrasts with screenshots, but does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the page DOM structure. Returns interactive elements with their text, roles, and positions. This is the primary way to understand what is on the page — use it to find elements to click, read text content, and understand page layout. Faster and more detailed than screenshots.
| Name | Required | Description | Default |
|---|---|---|---|
| selector | No | Scope to a CSS selector | |
| simplified | No | Return simplified interactive elements (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description handles behavioral disclosure well. Describes return content and performance comparison to screenshots. Could mention it's read-only and no side effects, but acceptable.
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?
Pithy two sentences covering purpose, usage, and key benefit. Front-loaded with 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?
Covers purpose, usage, and output nature. No output schema needed. Could differentiate from browser_get_page_info but overall complete for a read-only DOM retrieval 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?
Schema coverage is 100% and description adds no extra parameter details beyond the schema fields.
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?
States it gets page DOM structure, returns interactive elements with text/roles/positions. Clearly distinguishes from screenshots by claiming it's faster and more detailed.
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?
Explicitly says it's the primary way to understand the page for finding clickable elements, reading text, and understanding layout. Mentions it's faster and more detailed than screenshots, but doesn't discuss when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current page metadata: URL, title, dimensions, scroll position. Use this to quickly check where you are and whether navigation succeeded — much faster than a screenshot.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description lists returned metadata and implies read-only. Could mention page load dependencies or edge cases, but adequate for a simple tool.
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?
Two sentences, front-loaded with result list, includes a useful comparison. No wasted words.
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?
No output schema, but description enumerates all return fields (URL, title, dimensions, scroll position). Could add types or examples, but sufficient for understanding.
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?
No parameters; description effectively conveys what the tool does. Baseline 4 for zero parameters 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?
Description clearly states the tool gets page metadata (URL, title, dimensions, scroll position) and distinguishes it from screenshots. It uniquely identifies the tool among siblings.
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?
Explicitly says to use it to check current location and navigation success, implying after navigation. Does not explicitly list when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move mouse over an element to trigger hover effects.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | ||
| y | No | ||
| text | No | ||
| selector | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It fails to disclose whether the move is physical or simulated, whether it requires element visibility, what happens if no element matches, or if hover state persists. Minimal transparency.
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, which is concise but arguably too brief, sacrificing essential detail. It earns its place but could be restructured to include key parameter guidance.
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 four parameters with no descriptions, no output schema, and no annotations, the description is severely incomplete. The agent lacks critical information to correctly invoke the 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 four parameters with 0% description coverage, and the description adds no meaning to them. The agent gets no clue about how to use x, y, text, or selector to specify the target element.
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 (move mouse over an element) and purpose (trigger hover effects), distinguishing it from sibling tools like browser_click. However, it slightly lacks specificity about which element identification method is preferred.
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 over alternatives, how to choose among the four parameters (x,y, text, selector), or prerequisites such as element visibility. The usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Press a keyboard key, optionally with modifiers.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | Key name (Enter, Tab, Escape, ArrowDown, etc.) | |
| modifiers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure responsibility, but it only states the action without any traits (e.g., event behavior, context limitations, or side effects). This minimal information is insufficient for an agent to understand impact.
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, easy to parse. However, it is too brief to provide necessary details, bordering on under-specification. It earns a middle score for efficiency but lack of substance.
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 keypress tool with a basic schema and no output schema or annotations, the description is too terse. It omits details like key event type (keydown/keyup), return value, or behavior in different contexts, leaving the agent with incomplete information for safe 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 50% (key has description, modifiers has enum but no description). The tool description adds only 'optionally with modifiers,' which is already inferable from the schema. It does not explain modifier combinations or key naming conventions beyond the schema, failing to compensate for low 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 keyboard key, optionally with modifiers' clearly states the action (press) and resource (keyboard key). It distinguishes from siblings like browser_type (typing text) and browser_click (clicking), making the tool's 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 gives no guidance on when to use this tool versus alternatives like browser_type for text input or browser_click for UI interaction. No exclusions or context are provided, leaving the agent to infer appropriate usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all open browser tabs in this session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavior. It mentions session scope but does not specify what information is returned (e.g., titles, URLs, or IDs), nor confirm it is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence with no extraneous words. 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?
Without an output schema, the description should clarify the return format (e.g., tab titles, URLs, IDs). It lists 'open tabs' but omits details about what each tab entry contains.
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?
No parameters exist, so schema coverage is 100%. Baseline 4 applies; no additional parameter meaning needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'open browser tabs', distinguishing it from siblings like browser_switch_tab or browser_new_tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like browser_switch_tab or browser_new_tab, nor any context about prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a new browser tab.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to open (default: about:blank) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'Open a new browser tab' without disclosing behavior like focus change, popup handling, or failure modes.
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?
Single sentence, no redundancy, 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?
Minimal description for a simple tool; lacks details on return value and side effects, but adequate given low complexity.
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 covers parameter fully; description adds no extra meaning beyond the action. Baseline 3 for 100% 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?
Clearly states verb 'Open' and resource 'new browser tab'. Distinct from sibling tools like browser_navigate and browser_switch_tab.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like browser_navigate or browser_switch_tab. Missed opportunity to clarify context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new named tab group for a task. Use this to organize browsing by task — each group gets a label visible in Chrome. The new group becomes the active group; new tabs and navigations happen inside it.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | URL to open in the first tab (default: about:blank) | |
| name | Yes | Short task name for the tab group (e.g. "Search flights", "Debug login") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the new group becomes active and subsequent tabs/navigations happen inside it, adding important context beyond schema. No annotations present.
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?
Two focused sentences with no unnecessary words. Key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description explains behavioral outcome (active group, subsequent actions). Parameter details are clear, and overall provides enough for the tool's simplicity.
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%, baseline 3. Description adds meaning by explaining name as 'Short task name' and url defaults, and that group gets a visible label, improving agent understanding.
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 specific verb 'Create', resource 'named tab group', and context 'for a task', clearly distinguishing it from browser_new_tab which creates a single tab.
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?
Explicitly says 'Use this to organize browsing by task', implying context. Does not state explicit alternatives, but sibling tools are few and distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ask the user to perform an action (e.g., sign in, solve CAPTCHA). AI pauses until user signals done.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message explaining what the user needs to do | |
| timeout | No | Auto-resume after this many ms (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions the AI pauses until the user signals done, which is a key behavioral trait. But it lacks details about what happens on timeout, side effects on automation flow, or how the user signals completion. With no annotations, the description carries the full burden and is adequate but not comprehensive.
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?
Two sentences, front-loaded with the core purpose, and no extraneous information. Every phrase earns its place.
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 with only two parameters and no output schema, the description covers the essential behavioral aspect (pausing). It is complete enough for an agent to use correctly, though it could elaborate on how the user signals done.
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% (both parameters have descriptions). The tool description adds minimal value beyond what the schema provides: it repeats the message usage but does not mention the timeout parameter. 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?
Clearly states the tool asks the user to perform an action (e.g., sign in, solve CAPTCHA) and that the AI pauses until the user signals done. This verb+resource description distinguishes it well from siblings like browser_click or browser_navigate which perform automated actions.
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?
Implies usage when user input or action is needed (e.g., CAPTCHA, sign-in) and that the AI pauses. However, it does not explicitly state when not to use it or mention alternative tools for automated tasks, leaving room for confusion.
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 browser page. Returns the file path to a saved PNG image. Screenshots are slow and heavy — prefer browser_get_dom and browser_get_page_info to understand page content and structure. Use screenshots only when you need to verify visual layout, debug rendering issues, or when DOM inspection is insufficient (e.g. canvas, images, charts). The response includes a pageRect describing which page-coordinate region the image depicts. To zoom into fine detail (especially after a full-page shot), call again with rect:{x,y,width,height} narrowed to a sub-region of that pageRect — coordinates are page CSS pixels.
| Name | Required | Description | Default |
|---|---|---|---|
| rect | No | Page-coordinate rectangle to capture at full CSS resolution. Use this to zoom into a region returned in a prior screenshot's pageRect. | |
| fullPage | No | Capture full scrollable page instead of just viewport | |
| selector | No | CSS selector to screenshot a specific element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses that screenshots are slow and heavy, and explains the rect zooming mechanism. However, it does not explicitly state the default capture area (viewport vs full page), though the fullPage parameter in schema partially addresses this.
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?
Four sentences, front-loaded with purpose and usage, then details. Every sentence adds value with no redundancy or fluff.
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 3 parameters, nested objects, and no output schema, the description is fairly complete. It explains the output (file path, pageRect) and zooming workflow. The missing output schema is partially compensated by the description stating the return format. Could briefly mention default viewport capture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds value by explaining how rect relates to pageRect from previous screenshots, providing usage context beyond the schema. However, it does not elaborate on selector or fullPage beyond their schema descriptions.
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 specific verbs and resources: 'Take a screenshot of the current browser page' and 'Returns the file path to a saved PNG image.' It distinguishes from sibling tools by recommending browser_get_dom and browser_get_page_info for understanding content, clearly stating when to use screenshots.
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?
Explicitly states when to use (visual layout verification, debugging, DOM insufficient) and when not to ('slow and heavy — prefer browser_get_dom...'). Also provides guidance on zooming with rect and pageRect coordination.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scroll the page in a direction.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | No | Pixels to scroll (default: 500) | |
| selector | No | Scroll within a specific element | |
| direction | Yes | Scroll direction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states 'Scroll the page in a direction,' but does not specify how scrolling is performed (e.g., instant vs animated, viewport vs element), nor does it mention the optional 'selector' parameter that changes behavior. This omission reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is appropriately front-loaded and effectively communicates the core action without redundancy.
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 scrolling tool with no output schema, the description provides the essential purpose but lacks details about return behavior or optional use cases like element-specific scrolling. It is minimally complete but could be improved by mentioning that no value is returned or that it scrolls the main page by default.
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, describing all three parameters (amount, selector, direction) with descriptions. The tool description adds no additional meaning beyond 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Scroll the page in a direction' clearly identifies the action (scroll) and resource (the page), and is distinct from sibling tools like browser_click or browser_navigate. However, it could be more specific by mentioning that scrolling can be within a specific element via the 'selector' parameter.
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 vs alternatives like browser_wait (which might wait for scroll events) or browser_execute_js (which could implement custom scrolling). The description does not mention prerequisites or contextual cues for selecting this 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 from a dropdown element.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Option text to match | |
| value | No | Option value to select | |
| selector | Yes | CSS selector of the select element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states the action without mentioning side effects (e.g., page changes, event triggers), requirements (e.g., element visibility), or the result of selection.
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 that clearly communicates the purpose, but could be slightly more informative without being verbose. It is appropriately sized for a simple 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?
With no output schema and no side-effect details, the description is incomplete. It does not explain what happens after selection or what the return value is, leaving the agent underinformed about the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions (text, value, selector).
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 from a dropdown <select> element.' clearly states the action (select) and the specific resource (dropdown <select> element), distinguishing it from sibling tools like browser_click or browser_type.
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, no when-not-to-use conditions, and no mention of alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a descriptive name for this browser session. The name appears on the Chrome tab group so the user can identify what task this session is working on. Call this early with a short task summary (e.g. "Search flights to Paris", "Debug login page").
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Short descriptive name for this session (shown on Chrome tab group) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the name appears on the Chrome tab group, which is behavioral information not in the schema. Since no annotations are provided, this covers the full burden adequately.
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?
Three sentences, each with clear purpose: what the tool does, where the name appears, and when/how to use it. No unnecessary words, 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 (one parameter, no output schema), the description fully covers the necessary information for correct usage, including examples and placement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by specifying the name should be a short task summary and that it will appear on the tab group, enriching the understanding of the parameter beyond the schema description.
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 sets a descriptive name for a browser session, distinguishing it from sibling tools like browser_click or browser_navigate which perform actions. It specifies the resource (browser session) and the action (set 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 advises calling this early with a short task summary and provides examples, giving clear usage context. It does not explicitly mention when not to use or alternatives, but for a simple tool this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch to a specific browser tab by its ID.
| Name | Required | Description | Default |
|---|---|---|---|
| tabId | Yes | Tab ID to switch to (get IDs from browser_list_tabs) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral transparency. It fails to disclose what happens on invalid tab ID, whether it changes browser focus, or any side effects. This is a significant gap for a tool that mutates state.
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 extraneous words. It efficiently conveys the core purpose and links to the parameter source.
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 one-parameter tool with no output schema, the description covers the essential purpose and parameter source. However, missing behavioral details (e.g., error handling) leave some incompleteness.
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 tabId parameter's schema description is complete (100% coverage), and the tool description adds value by directing users to browser_list_tabs for IDs. The description enhances understanding 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 'Switch to a specific browser tab by its ID,' which distinguishes it from siblings like browser_list_tabs (list) and browser_new_tab (create). The verb and resource are 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 provides context by referencing browser_list_tabs for obtaining tab IDs, implying usage when a tab ID is available. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Type text into the focused element or a specific element.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to type | |
| clear | No | Clear existing text before typing | |
| selector | No | CSS selector to focus before typing | |
| pressEnter | No | Press Enter after typing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden, but it only mentions typing into an element. It does not disclose prerequisites (e.g., element must be editable), side effects, or behavior when the element is not focused. The parameters hint at clearing and pressing Enter, but no further context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, which aids quick comprehension. However, it may be too terse, missing an opportunity to add valuable context without becoming verbose.
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 complexity of browser automation and the absence of output schema and annotations, the description is insufficient. It does not explain return values, error states, or when to combine with other tools. The agent lacks critical context for effective 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%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions; it merely restates the concept of focusing a specific element, which is already implied by the 'selector' parameter.
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 target (focused element or specific element), distinguishing it from sibling tools like browser_click or browser_navigate. However, it does not explicitly differentiate from browser_keypress, which could be used for similar input tasks.
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 like browser_keypress or browser_click. The description merely states the action without contextual usage cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for a condition: element to appear, text to show, or fixed time.
| Name | Required | Description | Default |
|---|---|---|---|
| ms | No | Wait fixed milliseconds | |
| text | No | Wait for text to appear on page | |
| timeout | No | Max wait time in ms (default: 10000) | |
| selector | No | Wait for element matching selector |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only lists condition types without detailing behavior like combination logic, error handling, or return value. Schema adds timeout default but description adds minimal 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?
Single 11-word sentence, front-loaded with key action and conditions, efficiently conveying purpose without waste.
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 wait tool with 4 params and no output schema, the description lacks context on combining conditions, error behavior, or practical usage scenarios. Schema partially compensates but overall 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?
Schema has 100% description coverage; the description paraphrases schema fields (ms, selector, text) without adding new semantic meaning. Baseline 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 conditions (element, text, fixed time), distinguishing it 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for waiting on page conditions but provides no explicit when-to-use or alternative guidance. No exclusion criteria mentioned.
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.2.0browser_clickbrowser_execute_jsbrowser_get_dombrowser_get_page_infobrowser_hoverbrowser_keypressbrowser_list_tabsbrowser_navigatebrowser_new_tabbrowser_new_tab_groupbrowser_request_userbrowser_screenshotbrowser_scrollbrowser_select_optionbrowser_set_session_namebrowser_switch_tabbrowser_typebrowser_waitEach tool targets a distinct action: clicking, typing, scrolling, DOM inspection, screenshot, tab management, JS execution, user requests, etc. Descriptions clearly differentiate between DOM-based and screenshot-based understanding, and between navigation and interaction primitives.
All tools follow the consistent snake_case pattern with the verb_noun structure and browser_ prefix. There is no mixing of conventions, making names predictable and easy to infer.
18 tools is well-scoped for a browser control server. It covers navigation, interaction, DOM reading, tab management, and special actions like user requests, without being bloated or too sparse.
Obvious gaps exist: no tool to close a tab, no back/forward navigation, and no cookie or storage management. These are standard browser automation operations whose absence will cause agent failures.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Provides cloud browser automation capabilities using Stagehand and Browserbase, enabling LLMs to i…
Browser MCP for logged-in tasks. Uses your Chrome — credentials stay local. Zero-token replay.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/smankoo/open-browser-control'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
