Which integrations are available for this server?

Enables AI image generation using Google Gemini 2.0 Flash, generating custom images from text descriptions. Provides browser automation capabilities using Puppeteer, allowing navigation, screenshot capture, element interaction (clicking, typing, scrolling), and page information retrieval.

How do I use local-browser-mcp-server?

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., "@local-browser-mcp-server Navigate to google.com and take a screenshot" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

local-browser-mcp-server

by botdojo-ai

Overview Schema Related Servers Score Discussions

JavaScript

Local

Local Browser MCP Server

A Model Context Protocol (MCP) server that provides browser automation capabilities using Puppeteer, plus AI image generation using Google Gemini 2.0 Flash. This server allows you to control a local Chrome browser instance, take screenshots, perform interactions like clicking and typing, and generate custom images - perfect for testing websites and creating content with Cursor.

Features

🌐 Browser Navigation: Navigate to URLs, go back/forward, refresh pages
📸 Screenshots: Capture full page, viewport, or specific element screenshots
🖱️ Click Actions: Click on elements using CSS selectors
⌨️ Text Input: Type text into input fields and forms
📜 Scrolling: Scroll pages in any direction
⏳ Wait Operations: Wait for elements to appear
📊 Page Info: Get current page title, URL, and viewport information
🎨 AI Image Generation: Generate custom images using Google Gemini 2.0 Flash Preview

Related MCP server: Puppeteer MCP Server

Installation

Clone/Download this repository to your local machine
Install dependencies:
```
npm install
```
Build the project:
```
npm run build
```
Set up environment variables (for image generation): Create a .env file in the project root:
```
GOOGLE_AI_KEY=your_google_ai_api_key_here
```
Get your API key from Google AI Studio.

Usage with Cursor

Step 1: Start the HTTP Server

The recommended way to use this MCP server is through HTTP mode to avoid ES module compatibility issues:

npm run start:http

This starts the server on http://localhost:3045 and keeps it running.

Step 2: Configure MCP in Cursor

Create or update your cursor-mcp-config.json file with the following configuration:

{
  "mcpServers": {
    "local-browser": {
      "command": "node",
      "args": ["/absolute/path/to/your/project/mcp-http-bridge.js"],
      "env": {
        "NODE_ENV": "production"
      }
    }
  }
}

Important:

Replace /absolute/path/to/your/project/ with the actual absolute path to your project directory
The HTTP bridge (mcp-http-bridge.js) routes MCP requests to the HTTP server
Make sure the HTTP server is running before using the tools in Cursor

Step 3: Restart Cursor

After updating the configuration, restart Cursor to load the new MCP server.

Step 4: Start Using the Tools

Once configured, you can use the following tools in Cursor:

navigate_to_url - Navigate to any URL
go_back - Go back in browser history
go_forward - Go forward in browser history
refresh_page - Refresh the current page

Screenshots & Visual Capture

take_screenshot - Capture screenshots (full page, viewport, or specific elements)

Page Interactions

click_element - Click on elements using CSS selectors
type_text - Type text into input fields
scroll_page - Scroll the page in any direction
wait_for_element - Wait for elements to appear

Page Information

get_page_info - Get current page title, URL, and viewport info

AI Image Generation

generate_image - Generate custom images using Google Gemini 2.0 Flash Preview

Quick Start Example

Here's how to get started quickly:

Start the HTTP server:
```
npm run start:http
```
In Cursor, try these commands:
- "Navigate to google.com and take a screenshot"
- "Generate an image of a sunset over mountains"
- "Click on the search button and type 'hello world'"

Example Workflow

Here's a typical workflow when testing a website you've created:

Navigate to your local development server:

Use navigate_to_url with "http://localhost:3000"

Take a screenshot to see the current state:

Use take_screenshot to capture the full page

Interact with your website:

Use click_element to click buttons
Use type_text to fill out forms
Use scroll_page to test scrolling behavior

Capture results:

Use take_screenshot again to see changes

Tool Reference

navigate_to_url

Navigate the browser to a specific URL.

url (required): The URL to navigate to

take_screenshot

Take a screenshot of the current page.

fullPage (optional): Capture full page vs viewport only
selector (optional): CSS selector to screenshot specific element

click_element

Click on an element specified by CSS selector.

selector (required): CSS selector of element to click
waitFor (optional): Milliseconds to wait after clicking (default: 1000)

type_text

Type text into an input field.

selector (required): CSS selector of input element
text (required): Text to type
clear (optional): Clear field before typing (default: true)

wait_for_element

Wait for an element to appear on the page.

selector (required): CSS selector to wait for
timeout (optional): Timeout in milliseconds (default: 5000)

scroll_page

Scroll the page.

direction (required): 'up', 'down', 'top', or 'bottom'
amount (optional): Pixels to scroll for up/down (default: 500)

get_page_info

Get information about the current page (title, URL, viewport size).

refresh_page

Refresh the current page.

go_back

Navigate back in browser history.

go_forward

Navigate forward in browser history.

generate_image

Generate custom AI images using Google Gemini 2.0 Flash Preview.

description (required): Text description of the image to generate

Generated images are automatically saved to the generated-images/ directory and can be downloaded via HTTP at http://localhost:3045/download/{filename}.

Development

Build: npm run build
Development mode: npm run dev (watches for changes)
Start: npm start (visible browser) or npm run start:headless (background)
HTTP Test Server: npm run start:http (visible) or npm run start:http:headless (background)

Browser Behavior

Visible Mode: Browser window opens so you can see what's happening
Headless Mode: Browser runs in background (set MCP_HEADLESS=true)
Separate Profile: Uses /tmp/chrome-mcp-data to avoid conflicts with your main Chrome
Default viewport: 1280x720 pixels
Screenshots: Returned as base64-encoded PNG images

Troubleshooting

Browser doesn't launch

Ensure Chrome is installed on your system
Check that no other processes are blocking Chrome
Try restarting the HTTP server: npm run start:http
Clear Chrome data directory: rm -rf /private/tmp/chrome-mcp-data

Elements not found

Verify CSS selectors are correct
Use browser dev tools to test selectors
Try waiting for elements to load with wait_for_element

MCP Tools not available in Cursor

Ensure the HTTP server is running: npm run start:http
Check that cursor-mcp-config.json has the correct absolute path
Restart Cursor after configuration changes
Verify the HTTP bridge file exists: mcp-http-bridge.js

Image generation not working

Ensure GOOGLE_AI_KEY is set in your .env file
Get your API key from Google AI Studio
Check that the HTTP server is running (image generation requires HTTP mode)

Permission issues

Ensure the MCP server has permission to launch Chrome
Check file permissions on the built JavaScript files
On macOS, you may need to allow Chrome in System Preferences > Security & Privacy

Security Notes

This server launches a real browser with full system access
Only use with trusted websites and content
The browser runs with some security features disabled for automation
Always run in a controlled environment

License

MIT License - see LICENSE file for details.

Available Tools

11 tools

click_elementC

Click on an element specified by CSS selector

ParametersJSON Schema

Name	Required	Description	Default
`waitFor`	No	Milliseconds to wait after clicking
`selector`	Yes	CSS selector of the element to click

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does not disclose behavior like scrolling into view, error handling if element not found, or the fact that it includes a post-click wait (the waitFor parameter). The description is too minimal for safe autonomous use.

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 with no fluff, but it omits critical context. Conciseness alone does not compensate for incompleteness. It is appropriately sized but not well-structured for clarity.

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 simple interaction tool, the description lacks context about prerequisites (element must exist), error states, and the effect of waitFor. Without an output schema, the agent cannot understand what happens after the action. The description is insufficient for reliable agent decision-making.

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 (selector and waitFor). The tool description adds no additional meaning beyond the schema. Given 100% schema coverage, baseline 3 is appropriate.

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?

The description clearly states the action (click) and the target (element by CSS selector). However, it does not explicitly differentiate from sibling tools like type_text or take_screenshot, but the purpose is immediately understandable.

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. Sibling tools include wait_for_element and scroll_page, but the description does not explain that the element should already be present or visible before clicking.

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

generate_imageA

Generate images using Google Gemini 2.0 Flash Preview Image Generation (requires GOOGLE_AI_KEY environment variable)

ParametersJSON Schema

Name	Required	Description	Default
`description`	Yes	Text description of the image to generate

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description must disclose behavioral traits. It states the generation capability and env var requirement but omits details like output format, size limits, or latency. Adequate but not thorough.

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 that efficiently communicates purpose and a key requirement with zero unnecessary words.

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 tool's simplicity (one parameter, no output schema), the description covers the basics. However, additional context on output or limitations would enhance completeness for a generative AI 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 description coverage is 100% (the single parameter 'description' has a clear description). The tool description adds the env var requirement but no extra semantic meaning for the parameter beyond the schema.

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 explicitly states the tool generates images using a specific model (Google Gemini 2.0 Flash Preview Image Generation), which is a clear verb+resource pairing. It also uniquely distinguishes from sibling browser automation tools.

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

Usage Guidelines4/5

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

The description mentions the required GOOGLE_AI_KEY environment variable, providing a clear prerequisite. While it doesn't explicitly state when to use or avoid this tool, the siblings are all unrelated, making context clear.

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

get_page_infoA

Get information about the current page (title, URL, etc.)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It only mentions retrieving 'title, URL, etc.' without specifying scope, caching, or side effects. The term 'etc.' introduces ambiguity, reducing transparency.

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, efficient sentence that conveys the essential purpose without unnecessary words. It follows the principle of front-loading key information.

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 output schema and a simple tool, the description is vague with 'etc.' and does not enumerate all returned fields (e.g., metadata, maybe more). This leaves the agent uncertain about the exact output structure, especially compared to other similar tools that might have detailed output.

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?

The tool has no parameters, so schema coverage is 100%. By the rule, a tool with 0 parameters should receive a baseline score of 4 for this dimension. The description adds no parameter information, but none is needed.

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's purpose: 'Get information about the current page (title, URL, etc.)'. It uses a specific verb ('Get') and resource ('information about the current page'), effectively distinguishing it from sibling tools like click_element or navigate_to_url.

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 implies when to use (when page info is needed) but lacks explicit guidance on when not to use or alternatives. No exclusions or sibling comparisons are provided, making it minimally adequate.

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

go_backA

Navigate back in browser history

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It states a straightforward action but does not disclose what happens if there is no history or any other behavioral details. Adequate for a simple action.

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, no wasted words. Perfectly concise for the action described.

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 parameters, no output schema, and a simple action, the description is mostly complete. It could mention what happens if there is no browser history, but overall adequate.

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?

The tool has zero parameters, and the schema coverage is 100%. The description adds no parameter information, but none is needed. Baseline 4 applies per rubric.

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 explicitly states the action ('Navigate back in browser history') and clearly distinguishes from sibling tools like 'go_forward' (forward navigation) and 'navigate_to_url' (specific URL navigation).

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 implies usage for going back in history but does not provide when-to-use or when-not-to-use guidance, nor does it mention alternative tools. Context is clear but lacks exclusions.

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

go_forwardA

Navigate forward in browser history

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It does not disclose behavior when no forward history exists, error handling, or any 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?

The description is a single, clear sentence with no wasted words, front-loading the core action.

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 zero-parameter tool, the description covers the basic purpose but lacks detail on return values or error conditions, leaving some gaps.

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?

There are no parameters, and schema coverage is 100%. The description adds no parameter information, which is acceptable given the absence of parameters, so the baseline of 4 applies.

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 verb 'Navigate' and the resource 'forward in browser history', distinguishing it from the sibling tool 'go_back'.

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 'go_back' or 'navigate_to_url', nor does it mention prerequisites such as the availability of forward history.

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

navigate_to_urlB

Navigate the browser to a specific URL

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	The URL to navigate to

TDQS

B3.4/5.0

Behavior2/5

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

Without annotations, the description must disclose behavior. It only states the basic function, omitting details like whether it waits for page load, 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 with clear front-loaded action and object. No 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 simple navigation tool with no output schema and one parameter, the description is mostly complete. It could mention navigation completion behavior but is sufficient for basic use.

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 baseline 3 applies. The description adds no extra meaning beyond the schema's parameter description, but that is acceptable for a simple parameter.

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 target (browser to a specific URL), distinguishing it from sibling tools like go_back or go_forward which handle session history.

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. It does not mention scenarios where go_back or go_forward might be preferable, nor prerequisites or context.

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

refresh_pageA

Refresh the current page

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden. It simply states the action without disclosing behavioral traits like whether the page state is reset, scroll position is lost, or if authentication is required.

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, short sentence with no superfluous words. It is appropriately concise for the tool's simplicity.

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 action with no parameters or output schema, the description is minimally adequate. However, it could mention that the page reloads and any unsaved data may be lost.

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?

The tool has zero parameters and schema coverage is 100%. The description adds no parameter information because none is needed. Baseline 4 applies.

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 'Refresh the current page' is a specific verb+resource pairing. It clearly distinguishes from sibling tools like go_back, go_forward, and navigate_to_url, which perform different navigation actions.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, side effects, 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.

scroll_pageC

Scroll the page up or down

ParametersJSON Schema

Name	Required	Description	Default
`amount`	No	Amount to scroll in pixels (ignored for top/bottom)
`direction`	Yes	Direction to scroll

TDQS

C2.9/5.0

Behavior2/5

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

The description lacks detail on behavioral aspects such as whether scrolling is smooth or instant, how it interacts with page overflow, or any side effects. It does not disclose the amount parameter's behavior for top/bottom beyond what the schema says.

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 extremely concise with one sentence. It is front-loaded with the core action, but could include the top/bottom options without losing clarity.

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?

The tool is simple with no output schema, but the description does not confirm return values or side effects. It is adequate for a basic scroll but lacks completeness for an agent to fully understand behavior.

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 provides full coverage (100%) for both parameters with descriptions. The tool description adds no additional semantic context beyond the schema, so it meets the baseline.

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?

The description clearly states the tool scrolls a page, which is distinct from sibling tools like click_element or navigate_to_url. However, it omits the top/bottom options from the description, relying on the schema to convey that.

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 guidelines are provided on when to use this tool versus alternatives. There is no mention of prerequisites, scenarios, or when not to use it, which would help an agent decide.

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

take_screenshotB

Take a screenshot of the current page

ParametersJSON Schema

Name	Required	Description	Default
`fullPage`	No	Whether to capture the full page or just the viewport
`selector`	No	CSS selector to screenshot a specific element

TDQS

B3.2/5.0

Behavior2/5

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

No annotations exist, so description must carry full behavioral burden. It lacks details on side effects, return type (e.g., format of screenshot), permissions needed, or limitations (e.g., if page is not fully loaded). Only states action, not implications.

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, no fluff. However, it could include more detail without being overly verbose. It is concise but slightly under-specified.

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?

Tool is simple with 2 optional params and no output schema. Description lacks completeness about output format, error handling, and whether it works on all pages. Acceptable for a simple tool but could be more thorough.

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% with descriptions for both parameters. Description does not add additional context beyond schema. Baseline of 3 is appropriate as the schema already explains parameters adequately.

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 tool captures a screenshot of the current page. The verb 'Take' and resource 'screenshot' are specific, and it distinguishes from sibling tools like 'click_element' or 'navigate_to_url'.

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 vs alternatives. For instance, it doesn't explain when to capture full page vs viewport, or how 'selector' differs from default. Sibling tools are listed but not compared.

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

type_textA

Type text into an input field specified by CSS selector

ParametersJSON Schema

Name	Required	Description
`text`	Yes	Text to type into the element
`clear`	No	Whether to clear the field before typing
`selector`	Yes	CSS selector of the input element

TDQS

A3.8/5.0

Behavior3/5

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

No annotations exist, so description carries full burden. It mentions typing text but fails to disclose whether it clears the field (only the parameter does), triggers events, or waits for elements.

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, 10 words, front-loaded with purpose. No redundancy.

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 3 parameters and no annotations, the description is succinct but missing behavioral details like default clearing. Still adequate for a simple action in a browser automation context.

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%, so baseline is 3. The description adds no extra meaning beyond 'type text' and 'CSS selector', not mentioning the clear parameter.

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 (type text), target (input field), and identification method (CSS selector). It distinguishes well from sibling tools like click_element.

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 implies usage for typing into fields but does not explicitly state when to use this tool over alternatives, nor does it mention 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.

wait_for_elementB

Wait for an element to appear on the page

ParametersJSON Schema

Name	Required	Description	Default
`timeout`	No	Timeout in milliseconds
`selector`	Yes	CSS selector of the element to wait for

TDQS

B3/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It fails to mention what happens on timeout, whether the element must be visible, or any return value. The default timeout is in schema but not described.

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 single sentence is concise but under-specified. It lacks important behavioral details that would justify a higher score for completeness.

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 output schema, the description should explain results (e.g., returns element or times out). It does not address return behavior or integration with sibling tools like click_element, making it incomplete.

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% and both parameters have descriptions. The description adds no new information beyond 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 verb 'wait' and the resource 'element on the page', effectively conveying the tool's purpose. It is distinct from sibling tools like click_element, navigate_to_url, etc.

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, such as prerequisites (e.g., page must be loaded) or when alternatives like check_element might be preferred. The description lacks context for appropriate usage.

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

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.0.0Jun 27, 2026
- First observedclick_element
- First observedgenerate_image
- First observedget_page_info
- First observedgo_back
- First observedgo_forward
- First observednavigate_to_url
- First observedrefresh_page
- First observedscroll_page
- First observedtake_screenshot
- First observedtype_text
- First observedwait_for_element

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 distinct purpose: clicking, navigating, scrolling, typing, waiting, etc. No two tools overlap in functionality, even the optional image generation is separate. Agents can easily distinguish them.

Naming Consistency5/5

All tools use snake_case with a consistent verb_noun pattern (e.g., click_element, navigate_to_url, take_screenshot). The naming is uniform and predictable, making it easy for agents to infer functionality.

Tool Count5/5

11 tools is well-scoped for a browser automation server, covering essential actions without being excessive. Each tool serves a clear role in the workflow.

Completeness4/5

The tool set covers core browser automation tasks (navigation, clicking, typing, scrolling, screenshots, page info, waiting). Minor gaps include lack of text extraction from elements or page source retrieval, but these are not critical for common workflows.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

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

browserbasehq-mcp-browserbaseOAuth
ai.smithery
Provides cloud browser automation capabilities using Stagehand and Browserbase, enabling LLMs to i…
Browser Automation Web Scraping Agent Orchestration
23,406
agent-web-actions
com.trycloudflare.clients-involving-billion-headers
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Browser Automation Web Scraping
2
agent-web-actions
com.trycloudflare.plates-spread-materials-optimum
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Browser Automation Agent Orchestration
2
SkyvernOAuth
io.github.Skyvern-AI
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
Browser Automation Web Scraping App Automation
222,930

Related MCP Servers

Puppeteer MCP Server
Browser Automation Web Scraping Agent Orchestration
jwaldor
A
license
C
quality
D
maintenance
Enables LLMs to perform web browsing tasks, take screenshots, and execute JavaScript using Puppeteer for browser automation.
Updated 2 years ago (2025-01-13 19:55 UTC)
4
28,366
1
MIT
Puppeteer MCP Server
Browser Automation Web Scraping
merajmehrabi
A
license
A
quality
B
maintenance
Enables browser automation with Puppeteer, supporting navigation, form interactions, and connection to active Chrome instances for comprehensive web page interaction.
Updated a year ago (2025-03-14 00:12 UTC)
8
2,359
482
MIT
Puppeteer MCP Server
Browser Automation Web Scraping App Automation
andytango
A
license
B
quality
D
maintenance
Enables AI agents to automate browser interactions including navigation, content extraction, form filling, screenshots, and JavaScript execution across multiple tabs using Puppeteer.
Updated 9 months ago (2025-12-03 16:54 UTC)
27
48
1
MIT
Puppeteer MCP Server
Browser Automation Web Scraping
lijingle1
A
license
Not graded
quality
D
maintenance
Enables LLMs to perform browser automation including web navigation, element interaction, and screenshot capture using Puppeteer. It provides capabilities for executing JavaScript in the browser and monitoring console logs for debugging and data extraction.
Updated a year ago (2025-08-20 17:13 UTC)
28,366
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/botdojo-ai/local-browser-mcp-server'

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

Local Browser MCP Server

Features

Installation

Usage with Cursor

Step 1: Start the HTTP Server

Step 2: Configure MCP in Cursor

Step 3: Restart Cursor

Step 4: Start Using the Tools

Browser Navigation

Screenshots & Visual Capture

Page Interactions

Page Information

AI Image Generation

Quick Start Example

Example Workflow

Tool Reference

navigate_to_url

take_screenshot

click_element

type_text

wait_for_element

scroll_page

get_page_info

refresh_page

go_back

go_forward

generate_image

Development

Browser Behavior

Troubleshooting

Browser doesn't launch

Elements not found

MCP Tools not available in Cursor

Image generation not working

Permission issues

Security Notes

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API