What can you do with this server?

The MCP Web Browser Server is an advanced tool for automated web interactions and content extraction using headless browsing (Playwright). You can: * Navigate websites: Browse to URLs and retrieve HTML content * Extract content: Capture text from pages or specific elements using CSS selectors * Interact with pages: Click elements and input text into form fields * Capture screenshots: Take full-page or element-specific screenshots * Manage links: Extract and optionally filter links from the current page * Control navigation: Scroll pages, refresh, wait for navigation to complete * Execute JavaScript: Run custom code on the page * Manage tabs: Create, list, switch between, and close browser tabs * Configure settings: Custom user-agents, SSL validation bypass, CSP control * Handle resources: Automatic cleanup and timeout configuration

Which integrations are available for this server?

Enables execution of JavaScript code on web pages through the execute_javascript method, allowing interaction with dynamic web content.

How do I use MCP Web Browser 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., "@MCP Web Browser Server go to github.com and take a screenshot of the trending page" 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.

en es ja ko zh

MCP Web Browser Server

by random-robbie

Overview Schema Related Servers Score Discussions

Python

Local

MCP Web Browser Server

An advanced web browsing server for the Model Context Protocol (MCP) powered by Playwright, enabling headless browser interactions through a flexible, secure API.

🌐 Features

Headless Web Browsing: Navigate to any website with SSL certificate validation bypass
Full Page Content Extraction: Retrieve complete HTML content, including dynamically loaded JavaScript
Multi-Tab Support: Create, manage, and switch between multiple browser tabs
Advanced Web Interaction Tools:
- Extract text content
- Click page elements
- Input text into form fields
- Capture screenshots
- Extract page links with filtering capabilities
- Scroll pages in any direction
- Execute JavaScript on pages
- Refresh pages
- Wait for navigation to complete
Resource Management: Automatic cleanup of unused resources after inactivity
Enhanced Page Information: Get detailed metadata about the current page

Related MCP server: Cloudflare Playwright MCP

🚀 Quick Start

Prerequisites

Python 3.10+
MCP SDK
Playwright

Installation

# Install MCP and Playwright
pip install mcp playwright

# Install browser dependencies
playwright install

Configuration for Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "web-browser": {
      "command": "python",
      "args": [
        "/path/to/your/server.py"
      ]
    }
  }
}

💡 Usage Examples

# Browse to a website
page_content = browse_to("https://example.com")

# Extract page text
text_content = extract_text_content()

# Extract text from a specific element
title_text = extract_text_content("h1.title")

Web Interaction

# Navigate to a page
browse_to("https://example.com/login")

# Input text into a form
input_text("#username", "your_username")
input_text("#password", "your_password")

# Click a login button
click_element("#login-button")

Screenshot Capture

# Capture full page screenshot
full_page_screenshot = get_page_screenshots(full_page=True)

# Capture specific element screenshot
element_screenshot = get_page_screenshots(selector="#main-content")

Link Extraction

# Get all links on the page
page_links = get_page_links()

# Get links matching a pattern
filtered_links = get_page_links(filter_pattern="contact")

Multi-Tab Browsing

# Create a new tab
tab_id = create_new_tab("https://example.com")

# Create another tab
another_tab_id = create_new_tab("https://example.org")

# List all open tabs
tabs = list_tabs()

# Switch between tabs
switch_tab(tab_id)

# Close a tab
close_tab(another_tab_id)

Advanced Interactions

# Scroll the page
scroll_page(direction="down", amount="page")

# Execute JavaScript on the page
result = execute_javascript("return document.title")

# Get detailed page information
page_info = get_page_info()

# Refresh the current page
refresh_page()

# Wait for navigation to complete
wait_for_navigation(timeout_ms=5000)

🛡️ Security Features

SSL certificate validation bypass
Secure browser context management
Custom user-agent configuration
Error handling and comprehensive logging
Configurable timeout settings
CSP bypass control
Protection against cookie stealing

🔧 Troubleshooting

Common Issues

SSL Certificate Errors: Automatically bypassed
Slow Page Load: Adjust timeout in browse_to() method
Element Not Found: Verify selectors carefully
Browser Resource Usage: Auto-cleanup after inactivity period

Logging

All significant events are logged with detailed information for easy debugging.

📋 Tool Parameters

`browse_to(url: str, context: Optional[Any] = None)`

url: Website to navigate to
context: Optional context object (currently unused)

`extract_text_content(selector: Optional[str] = None, context: Optional[Any] = None)`

selector: Optional CSS selector to extract specific content
context: Optional context object (currently unused)

`click_element(selector: str, context: Optional[Any] = None)`

selector: CSS selector of the element to click
context: Optional context object (currently unused)

`get_page_screenshots(full_page: bool = False, selector: Optional[str] = None, context: Optional[Any] = None)`

full_page: Capture entire page screenshot
selector: Optional element to screenshot
context: Optional context object (currently unused)

`get_page_links(filter_pattern: Optional[str] = None, context: Optional[Any] = None)`

filter_pattern: Optional text pattern to filter links
context: Optional context object (currently unused)

`input_text(selector: str, text: str, context: Optional[Any] = None)`

selector: CSS selector of input element
text: Text to input
context: Optional context object (currently unused)

`create_new_tab(url: Optional[str] = None, context: Optional[Any] = None)`

url: Optional URL to navigate to in the new tab
context: Optional context object (currently unused)

`switch_tab(tab_id: str, context: Optional[Any] = None)`

tab_id: ID of the tab to switch to
context: Optional context object (currently unused)

`list_tabs(context: Optional[Any] = None)`

context: Optional context object (currently unused)

`close_tab(tab_id: Optional[str] = None, context: Optional[Any] = None)`

tab_id: Optional ID of the tab to close (defaults to current tab)
context: Optional context object (currently unused)

`refresh_page(context: Optional[Any] = None)`

context: Optional context object (currently unused)

`get_page_info(context: Optional[Any] = None)`

context: Optional context object (currently unused)

`scroll_page(direction: str = "down", amount: str = "page", context: Optional[Any] = None)`

direction: Direction to scroll ('up', 'down', 'left', 'right')
amount: Amount to scroll ('page', 'half', or a number)
context: Optional context object (currently unused)

`wait_for_navigation(timeout_ms: int = 10000, context: Optional[Any] = None)`

timeout_ms: Maximum time to wait in milliseconds
context: Optional context object (currently unused)

`execute_javascript(script: str, context: Optional[Any] = None)`

script: JavaScript code to execute
context: Optional context object (currently unused)

🤝 Contributing

Contributions are welcome! Please feel free to submit a Pull Request.

Development Setup

# Clone the repository
git clone https://github.com/random-robbie/mcp-web-browser.git

# Create virtual environment
python -m venv venv
source venv/bin/activate  # On Windows use `venv\Scripts\activate`

# Install dependencies
pip install -e .[dev]

📄 License

MIT License

💬 Support

For issues and questions, please open an issue on GitHub.

Available Tools

6 tools

browse_toA

Navigate to a specific URL and return the page's HTML content.

Args:
    url: The full URL to navigate to
    context: Optional context object for logging (ignored)

Returns:
    The full HTML content of the page

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes
`context`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/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 of behavioral disclosure. It mentions navigation and returning HTML content, but fails to describe critical behaviors such as timeouts, error handling, JavaScript execution, or network conditions. This leaves significant gaps for a tool that interacts with external resources.

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 front-loaded with the core purpose, followed by structured sections for arguments and returns. Every sentence adds value without redundancy, making it efficient and easy to parse. The formatting enhances readability without unnecessary verbosity.

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 complexity (external navigation) and lack of annotations, the description is moderately complete but has gaps. It explains the return value, and an output schema exists, so return details aren't needed. However, it omits behavioral aspects like performance or security considerations, which are important for such a tool.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate. It explains the 'url' parameter's purpose ('full URL to navigate to') and notes that 'context' is optional and ignored for logging, adding meaningful semantics beyond the bare schema. However, it doesn't detail URL format requirements or context structure.

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 specific action ('Navigate to a specific URL') and resource ('page's HTML content'), distinguishing it from siblings like click_element or input_text that perform different browser interactions. It precisely defines the tool's function without being vague or tautological.

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 implies usage for retrieving HTML content from URLs, which provides clear context, but it doesn't explicitly state when to use this tool versus alternatives like get_page_links or extract_text_content. No misleading guidance is present, but it lacks explicit exclusions or named alternatives.

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

click_elementC

Click an element on the current page.

Args:
    selector: CSS selector for the element to click
    context: Optional context object for logging (ignored)

Returns:
    Confirmation message or error details

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes
`context`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action is 'click' but doesn't mention what happens if the element isn't found, if the page needs to be loaded first, if there are timing considerations, or what errors might occur. This leaves significant gaps for a tool that performs UI interactions.

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 appropriately sized with a clear purpose statement followed by parameter and return value sections. Each sentence adds value, though the 'context' explanation could be more precise about why it's included if ignored.

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 that this is a UI interaction tool with no annotations and 2 parameters (one with 0% schema coverage), the description is minimally adequate. It explains the basic purpose and parameters but lacks crucial behavioral context about error conditions, prerequisites, and interaction patterns. The presence of an output schema helps but doesn't fully compensate for missing operational details.

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 0%, so the description must compensate. It explains that 'selector' is a 'CSS selector for the element to click' and that 'context' is 'optional... for logging (ignored)', which adds meaningful semantics beyond the bare schema. However, it doesn't provide examples of valid selectors or explain what 'ignored' means operationally.

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 an element') and the target ('on the current page'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from potential sibling tools like 'input_text' or 'browse_to' that might also interact with page elements, missing full sibling differentiation.

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 like 'input_text' for text entry or 'browse_to' for navigation. It mentions the context parameter is 'ignored' but doesn't explain when this tool is appropriate versus other interaction methods.

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

extract_text_contentA

Extract text content from the current page, optionally using a CSS selector.

Args:
    selector: Optional CSS selector to target specific elements
    context: Optional context object for logging (ignored)

Returns:
    Extracted text content

ParametersJSON Schema

Name	Required	Description	Default
`selector`	No
`context`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.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 full burden. It mentions the tool extracts text and that 'context' is ignored, but lacks details on behavioral traits such as error handling (e.g., if selector fails), performance (e.g., timeouts), or output format specifics (though output schema exists). It doesn't disclose permissions, rate limits, or side effects.

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

Conciseness5/5

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

The description is front-loaded with the core purpose in the first sentence, followed by structured Args and Returns sections. Every sentence earns its place by explaining parameters and return value efficiently, with no redundant information.

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 2 parameters with 0% schema coverage, no annotations, and an output schema (which handles return values), the description is mostly complete. It covers purpose and parameter semantics adequately but lacks behavioral details like error cases or performance constraints, which would be beneficial for a tool interacting with web pages.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining 'selector' as 'Optional CSS selector to target specific elements' and 'context' as 'Optional context object for logging (ignored)', which clarifies their purposes beyond the schema's basic types. However, it doesn't detail selector syntax or context structure.

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 'extract' and resource 'text content from the current page', specifying it can optionally use a CSS selector. This distinguishes it from siblings like browse_to (navigation), click_element (interaction), get_page_links (link extraction), get_page_screenshots (visual capture), and input_text (text entry).

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 by mentioning 'optionally using a CSS selector' and 'from the current page', suggesting it's for extracting text after navigation. However, it doesn't explicitly state when to use this versus alternatives like get_page_links (for links) or when not to use it (e.g., for non-text content). No explicit alternatives or exclusions are provided.

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

get_page_linksB

Extract all links from the current page.

Args:
    context: Optional context object for logging (ignored)

Returns:
    List of links found on the page

ParametersJSON Schema

Name	Required	Description	Default
`context`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Extract all links') but lacks critical details: whether this requires page interaction, if it works on any loaded page, potential rate limits, error handling, or what 'current page' means in context. The return format is mentioned but without specifics like link structure or pagination.

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 highly concise and well-structured: a clear purpose statement followed by brief, bullet-like sections for Args and Returns. Every sentence earns its place with no redundant information, making it easy to scan and understand quickly.

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 moderate complexity (extracting links from a page), no annotations, and an output schema present (which handles return values), the description is minimally adequate. It covers the basic purpose and parameter semantics but lacks behavioral context and usage guidelines, leaving gaps for an agent to operate effectively.

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 description adds meaningful context for the single parameter: it explains that 'context' is optional and for logging purposes only, and explicitly states it's ignored. Since schema description coverage is 0% and there's only one parameter, this adequately compensates, though it doesn't detail logging specifics.

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's purpose with a specific verb ('Extract') and resource ('all links from the current page'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'extract_text_content' or 'get_page_screenshots', which prevents a perfect score.

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 doesn't mention prerequisites (e.g., needing to be on a page first), compare to siblings like 'extract_text_content' for non-link content, or specify use cases (e.g., for navigation vs. analysis).

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

get_page_screenshotsA

Capture screenshot of the current page.

Args:
    full_page: Whether to capture the entire page or just the viewport
    selector: Optional CSS selector to screenshot a specific element
    context: Optional context object for logging (ignored)

Returns:
    Base64 encoded screenshot image

ParametersJSON Schema

Name	Required	Description	Default
`full_page`	No
`selector`	No
`context`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

With no annotations provided, the description carries full burden. It discloses that the tool captures screenshots and returns base64 encoded images, but doesn't mention behavioral aspects like whether it requires page load completion, handles dynamic content, has size limitations, or potential performance impacts. The 'context' parameter is noted as 'ignored', which is useful 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 efficiently structured with a clear purpose statement followed by organized Args and Returns sections. Every sentence adds value: the first states the action, and the parameter explanations are necessary for understanding usage. No wasted 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?

Given the tool's moderate complexity (screenshot capture with options), no annotations, and an output schema (implied by 'Returns' statement), the description is reasonably complete. It covers purpose, parameters, and return format. However, it lacks some behavioral context like prerequisites (e.g., page must be loaded) or limitations.

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?

With 0% schema description coverage, the description compensates well by explaining all three parameters: 'full_page' (entire page vs viewport), 'selector' (CSS selector for specific element), and 'context' (ignored for logging). This adds meaningful semantics beyond the bare schema, though it doesn't provide format examples or constraints.

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 specific action ('Capture screenshot') and resource ('of the current page'), distinguishing it from sibling tools like 'get_page_links' or 'extract_text_content' which handle different types of page content extraction.

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 through the parameter explanations (e.g., 'Whether to capture the entire page or just the viewport'), but doesn't explicitly state when to use this tool versus alternatives like 'extract_text_content' for text or 'get_page_links' for links. No explicit when-not-to-use guidance is provided.

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

input_textB

Input text into a specific element on the page.

Args:
    selector: CSS selector for the input element
    text: Text to input
    context: Optional context object for logging (ignored)

Returns:
    Confirmation message

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes
`text`	Yes
`context`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool inputs text and returns a confirmation, but lacks critical details: whether it simulates typing or sets value directly, if it waits for element visibility, error handling for invalid selectors, or side effects. This is inadequate for a mutation tool with zero annotation coverage.

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 highly concise and well-structured. It starts with a clear purpose statement, followed by bullet-point explanations of each parameter and the return value. Every sentence earns its place with no redundant information, making it easy to scan and understand.

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 moderate complexity (3 parameters, mutation operation) and the presence of an output schema (which covers return values), the description is partially complete. It explains parameters well but lacks behavioral context like error conditions or interaction details. With no annotations, it should do more to guide safe usage, but the output schema reduces the need to describe returns.

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 description adds significant value beyond the input schema, which has 0% description coverage. It explains that 'selector' is a 'CSS selector for the input element', 'text' is 'Text to input', and 'context' is 'Optional context object for logging (ignored)'. This clarifies parameter purposes and constraints, compensating well for the schema's lack of descriptions.

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's purpose: 'Input text into a specific element on the page.' This specifies the verb ('input text') and resource ('specific element on the page'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'extract_text_content' or 'click_element', which prevents a perfect score.

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 doesn't mention prerequisites (e.g., needing a page loaded via 'browse_to'), exclusions, or comparisons to other input-related tools. The agent must infer usage from context alone.

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

Install Server

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

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: navigation, clicking, text extraction, link extraction, screenshot capture, and text input. The descriptions reinforce these distinct functions, making it easy for an agent to select the right tool for each task without confusion.

Naming Consistency4/5

The tools follow a consistent verb_noun or verb_adjective_noun pattern (e.g., browse_to, click_element, extract_text_content), with all names using snake_case. The only minor deviation is 'get_page_links' and 'get_page_screenshots' using 'get' instead of a more specific verb like 'extract', but this is still readable and maintains overall consistency.

Tool Count5/5

With 6 tools, this server is well-scoped for basic web browsing automation, covering essential actions like navigation, interaction, and content extraction. Each tool earns its place without being overly complex or insufficient for the domain, making it manageable and effective for typical use cases.

Completeness4/5

The toolset provides solid coverage for core web browsing tasks, including navigation, interaction (clicking and input), and content extraction (text, links, screenshots). A minor gap is the lack of tools for more advanced actions like form submission, scrolling, or handling pop-ups, but agents can likely work around this with the existing tools for most workflows.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Reddit Discussion

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

render-mcp A
io.github.RodRomer
A real browser for AI agents: screenshots, PDFs, post-JS HTML. No API key.
61
ImRonAI-mcp-server-browserbase
ai.smithery
Automate cloud browsers to navigate websites, interact with elements, and extract structured data.…
Browser Automation Web Scraping App Automation
2
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

Related MCP Servers

Playwright MCP Server
Browser Automation Web Scraping Agent Orchestration
lebrodus
A
license
B
quality
D
maintenance
A server that enables browser automation using Playwright, allowing interaction with web pages, capturing screenshots, and executing JavaScript in a browser environment through LLMs.
Updated 2 years ago (2025-01-03 06:24 UTC)
12
18,122
1
MIT
Cloudflare Playwright MCP
Browser Automation Web Scraping
sent3nal
F
license
Not graded
quality
C
maintenance
A server that enables AI assistants to control a browser through tools, allowing them to perform web automation tasks like navigation, typing, clicking, and taking screenshots.
Updated a year ago (2025-06-25 01:27 UTC)
Playwright MCP Server
Browser Automation Web Scraping
Leviathangk
A
license
Not graded
quality
D
maintenance
Enables browser automation and web scraping with multi-session management, supporting page navigation, element interaction, network request capture, and content extraction across multiple concurrent browser instances.
Updated 9 months ago (2025-12-17 13:17 UTC)
9
MIT
Browser MCP
Browser Automation Web Scraping
blink-new
A
license
Not graded
quality
D
maintenance
An MCP server for browser automation using Puppeteer that enables AI assistants to navigate web pages, interact with UI elements, and capture screenshots. It supports comprehensive web tasks including form filling, content extraction, and executing custom JavaScript within the browser context.
Updated 7 months ago (2026-01-29 00:41 UTC)
1
MIT

Appeared in Searches

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/random-robbie/mcp-web-browser'

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

MCP Web Browser Server

🌐 Features

🚀 Quick Start

Prerequisites

Installation

Configuration for Claude Desktop

💡 Usage Examples

Basic Web Navigation

Web Interaction

Screenshot Capture

Link Extraction

Multi-Tab Browsing

Advanced Interactions

🛡️ Security Features

🔧 Troubleshooting

Common Issues

Logging

📋 Tool Parameters

browse_to(url: str, context: Optional[Any] = None)

extract_text_content(selector: Optional[str] = None, context: Optional[Any] = None)

click_element(selector: str, context: Optional[Any] = None)

get_page_screenshots(full_page: bool = False, selector: Optional[str] = None, context: Optional[Any] = None)

get_page_links(filter_pattern: Optional[str] = None, context: Optional[Any] = None)

input_text(selector: str, text: str, context: Optional[Any] = None)

create_new_tab(url: Optional[str] = None, context: Optional[Any] = None)

switch_tab(tab_id: str, context: Optional[Any] = None)

list_tabs(context: Optional[Any] = None)

close_tab(tab_id: Optional[str] = None, context: Optional[Any] = None)

refresh_page(context: Optional[Any] = None)

get_page_info(context: Optional[Any] = None)

scroll_page(direction: str = "down", amount: str = "page", context: Optional[Any] = None)

wait_for_navigation(timeout_ms: int = 10000, context: Optional[Any] = None)

execute_javascript(script: str, context: Optional[Any] = None)

🤝 Contributing

Development Setup

📄 License

🔗 Related Projects

💬 Support

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API

`browse_to(url: str, context: Optional[Any] = None)`

`extract_text_content(selector: Optional[str] = None, context: Optional[Any] = None)`

`click_element(selector: str, context: Optional[Any] = None)`

`get_page_screenshots(full_page: bool = False, selector: Optional[str] = None, context: Optional[Any] = None)`

`get_page_links(filter_pattern: Optional[str] = None, context: Optional[Any] = None)`

`input_text(selector: str, text: str, context: Optional[Any] = None)`

`create_new_tab(url: Optional[str] = None, context: Optional[Any] = None)`

`switch_tab(tab_id: str, context: Optional[Any] = None)`

`list_tabs(context: Optional[Any] = None)`

`close_tab(tab_id: Optional[str] = None, context: Optional[Any] = None)`

`refresh_page(context: Optional[Any] = None)`

`get_page_info(context: Optional[Any] = None)`

`scroll_page(direction: str = "down", amount: str = "page", context: Optional[Any] = None)`

`wait_for_navigation(timeout_ms: int = 10000, context: Optional[Any] = None)`

`execute_javascript(script: str, context: Optional[Any] = None)`