How do I use browser-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@browser-mcp Get the HTML and CSS from example.com" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

browser-mcp

by hupeng9995

Overview Schema Related Servers Score Discussions

JavaScript

Local

🌐 Browser MCP Server

License: MIT Node.js Version MCP Version

A powerful MCP tool for UI designers and developers to extract, analyze, and clone website front-end code (HTML, CSS) with pixel-perfect accuracy.

English | 中文文档

✨ What's New in v2.0

🎉 Major Upgrade! The v2.0 release includes 8 powerful new features:

🖱️ User Interaction Support - Visual browser mode for handling logins and interactions
🎨 Smart Component CSS Extraction - Auto-generate ready-to-use component code
📦 Resource Downloader - Actually download images, fonts, and CSS files to local disk
🎨 Color Palette Extraction - Extract all colors used in the page
📱 Responsive Analysis - Detect CSS breakpoints and responsive design patterns
🔢 Batch Element Extraction - Extract multiple elements in one call
🎯 Interactive Element Analysis - Analyze buttons, forms, and interactive components
📸 Enhanced Screenshots - More flexible screenshot options with quality control

See full upgrade details →

Related MCP server: mcp-page-capture

🎯 专为UI设计师打造

专业的浏览器MCP工具，用于完整抓取和分析网站的前端代码（HTML、CSS等），实现一比一网站UI还原。

🎯 核心特性

完整HTML源码获取 - 获取页面完整的HTML结构
真实CSS样式提取 - 获取计算后的CSS样式（computed styles），而非AI猜测
CSS类完整分析 - 提取所有CSS类定义和使用情况
静态资源下载 - 批量获取CSS、字体、图片等资源URL
布局结构分析 - 分析Flexbox、Grid等现代布局
字体信息提取 - 获取所有@font-face和使用的字体
元素精确定位 - 通过CSS选择器精确获取任何元素的样式
自定义脚本执行 - 在页面中执行JavaScript获取运行时数据

📦 安装

1. 安装依赖

npm install

2. 安装Chromium浏览器

npm run install-browser

或者手动安装：

npx playwright install chromium

🚀 使用方法

在Claude Desktop中配置

编辑Claude Desktop配置文件：

Windows: %APPDATA%\Claude\claude_desktop_config.json macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Linux: ~/.config/Claude/claude_desktop_config.json

添加以下配置：

{
  "mcpServers": {
    "browser": {
      "command": "node",
      "args": ["/path/to/browser-mcp/browser-mcp-server-v2.js"]
    }
  }
}

💡 提示: 替换 /path/to/browser-mcp/ 为你的实际安装路径 🔄 v1 升级: 如果你还在使用 v1，将 browser-mcp-server.js 改为 browser-mcp-server-v2.js

重启Claude Desktop后即可使用。

🛠️ 可用工具

1. `navigate`

访问指定的URL网页

{
  "url": "https://example.com",
  "waitUntil": "networkidle"  // 可选: load, domcontentloaded, networkidle
}

2. `get_page_source`

获取当前页面的完整HTML源码

3. `get_element_styles`

获取指定元素的所有CSS样式（包括计算后的样式）

{
  "selector": ".header",
  "includeComputed": true  // 默认true
}

4. `get_all_stylesheets`

获取页面所有CSS样式表的内容（包括外部和内联）

{
  "includeInline": true  // 默认true
}

5. `extract_css_classes`

提取页面中所有CSS类的定义和使用情况

6. `get_element_by_selector`

通过CSS选择器获取元素的HTML和样式信息

{
  "selector": "#main-content",
  "includeChildren": false  // 默认false
}

7. `download_assets`

获取页面所有静态资源的URL列表

{
  "types": ["css", "font", "image"]  // 或 ["all"]
}

8. `analyze_layout`

分析页面布局结构（Flexbox、Grid等）

{
  "selector": ".container"  // 可选，不填则分析整个页面
}

9. `get_fonts`

获取页面使用的所有字体信息

10. `screenshot`

对当前页面或指定元素截图

{
  "selector": ".hero-section",  // 可选
  "fullPage": false  // 默认false
}

11. `execute_script`

在页面中执行自定义JavaScript代码

{
  "script": "return document.title"
}

💡 使用场景示例

场景1: 完整复制一个网站的导航栏

1. 访问目标网站: navigate(url: "https://example.com")
2. 获取导航栏元素: get_element_by_selector(selector: "nav", includeChildren: true)
3. 提取所有CSS类: extract_css_classes()
4. 下载字体和图标: download_assets(types: ["font", "image"])

场景2: 分析某个页面的布局系统

1. 访问页面: navigate(url: "https://example.com")
2. 分析布局: analyze_layout()
3. 获取所有样式表: get_all_stylesheets()

场景3: 提取特定组件的完整样式

1. 访问页面: navigate(url: "https://example.com")
2. 定位组件: get_element_by_selector(selector: ".card-component", includeChildren: true)
3. 获取样式: get_element_styles(selector: ".card-component")

⚙️ 技术栈

MCP SDK: Model Context Protocol官方SDK
Playwright: 浏览器自动化引擎
Node.js: v18+

🔒 安全说明

本工具仅用于学习和参考，请尊重网站的版权和使用条款
使用时请遵守目标网站的robots.txt和服务条款
不建议用于商业抄袭用途

📝 注意事项

跨域CSS问题: 某些跨域加载的CSS文件可能无法直接读取内容，工具会自动跳过
动态内容: 工具支持等待页面完全加载（包括AJAX内容）
性能: 首次启动会下载Chromium浏览器（约150MB）

🐛 故障排除

无法安装Chromium

# 手动指定代理
set HTTPS_PROXY=http://your-proxy:port
npm run install-browser

Node版本过低

确保使用Node.js 18或更高版本：

node --version

📝 许可证

MIT License - 查看 LICENSE 文件了解详情。

🤝 贡献

欢迎提交Issue和Pull Request！

如何贡献

Fork 这个仓库
创建你的特性分支 (git checkout -b feature/AmazingFeature)
提交你的修改 (git commit -m 'Add some AmazingFeature')
推送到分支 (git push origin feature/AmazingFeature)
打开一个Pull Request

⭐ Star History

如果这个项目对你有帮助，请给我们一个 Star ⭐！

🙏 鸣谢

Model Context Protocol - 提供了MCP标准和SDK
Playwright - 强大的浏览器自动化引擎
所有贡献者们的支持和反馈

Made with ❤️ by Browser MCP Contributors

Available Tools

11 tools

analyze_layoutB

分析页面布局结构（Flexbox、Grid等）

ParametersJSON Schema

Name	Required	Description	Default
`selector`	No	CSS选择器，分析特定元素的布局（可选，默认分析整个页面）

TDQS

B3.3/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 does not disclose behavioral traits such as read-only nature, performance impact, or what exactly is analyzed (e.g., returned data format). The minimal description leaves agents uninformed about side effects or resource usage.

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

Conciseness4/5

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

The description is a single sentence that is front-loaded and efficient. It avoids waste, though could be more informative without sacrificing conciseness.

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

Completeness2/5

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

Given the complexity of layout analysis, the description is overly minimal. It lacks details about output, scope, and what specific layout properties are analyzed. No output schema is provided, and the description does not compensate.

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 has 100% coverage with a single parameter 'selector' described as optional. The tool description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool analyzes page layout structure, specifically mentioning Flexbox and Grid. It distinguishes from siblings like get_element_styles and get_all_stylesheets, which focus on individual elements or styles.

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 lacks explicit guidance on when to use this tool versus alternatives. It implies usage for layout analysis but provides no when-not-to or context for selection among sibling tools.

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

download_assetsA

获取页面所有静态资源的URL列表（CSS、字体、图片等）

ParametersJSON Schema

Name	Required	Description	Default
`types`	No	资源类型：css, font, image, all（默认：all）

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided. The description states it returns a URL list, but does not clarify that it does not actually download the files (despite the name 'download_assets'). Missing behavioral details like read-only nature, performance impact, or result format.

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

Conciseness5/5

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

Single sentence, no fluff. Front-loaded with action and resource. Ideal conciseness for a simple tool.

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 no output schema, the description should mention the return format (e.g., array of strings). It is adequate for a straightforward list but incomplete for full 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 coverage is 100% with parameter 'types' already described. The description repeats the same information (CSS, fonts, images) without adding new meaning. Baseline score of 3 is appropriate.

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

Purpose5/5

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

Description clearly states the tool retrieves a URL list of all static resources (CSS, fonts, images). This distinguishes it from sibling tools like 'get_all_stylesheets' or 'get_fonts' which are more specific, making purpose unambiguous.

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

Usage Guidelines3/5

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

No explicit guidance on when to use this tool vs alternatives. The description implies it's for listing all resource types, but does not mention that 'get_all_stylesheets' or 'get_fonts' might be preferable for single-type queries. Lacks exclusion criteria.

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

execute_scriptB

在页面中执行自定义JavaScript代码

ParametersJSON Schema

Name	Required	Description	Default
`script`	Yes	要执行的JavaScript代码

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as side effects, return values, or security implications. For a tool executing arbitrary JavaScript, this is a significant gap.

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

Conciseness4/5

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

The description is a single, clear sentence that directly conveys the tool's purpose. It is concise but could potentially include more key information without becoming verbose.

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

Completeness2/5

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

Given the lack of annotations and output schema, and the powerful nature of executing arbitrary code, the description is incomplete. It does not explain return values, error scenarios, or any restrictions.

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 a parameter description for 'script'. The tool-level description does not add additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

Purpose5/5

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

The description '在页面中执行自定义JavaScript代码' clearly states that the tool executes custom JavaScript code in the page. It uses a specific verb (execute) and resource (custom JavaScript code) and distinguishes itself from sibling tools like analyze_layout or get_page_source.

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 explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. It only describes the action without 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.

extract_css_classesA

提取页面中所有CSS类的定义和使用情况

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, and the description does not disclose behavioral traits such as whether the tool modifies state, requires any permissions, or performance characteristics. It only states the basic function.

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

Conciseness5/5

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

The description is a single sentence with no unnecessary words. It is appropriately concise and front-loaded with the core purpose.

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

Completeness3/5

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

Given the tool has no parameters and no output schema, the description is minimal but does not explain what the output looks like (e.g., return format). It is adequate for a simple tool but could benefit from specifying expected results.

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 zero parameters, so the schema covers 100% of parameters. The description adds meaning by explaining the tool's purpose, which is sufficient. Baseline of 4 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 tool extracts CSS class definitions and usage, using a specific verb 'extract' and resource 'CSS classes'. It distinguishes from sibling tools like get_all_stylesheets or get_element_styles, which focus on different aspects.

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, nor any context about prerequisites or conditions. The description is purely functional without usage recommendations.

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

get_all_stylesheetsB

获取页面所有CSS样式表的内容

ParametersJSON Schema

Name	Required	Description	Default
`includeInline`	No	是否包含内联样式（默认：true）

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided. The description does not disclose behavioral traits such as whether external stylesheets are included, performance implications, or side effects. Minimal transparency.

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

Conciseness4/5

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

Single sentence in Chinese, concise and to the point. No unnecessary words, but could benefit from structuring output details.

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 read tool with one parameter and no output schema, the description is minimally complete. However, it lacks output format description and usage context, which are moderate gaps given the number of sibling tools.

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% for the single parameter (includeInline). The description does not add any meaning beyond the schema's documentation; it only restates the tool's core action.

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: retrieving the content of all CSS stylesheets on the page. It is distinct from sibling tools like get_element_styles (specific element styles) or get_page_source (full HTML).

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives (e.g., extract_css_classes, get_element_styles). No exclusions or context provided.

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

get_element_by_selectorC

通过CSS选择器获取元素的HTML和样式信息

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	CSS选择器
`includeChildren`	No	是否包含子元素（默认：false）

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided; the description does not disclose behavioral traits such as read-only nature, error behavior, or permissions required. It lacks transparency beyond the basic function.

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

Conciseness4/5

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

The description is a single, front-loaded sentence with no unnecessary words. It is concise and directly states the purpose.

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?

Missing output schema; the description does not specify the return format (e.g., structure of HTML and style info) or error handling. For a two-parameter tool with no annotations, more detail would improve completeness.

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% for both parameters (selector, includeChildren). The tool description adds no extra meaning beyond the schema, meeting the baseline expectation.

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

Purpose4/5

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

The description clearly states the verb 'get' and resource 'element' via CSS selector, and specifies that it retrieves both HTML and style info. It distinguishes from siblings like 'get_element_styles' (only styles) and 'get_page_source' (full page).

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 such as 'get_element_styles' or 'get_page_source'. No context on prerequisites 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.

get_element_stylesA

获取指定元素的所有CSS样式（包括计算后的样式）

ParametersJSON Schema

Name	Required	Description	Default
`selector`	Yes	CSS选择器，用于定位元素
`includeComputed`	No	是否包含计算后的样式（默认：true）

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 disclose behavior. It only states the action (get styles) without mentioning read-only nature, potential selector failure, or no side effects.

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

Conciseness5/5

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

Single sentence is concise and directly states the tool's purpose without superfluous 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?

Tool is simple with 2 parameters and no output schema. Description lacks details on return format (e.g., object of style properties). However, it is adequate for basic understanding.

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

Parameters3/5

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

Schema covers both parameters (selector and includeComputed) with descriptions. The tool description adds no additional meaning beyond the schema, so baseline 3 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?

Description clearly states the action ('获取所有CSS样式') and resource ('指定元素'), differentiating from siblings like get_all_stylesheets and extract_css_classes.

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?

Description implies usage for retrieving element styles but does not explicitly state when to use or exclude alternatives like get_all_stylesheets or get_element_by_selector.

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

get_fontsA

获取页面使用的所有字体信息

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 bears full responsibility. It states only that it gets font information, without disclosing behavioral traits such as whether it triggers network requests, modifies the page, or has performance implications. Critical details like side effects or dependency on page rendering are missing.

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 that is efficient and front-loaded. Every word is necessary; there is no wasted space.

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 no parameters and no output schema, the description is minimal. It tells what the tool does but fails to mention the return format or any constraints. For a simple information retrieval tool, this is adequate but not fully complete.

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% (trivially). According to calibration guidelines, the baseline for 0 parameters is 4. The description does not need to add parameter details, and it correctly implies no input 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 it retrieves all font information from the page ('获取页面使用的所有字体信息'). It uses a specific verb ('get') and resource ('fonts'), and it distinguishes itself from sibling tools like 'get_element_styles' or 'analyze_layout', which target different aspects.

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 when font information is needed, but it provides no explicit guidance about when to use this tool compared to alternatives. It lacks when-not-to-use advice or mentions of prerequisites.

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

get_page_sourceA

获取当前页面的完整HTML源码

ParametersJSON Schema

Name	Required	Description	Default
No parameters

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 the full burden. It states the tool retrieves HTML source but does not disclose any behavioral traits such as whether it includes scripts, dynamic content, or if any side effects occur. Minimal information.

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

Conciseness5/5

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

Single sentence, front-loaded with the key action and resource. No unnecessary words. Highly concise.

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

Completeness4/5

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

Given no output schema and zero parameters, the description is fairly complete. It could optionally mention that the return value is a string of HTML, but the purpose is clear. Siblings are diverse, and this tool's function is straightforward.

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, and schema coverage is 100% (void of parameters). The description does not need to add parameter meaning. Baseline score of 4 for zero-parameter tools.

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 '获取' (get) and resource '当前页面的完整HTML源码' (complete HTML source of the current page), distinguishing it from sibling tools like get_element_by_selector or screenshot.

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

Usage Guidelines3/5

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

No explicit guidance on when to use or not use this tool versus alternatives. Usage is implied by the name and description, but no exclusions or context provided.

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

navigateC

访问指定的URL网页

ParametersJSON Schema

Name	Required	Description	Default
`url`	Yes	要访问的网页URL
`waitUntil`	No	等待条件：load, domcontentloaded, networkidle（默认：networkidle）

TDQS

C2.7/5.0

Behavior1/5

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

With no annotations, the description must cover behavioral traits but only states 'visit URL.' It does not disclose whether navigation replaces the current page, requires a browser instance, or affects session state. The waitUntil parameter is not explained.

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 very short (one sentence) and front-loaded. It is concise, but could include additional context without being verbose.

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 the need for behavioral context in a browser automation tool, the description is incomplete. It does not explain return values, side effects, or page load 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?

Schema coverage is 100%, so parameters are documented. However, the description adds no extra meaning beyond the schema. Baseline 3 is appropriate as the schema already covers parameter details.

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 '访问指定的URL网页' clearly indicates the tool navigates to a specified URL. It is a specific verb-resource statement, but lacks differentiation from sibling tools, though siblings like 'screenshot' or 'get_page_source' are distinct enough.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or comparisons to siblings such as 'execute_script' or 'analyze_layout'.

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

screenshotC

对当前页面或指定元素截图

ParametersJSON Schema

Name	Required	Description	Default
`selector`	No	CSS选择器，截取特定元素（可选）
`fullPage`	No	是否截取整个页面（默认：false）

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 but only states the action. It does not disclose return format (e.g., binary, base64), error handling (e.g., invalid selector), or side effects. The behavioral impact of fullPage parameter is implied but not explained.

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

Conciseness4/5

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

The description is a single, brief sentence. It is efficient but omits potentially useful details. It earns a 4 for being concise without being wasteful.

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

Completeness2/5

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

Given the tool has two optional parameters and no output schema, the description fails to explain the expected return value or behavior in edge cases (e.g., no selector, empty page). The agent lacks information to reliably process the result.

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 inline descriptions. The tool description adds no additional meaning beyond the schema, which is adequate. 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 tool captures a screenshot of the current page or a specified element, using a specific verb and resource. It distinguishes from sibling tools by focusing on visual capture rather than analysis or scripting.

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 get_page_source or analyze_layout. No prerequisites or exclusions are mentioned.

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 21, 2026
- First observedanalyze_layout
- First observeddownload_assets
- First observedexecute_script
- First observedextract_css_classes
- First observedget_all_stylesheets
- First observedget_element_by_selector
- First observedget_element_styles
- First observedget_fonts
- First observedget_page_source
- First observednavigate
- First observedscreenshot

Install Server

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

TDQS

A3.5/5.0

Disambiguation4/5

Most tools have distinct purposes, but there is minor overlap between get_element_by_selector and get_element_styles (both return style info) and between download_assets and get_fonts (both list fonts). Overall, the boundaries are clear enough for an agent.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., analyze_layout, download_assets, get_element_styles). Even single-word tools like 'navigate' and 'screenshot' fit the imperative style. No mixing of conventions.

Tool Count5/5

With 11 tools, the server is well-scoped for browser inspection and debugging tasks. Each tool covers a clear aspect (navigation, HTML, CSS, layout, assets, scripts, screenshots) without redundancy or bloat.

Completeness3/5

The tools cover static analysis well but lack interactive capabilities such as clicking, form filling, cookie management, or network request interception. This may leave agents unable to perform dynamic browser automation tasks.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

mcp-webextratorOAuth
io.github.AceDataCloud
MCP server for web extraction and rendering via AceDataCloud WebExtrator
Web Scraping Browser Automation
2
mintqa-mcp
io.github.adamgusky
MCP server for Mint — AI-powered QA that runs your app in a real browser on every PR.
Testing & QA Tools CI/CD & DevOps
2
UI Verify
io.github.igrlk
MCP server for visual regression testing: triage a PR's UI diffs from your coding agent.
9118
ReefAPI A
io.github.reefapi
One MCP server for 180+ live web-data APIs returning clean JSON from sites that block scrapers.
Web Scraping Browser Automation
522

Related MCP Servers

custom-browser-mcp
Browser Automation Web Scraping Design Tools
theriz78
A
license
Not graded
quality
D
maintenance
MCP server that extracts accessibility tree, design tokens, screenshots, Claude DSL, and Figma JSON from any URL using a persistent Chromium browser with zero LLM cost.
Updated 4 months ago (2026-05-18 12:12 UTC)
MIT
mcp-page-capture
Browser Automation Web Scraping
chasesaurabh
A
license
A
quality
D
maintenance
An MCP server that uses headless Chromium (Puppeteer) to capture pixel-perfect screenshots and extract DOM from URLs, with LLM-friendly step-based workflows.
Updated 8 months ago (2025-12-24 04:52 UTC)
2
22
3
MIT
design-md-extractor
Nexuses
-
license
Not graded
quality
Not graded
maintenance
MCP server that captures a website's full design and content, producing a downloadable Next.js clone package with tokens, components, and a rebuild guide.
Updated 2 months ago (2026-07-19 13:00 UTC)
-
design-compare-mcp
codenameakshay
A
license
Not graded
quality
A
maintenance
An MCP server that measures how faithfully one UI reproduces another, returning a score and actionable findings for improvement.
Updated 24 days ago (2026-08-12 18:23 UTC)
1
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/hupeng9995/browser-mcp'

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

🌐 Browser MCP Server

✨ What's New in v2.0

🎯 专为UI设计师打造

🎯 核心特性

📦 安装

1. 安装依赖

2. 安装Chromium浏览器

🚀 使用方法

在Claude Desktop中配置

🛠️ 可用工具

1. navigate

2. get_page_source

3. get_element_styles

4. get_all_stylesheets

5. extract_css_classes

6. get_element_by_selector

7. download_assets

8. analyze_layout

9. get_fonts

10. screenshot

11. execute_script

💡 使用场景示例

场景1: 完整复制一个网站的导航栏

场景2: 分析某个页面的布局系统

场景3: 提取特定组件的完整样式

⚙️ 技术栈

🔒 安全说明

📝 注意事项

🐛 故障排除

无法安装Chromium

Node版本过低

📝 许可证

🤝 贡献

如何贡献

⭐ Star History

🙏 鸣谢

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

1. `navigate`

2. `get_page_source`

3. `get_element_styles`

4. `get_all_stylesheets`

5. `extract_css_classes`

6. `get_element_by_selector`

7. `download_assets`

8. `analyze_layout`

9. `get_fonts`

10. `screenshot`

11. `execute_script`