mcp-chrome 调研：把你的日常 Chrome 变成 AI 可控制的浏览器

109次阅读

title: mcp-chrome 调研：把你的日常 Chrome 变成 AI 可控制的浏览器
date: 2026-07-16
tags:
– MCP
– Chrome
– 浏览器自动化
– AI Agent
– 开源工具
– 技术品牌
categories:
– 技术
description: 这不是另一个浏览器，而是一个 Chrome 扩展 + MCP Server，让 Claude / Cursor / OpenClaw 等 AI 直接控制你正在用的日常 Chrome，复用现有登录态、书签、历史、标签页。
lang: zh-CN
cover: yj-blog-cover-mcp-chrome.png

mcp-chrome 调研：把你的日常 Chrome 变成 AI 可控制的浏览器

Chrome MCP Server 不是一个“新浏览器”，而是一个 Chrome 扩展 + MCP Server，让 Claude / Cursor / OpenClaw 等 AI 直接控制你正在用的 Chrome，复用现有登录态、书签、历史、标签页。

写在前面

2025 年下半年到 2026 年，MCP 协议把 AI 和浏览器之间的接口标准化了。但大多数方案 still 停留在“造一个干净浏览器替用户跑流程”的层面：Playwright 开独立进程、每次重新登录、环境是假的、只能访问有限 API。

mcp-chrome 选了一条完全不同的路：不造新浏览器，直接把你的日常 Chrome 变成 AI 可控制的外设。这个思路听起来简单，却恰好戳中了隐私、登录态、真实环境这三个核心痛点。

一、它解决什么问题

传统浏览器自动化的本质矛盾是：自动化越强，环境越假。Playwright / Puppeteer 能跑流程，但拿不到真实用户的 Cookie、插件配置、双因素认证会话，也观察不到真实环境下的页面行为。

mcp-chrome 的答案很直接：用 Chrome 扩展 + 全局桥接服务，把 Chrome 原生能力暴露给 MCP Client。

字段 内容
仓库 hangwin/mcp-chrome
主语言 TypeScript
协议 MIT
当前版本 v1.0.0（2026-05-21）
社区数据 11.9k Stars / 1.1k Forks / 7 Open Issues
维护者 hangwin / hangerye（PR 占 92%）
状态 早期阶段，README 明确写 “still in its early stages”
文档 英文 README + 中文 README + Architecture / Tools / Troubleshooting

消歧：GitHub 上不存在同名主流竞品；唯一容易混淆的是 Google 官方的 Chrome DevTools MCP（2025-09），但 DevTools MCP 偏调试 / 性能审计，mcp-chrome 偏日常浏览自动化 + 内容分析 + 语义搜索。

二、架构：两步把 Chrome 变成 MCP Server

┌─────────────────────────────────────────┐
│  你的 Chrome 浏览器（日常使用的那个）│
│  ┌───────────────────────────────────┐  │
│  │  Chrome Extension（mcp-chrome）│  │
│  │  - 内容脚本注入 / 消息桥接          │  │
│  └──────────────┬────────────────────┘  │
└─────────────────┼──────────────────────┘
                  │ Native Messaging / WebSocket
┌─────────────────▼──────────────────────┐
│  mcp-chrome-bridge（全局 Node.js 包）│
│  - 注册为系统 MCP Server               │
│  - 提供 stdio / streamable HTTP 双入口  │
└─────────────────────────────────────────┘
         ↓                    ↓
   Claude / Cursor      OpenClaw / 其他 MCP Client

两种连接方式：

  1. Streamable HTTP（推荐）：http://127.0.0.1:12306/mcp，适合支持 HTTP 的 MCP Client
  2. stdio：直接调用 mcp-server-stdio.js，适合传统 stdio MCP Client

安装只需两步：

npm install -g mcp-chrome-bridge

然后 Chrome 加载 GitHub Releases 的 zip 扩展，点击 connect。

三、20+ 工具全景

根据官方 docs/TOOLS.md，工具分为六大类：

3.1 浏览器管理（6 个）

列出窗口标签、导航、切换标签、关闭标签 / 窗口、前进后退、注入内容脚本并下发命令。

3.2 截图与视觉（1 个）

元素级截图 / 全页截图 / 自定义尺寸，支持 targeting 特定 DOM 节点。

3.3 网络监控（4 个）

webRequest API 抓包开始 / 停止；Debugger API 抓响应体开始 / 停止；发送自定义 HTTP 请求。这三对工具覆盖了从“看请求列表”到“拿响应 body”的完整抓包链。

3.4 内容分析（4 个）

search_tabs_content 是亮点：内置向量数据库，跨标签页做语义搜索，不只是关键词匹配。其余三个是提取网页文本 /HTML、找出可交互元素、抓取控制台输出。

3.5 交互（3 个）

CSS 选择器点击、填表 / 下拉选择、模拟键盘输入和快捷键。

3.6 数据管理（5 个）

按时间范围搜索历史、书签搜索 / 新增 / 删除。

四、差异化竞争力

4.1 vs Playwright-based MCP Server

维度 Playwright MCP mcp-chrome
资源占用 需额外浏览器进程 + 二进制 复用已有 Chrome
登录态 每次重新登录 自动保留
环境真实度 干净环境 完整用户环境
API 范围 Playwright API Chrome 原生 API
启动速度 需启动浏览器 只需激活扩展
响应速度 50–200ms IPC 更快

4.2 vs Google Chrome DevTools MCP

  • DevTools MCP：偏调试 / 性能 / 审计，适合开发者排查页面问题
  • mcp-chrome：偏 自动化操作 + 内容理解 + 语义搜索，适合让 AI 帮你“用浏览器”

4.3 vs Browserbase / MultiOn / Stagehand

云端浏览器方案需要把数据传到第三方服务器；mcp-chrome 纯本地，所有数据留在你机器上。

4.4 独特卖点：SIMD-Accelerated 语义搜索

内置向量数据库，用 WebAssembly SIMD 做向量运算，官方声称比普通实现快 4–8 倍。这个能力让 AI 可以跨标签页做语义检索，而不只是关键词匹配。

五、典型使用场景

场景 工具组合 示例
网页摘要 + 画图 screenshot + content extraction + Excalidraw 总结当前页内容，然后画一张理解图
页面样式修改 inject script + CSS 操作 帮我去掉当前页的广告
API 研究 network capture + content extraction 研究小红书的搜索 API 响应结构
历史分析 chrome_history + 数据分析 分析过去一个月的浏览习惯
翻译摘要 get_web_content + 翻译 翻译并总结当前网页
批量截图 screenshot 循环 截图指定网站的图标
书签整理 bookmark_search + bookmark_add 把当前页归类到合适的书签文件夹
标签管理 get_windows_and_tabs + close_tabs 关闭所有 shadcn 相关页面

这些场景来自官方示例视频和社区用法，覆盖了从“个人助理”到“开发辅助”的跨度。

六、实战：3 步跑通基础流程

前提：Node.js >= 20，Chrome/Chromium，npm 或 pnpm。

第一步：安装桥接服务

npm install -g mcp-chrome-bridge
# pnpm 用户需要先执行：# pnpm config set enable-pre-post-scripts true

第二步：加载 Chrome 扩展

1. 打开
chrome://extensions/

2. 开启“开发者模式”
3. 点击“加载已解压的扩展程序”，选择从 GitHub Releases 下载的 zip 解压目录（或直接拖 zip，视 Chrome 版本而定）
4. 点击扩展图标 → connect

第三步：配置 MCP Client

以 Streamable HTTP 为例：

{
  "mcpServers": {
    "chrome-mcp-server": {
      "type": "streamableHttp",
      "url": "http://127.0.0.1:12306/mcp"
    }
  }
}

如果你用的 Client 只支持 stdio，需要把 mcp-server-stdio.js 的绝对路径填进 command + args。

七、风险与局限

7.1 项目早期风险

  • README 明确写 “still in its early stages”，API 可能 breaking change
  • v1.0.0 刚发布（2026-05-21），生产锁定前建议小范围试用
  • 单作者主导，92% 是 PR，需关注长期维护性

7.2 浏览器限制

  • 仅支持 Chrome / Chromium，Firefox 在 roadmap 但未实现
  • 需要开启 Chrome 开发者模式加载扩展
  • 部分 Chrome 原生 API 有权限限制

7.3 安全风险

  • 未配置 SECURITY.md，无官方安全响应流程
  • 扩展需要较高权限（消息桥接、内容脚本、网络请求）
  • 扩展加载需手动操作，不适合大规模自动化部署

7.4 环境依赖

  • Node.js >= 20
  • pnpm/npm 全局安装 mcp-chrome-bridge
  • 需要手动加载 unpacked 扩展
  • 不同 OS 的 stdio 路径不同，需要手动配置

7.5 竞品压力

  • Google 官方 Chrome DevTools MCP 有官方背书
  • Browserbase 等云端方案生态更成熟
  • Playwright 本身也在改进 MCP 支持

八、总结

mcp-chrome 最值得装的三个理由：

  1. 真环境：复用日常 Chrome 的登录态、插件、书签、历史，不用在自动化里反复登录
  2. 纯本地：数据不流出你的机器，隐私敏感场景友好
  3. 工具全：20+ 工具覆盖导航、截图、抓包、语义搜索、表单交互，日常自动化基本够用

它不适合谁：需要 Firefox/Safari 支持的用户、需要稳定生产 API 的企业团队、对浏览器权限有严格合规要求的场景。

建议先试一周：装扩展、跑通 HTTP 连接、让 AI 帮你总结几个标签页内容，感受一下“用 AI 操作真实浏览器”和“用 Playwright 跑假浏览器”的差异。

参考链接

  • GitHub: https://github.com/hangwin/mcp-chrome
  • 英文 README: https://github.com/hangwin/mcp-chrome/blob/master/README.md
  • 中文 README: https://github.com/hangwin/mcp-chrome/blob/master/README_zh.md
  • Architecture: https://github.com/hangwin/mcp-chrome/blob/master/docs/ARCHITECTURE.md
  • Tools API: https://github.com/hangwin/mcp-chrome/blob/master/docs/TOOLS.md
  • Releases: https://github.com/hangwin/mcp-chrome/releases
正文完
发表至： 技术
2026-07-16
 

近期文章

近期评论