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 "Install 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'streaming support' and implies navigation and capture actions, but doesn't describe what happens during execution (e.g., browser launch, page load behavior, error handling, or output format). For a tool with 5 parameters and no annotations, this leaves significant gaps in understanding its behavior.
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 front-loads the core purpose. It avoids redundancy and wastes no words, making it highly concise and well-structured for quick understanding.
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 annotations, no output schema), the description is incomplete. It lacks details on behavioral traits, output format, error conditions, and differentiation from the sibling tool. Without annotations or output schema, the description should provide more context to compensate, but it doesn't.
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 5 parameters. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain parameter interactions or provide examples). Baseline 3 is appropriate when the schema handles parameter documentation effectively.
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's purpose: 'Navigate to a URL and capture console output from the browser with streaming support.' It specifies the verb ('navigate' and 'capture'), resource ('console output'), and key feature ('streaming support'). However, it doesn't explicitly differentiate from its sibling tool 'browser-server-console', which prevents a score of 5.
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 provides no guidance on when to use this tool versus alternatives. It doesn't mention the sibling tool 'browser-server-console' or any other context for selection. Usage is implied by the purpose but lacks explicit when/when-not instructions or prerequisites.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions spawning a server and capturing console output, but lacks details on permissions, error handling, resource cleanup, or what happens after timeout. For a tool with server spawning and browser interaction, this is a significant gap in transparency.
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 front-loads the core functionality without unnecessary words. Every element ('spawn', 'Express static server', 'directory', 'capture console output') earns its place in conveying the tool's purpose.
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 (spawning servers, browser automation, 7 parameters) and lack of annotations or output schema, the description is insufficient. It doesn't explain return values, error conditions, or behavioral nuances, leaving critical gaps for an agent to use the tool effectively.
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 7 parameters. The description adds no parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 where the schema does the heavy lifting.
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's purpose with specific verbs ('spawn', 'capture') and resources ('Express static server', 'console output from served content'). It distinguishes from the sibling 'browser-console' by specifying server spawning functionality, though the distinction could be more explicit about what 'browser-console' does differently.
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 provides no guidance on when to use this tool versus alternatives like 'browser-console'. It mentions the tool's function but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pansin/browserMCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
