en es ja ko zh

MCP Web Browser Server

Name: MCP Web Browser Server
Author: random-robbie

by random-robbie

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

MCP Web 浏览器服务器

由 Playwright 提供支持的模型上下文协议 (MCP) 的高级 Web 浏览服务器，通过灵活、安全的 API 实现无头浏览器交互。

🌐 功能

无头 Web 浏览：通过 SSL 证书验证绕过导航到任何网站
整页内容提取：检索完整的 HTML 内容，包括动态加载的 JavaScript
多标签支持：创建、管理和在多个浏览器标签之间切换
高级Web交互工具：
- 提取文本内容
- 点击页面元素
- 在表单字段中输入文本
- 截取屏幕截图
- 使用过滤功能提取页面链接
- 向任意方向滚动页面
- 在页面上执行 JavaScript
- 刷新页面
- 等待导航完成
资源管理：闲置后自动清理未使用的资源
增强页面信息：获取有关当前页面的详细元数据

Related MCP server: Cloudflare Playwright MCP

🚀 快速入门

先决条件

Python 3.10+
MCP SDK
剧作家

安装

# Install MCP and Playwright
pip install mcp playwright

# Install browser dependencies
playwright install

Claude Desktop 的配置

添加到您的claude_desktop_config.json ：

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

💡 使用示例

基本网页导航

# 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")

网络互动

# 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")

屏幕截图

# 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")

链接提取

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

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

多标签浏览

# 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)

高级交互

# 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)

🛡️ 安全功能

SSL 证书验证绕过
安全浏览器上下文管理
自定义用户代理配置
错误处理和全面日志记录
可配置超时设置
CSP旁路控制
防止 cookie 被窃取

🔧 故障排除

常见问题

SSL 证书错误：自动绕过
页面加载缓慢：调整browse_to()方法中的超时时间
未找到元素：仔细验证选择器
浏览器资源使用情况：闲置一段时间后自动清理

日志记录

所有重要事件均记录详细信息，以便于调试。

📋 工具参数

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

url ：要导航到的网站
context ：可选上下文对象（当前未使用）

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

selector ：可选的 CSS 选择器，用于提取特定内容
context ：可选上下文对象（当前未使用）

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

selector ：要点击的元素的 CSS 选择器
context ：可选上下文对象（当前未使用）

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

full_page ：捕获整个页面截图
selector ：屏幕截图的可选元素
context ：可选上下文对象（当前未使用）

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

filter_pattern ：用于过滤链接的可选文本模式
context ：可选上下文对象（当前未使用）

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

selector ：输入元素的 CSS 选择器
text ：要输入的文本
context ：可选上下文对象（当前未使用）

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

url ：在新标签页中导航到的可选 URL
context ：可选上下文对象（当前未使用）

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

tab_id ：要切换到的选项卡的 ID
context ：可选上下文对象（当前未使用）

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

context ：可选上下文对象（当前未使用）

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

tab_id ：要关闭的选项卡的可选 ID（默认为当前选项卡）
context ：可选上下文对象（当前未使用）

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

context ：可选上下文对象（当前未使用）

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

context ：可选上下文对象（当前未使用）

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

direction ：滚动方向（‘向上’，‘向下’，‘向左’，‘向右’）
amount ：滚动量（‘页’、‘一半’或数字）
context ：可选上下文对象（当前未使用）

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

timeout_ms ：等待的最长时间（以毫秒为单位）
context ：可选上下文对象（当前未使用）

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

script ：要执行的 JavaScript 代码
context ：可选上下文对象（当前未使用）

🤝 贡献

欢迎贡献代码！欢迎提交 Pull 请求。

开发设置

# 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]

📄 许可证

MIT 许可证

🔗 相关项目

💬 支持

如有问题或疑问，请在 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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

6 tool updatesAug 18, 2025
- First observedbrowse_to
- First observedclick_element
- First observedextract_text_content
- First observedget_page_links
- First observedget_page_screenshots
- First observedinput_text

Install Server

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

TDQS

A3.7/5.0

Scored 2026-04-18 11:45 across 6 tools

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

ResponsivenessNo issues

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
Hosted browser for AI agents: screenshots, post-JS DOM, console, WCAG. No install, no API key.
Browser Automation Testing & QA Tools
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
scrapeless-mcp-server
io.github.scrapeless-ai
Web search, browser automation, scraping, crawling and CAPTCHA solving for AI agents.
Browser Automation Web Scraping Search
1168
agent-web-actions
com.trycloudflare.clients-involving-billion-headers
Stealth web automation for AI agents. Login, signup, navigate, screenshot.
Browser Automation Web Scraping
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
7,953
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)
7
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

MCP Web 浏览器服务器

🌐 功能

🚀 快速入门

先决条件

安装

Claude Desktop 的配置

💡 使用示例

基本网页导航

网络互动

屏幕截图

链接提取

多标签浏览

高级交互

🛡️ 安全功能

🔧 故障排除

常见问题

日志记录

📋 工具参数

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)

🤝 贡献

开发设置

📄 许可证

🔗 相关项目

💬 支持

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

`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)`