Chrome MCP

Chrome MCP 向 Model Context Protocol 客户端暴露真实的 Chrome 标签页，而无需将浏览器会话复制到另一个引擎中。Chrome 扩展通过 chrome.debugger 控制用户现有配置文件中的标签页，同时一个持久的本地守护进程协调一个或多个 Chrome 配置文件与 MCP 进程。

架构

MCP client ──stdio── MCP bridge ──authenticated HTTP── persistent daemon
                                                        │
                                                        ├── WebSocket ── Chrome extension/profile A ── tabs
                                                        └── WebSocket ── Chrome extension/profile B ── tabs

• 标签页就是浏览器会话。关闭会话即关闭其 Chrome 标签页。

• 每个扩展安装代表一个 Chrome 配置文件/实例。

• 守护进程为每个已连接实例分配全局数字 session_id 值。

• 守护进程独立于 MCP 客户端的重启而持续存在，并且没有托盘图标。

• 操作通过 chrome.debugger 使用 Chrome DevTools Protocol，因此被评估的 JavaScript 不会被页面 CSP 阻止。

• 由于无需会话迁移，认证状态、Cookie、IndexedDB、service worker、证书、扩展和浏览器指纹都保留在原始 Chrome 配置文件中。

Related MCP server: monkeysee

安装

需要 Chrome 116 或更高版本。

bun install

在每个应可用的 Chrome 配置文件中加载扩展：

1. 打开 chrome://extensions。

2. 启用开发者模式。

3. 选择加载已解压的扩展程序。

4. 选择此仓库的 extension 目录。

5. 打开扩展弹出窗口，为实例指定一个易识别的名称，并在适当时选择设为默认。

Chrome 必须能够访问 ws://127.0.0.1:55333。守护进程只接受来自 chrome-extension:// 来源的扩展 WebSocket，并且仅绑定到 localhost。

MCP 客户端配置

{
  "mcpServers": {
    "chrome": {
      "command": "bunx",
      "args": ["-y", "@cypherpotato/chrome-mcp", "--mcp"]
    }
  }
}

对于在 bun link 之后的本地检出，请将 MCP 配置直接指向链接后的可执行文件，而不是使用 bunx：

{
  "command": "C:\\Users\\<user>\\.bun\\bin\\chrome-mcp-electron",
  "args": ["--mcp"]
}

CLI

chrome-mcp-electron --mcp
chrome-mcp-electron --daemon
chrome-mcp-electron --status
chrome-mcp-electron --stop-daemon
chrome-mcp-electron --help

--mcp 会在必要时在后台启动守护进程，然后通过 stdio 提供 MCP 服务。关闭 MCP 进程不会停止守护进程，也不会断开 Chrome 扩展的连接。

工具

公共工具名称和输入模式与 Browser MCP 一致：

• browser_toggle_session

• browser_import_session

• browser_run_actions

• browser_get_context

browser_toggle_session({ "action": "start" }) 会在默认 Chrome 实例中打开一个标签页。当连接了多个实例时，请在扩展弹出窗口中选择默认实例。扩展报告的现有标签页也会获得 session_id 值，并且可以直接控制。

browser_get_context 列出所有已连接实例及其标签页。URL 返回时不带查询字符串。

多个 Chrome 实例与配置文件

在每个配置文件中分别安装已解压的扩展。每次安装都会创建一个存储在该配置文件中的稳定随机实例 ID，并自动重新连接到守护进程。实例名称不必唯一，但建议使用不同的名称。

在扩展或 service worker 重启后，守护进程会协调标签页。只要所属扩展已连接且标签页仍然存在，会话就保持可寻址状态。

能力

browser_run_actions 支持与 Browser MCP 相同的浏览器辅助功能：

• 快照与 JavaScript 评估；

• 点击、右键单击、悬停、拖拽、滚动和键入；

• 导航；

• 截图；

• 控制台与网络日志；

• Chrome 仍保留时的网络请求详情与响应体；

• 响应式视口模拟与配色方案模拟；

• JavaScript alert、confirm 和 prompt 处理。

限制

• Chrome 每个标签页只允许一个调试器连接。在控制该标签页之前，请先关闭 DevTools。打开 DevTools 可能会分离扩展。

• Chrome 内部页面、扩展页面、Chrome Web Store 以及其他受限方案无法被控制或作为智能体会话暴露。

• 扩展必须安装在每个配置文件中；一个配置文件无法检查另一个配置文件的标签页。

• 当标签页处于连接状态时，调试器权限会显示一条 Chrome 警告。

• 响应体可能会从 Chrome 的网络缓冲区中过期失效。

• 原生触摸输入和浏览器内部的下载 CDP API 不会通过 chrome.debugger 暴露。

开发

bun run check
bun run test

测试套件使用模拟扩展 WebSocket 客户端，在不打开 Chrome 的情况下验证持久守护进程生命周期、认证、标签页/会话协调、多实例、默认实例选择、操作路由和重连行为。

内部协议记录在 docs/protocol.md 中。