Converts web page content into structured Markdown format for improved readability and organization of extracted web information.
Powers browser automation capabilities including page navigation, content extraction, element interaction, and screenshot capture through Puppeteer's headless browser technology.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Browser MCP Server go to github.com and get the latest trending repositories"
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.
一个基于Model Context Protocol (MCP)的浏览器自动化服务器，使用Puppeteer提供强大的网页浏览、内容提取和交互功能。
页面导航：导航到URL、刷新、前进/后退
内容提取：获取页面源代码、元数据、截图和文本
格式化内容：将网页内容转换为结构化的Markdown格式
元素交互：点击、输入、选择和等待元素
测试工具：检查元素存在、验证内容、执行脚本
搜索功能：通过百度搜索获取最新文章和信息
安全保障：沙箱浏览器执行与域名限制
配置灵活：支持自定义配置管理
Related MCP server: Steel Puppeteer
# 克隆仓库
git clone https://github.com/yourusername/browser-mcp-server.git
cd browser-mcp-server
# 安装依赖
npm install
# 构建项目
npm run build# 启动开发模式
npm run dev# 运行测试
npm test
# 运行特定测试
npx tsx src/tests/simple-test.ts
npx tsx src/tests/search-test.ts
npx tsx src/tests/visit-website-test.ts
npx tsx src/tests/formatted-content-test.ts服务器使用配置文件管理浏览器设置、安全选项和默认行为。查看src/config/default.ts了解默认配置。
Browser MCP Server设计为与Kiro IDE一起使用。将其添加到您的MCP配置中：
{
"mcpServers": {
"browser": {
"command": "node",
"args": ["path/to/browser-mcp-server/dist/index.js"]
}
}
}详细使用说明请参考用户指南。
browser-mcp-server/
├── src/
│ ├── config/ # 配置文件
│ ├── errors/ # 错误处理类
│ ├── interfaces/ # 接口定义
│ ├── managers/ # 管理器实现
│ ├── tools/ # 工具实现
│ ├── types/ # 类型定义
│ ├── utils/ # 工具函数
│ ├── tests/ # 测试文件
│ └── index.ts # 入口文件
├── dist/ # 编译后的文件
├── package.json # 项目配置
└── README.md # 项目说明本项目采用 Apache License 2.0 许可证。
Copyright 2025 Browser MCP Server Contributors
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.Navigate to a URL and capture console output from the browser with streaming support
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL to navigate to | |
| timeout | No | Timeout in milliseconds (default: 30000) | |
| waitFor | No | CSS selector or text to wait for before capturing console (optional) | |
| commands | No | Browser commands to execute (e.g., "click .button wait 2s") (optional) | |
| stream | No | Whether to stream console output in real-time (default: true) |
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 only mentions 'streaming support', which is a useful detail, but it omits any side effects (e.g., opening a browser, executing scripts, potential resource usage), prerequisites, or what happens to the browser session. It also does not describe the return format or how streaming terminates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core action and a key feature. It contains no filler or redundant information, making it appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations), the description is too minimal. It does not explain the waitFor or commands parameters, which represent significant behaviors, nor does it clarify what the captured console output looks like. The schema covers parameters but the description fails to provide a complete mental model of the tool's capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (url, stream, timeout, waitFor, commands) have descriptive schema definitions. The tool description adds nothing beyond the schema—'streaming support' repeats the stream parameter's purpose. Therefore, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool navigates to a URL and captures console output from the browser, with streaming support. This specific verb+resource combination ('navigate' + 'capture console output') and the qualifier 'from the browser' distinguishes it from the sibling tool 'browser-server-console', which likely targets a server-side console.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for capturing browser console output after navigation, but it does not explicitly state when to use this tool versus alternatives, mention exclusions, or provide use-case context (e.g., debugging front-end errors). The presence of a sibling tool suggests a potential distinction but it is not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Spawn an Express static server for a directory and capture console output from the served content
| Name | Required | Description | Default |
|---|---|---|---|
| directory | Yes | The directory to serve statically | |
| port | No | Preferred port to run the server on (will find next available if busy, default: 3000) | |
| path | No | Path to navigate to after starting server (default: "/") | / |
| timeout | No | Timeout in milliseconds (default: 30000) | |
| waitFor | No | CSS selector or text to wait for before capturing console (optional) | |
| commands | No | Browser commands to execute (e.g., "click .button wait 2s") (optional) | |
| stream | No | Whether to stream console output in real-time (default: true) |
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 disclosing behavioral traits. It states what the tool does (spawns a server, captures console) but does not disclose side effects such as server lifecycle/cleanup, blocking behavior, rate limits, or what happens to existing servers. This is a significant gap for a tool that starts a server.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the core purpose and actions. It contains no fluff or redundant phrasing, and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given seven parameters and the absence of annotations and an output schema, the description is relatively minimal. It does not explain what the tool returns, how console output is delivered, or whether the server is automatically stopped. The parameter schema covers the 'how' but the overall usage context remains incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all seven parameters including defaults and semantics. The description adds no 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Spawn') and resource ('Express static server') and clearly states the second function ('capture console output'). This distinguishes it from the sibling tool 'browser-console', which likely focuses only on console capture without serving a directory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus the sibling tool 'browser-console'. It implies usage for serving static content and capturing console output, but there are no exclusions or alternative recommendations, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
browser-consolebrowser-server-consoleScored across 2 tools
The two tools have overlapping purposes—both capture console output from a browser—but their descriptions clarify distinct contexts: one navigates to a URL, while the other serves local content. Some ambiguity remains as both involve browser console operations, but the descriptions help differentiate them.
Both tool names follow a consistent 'browser-[context]-console' pattern, using hyphens to separate words. This predictable naming scheme makes it easy to understand their roles and relationship within the server.
With only two tools, the server feels under-scoped for a 'Browser MCP Server' that implies broader browser automation capabilities. A typical browser server might include tools for navigation, DOM interaction, or screenshots, making this set appear incomplete.
Inferred domain is browser automation, but the toolset is severely incomplete. It lacks basic operations like page navigation, element interaction, or screenshot capture, focusing narrowly on console output. This will likely cause agent failures for common browser tasks.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Provides cloud browser automation capabilities using Stagehand and Browserbase, enabling LLMs to i…
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
