1. Chrome MCP 是什么把日常浏览器交给 LLM 的浏览器自动化方案Chrome MCP 全称 Chrome MCP Server是一个基于 Chrome 扩展实现的 Model Context Protocol 服务器。它做的事情可以用一句话概括把你正在用的那个 Chrome 浏览器通过 MCP 协议暴露给大模型或聊天客户端让 LLM 能直接读页面、点按钮、填表单、抓网络请求、截图、查历史记录。它不是一个独立的无头浏览器而是挂在你现有浏览器上的一个「遥控接口」。这跟 Playwright 那类浏览器自动化最大的区别在于运行环境。Playwright 通常会启动一个全新的、干净的浏览器实例登录态、Cookie、扩展、书签全都没有你得在脚本里重新走一遍登录流程。Chrome MCP 直接复用你日常那个 Chrome你已经登录的网站、你保存的密码、你装的插件、你打开的标签页它都能看到并用上。对于「让 AI 帮我处理一下当前这个后台页面」这类需求这个差异是决定性的。它适合谁我梳理了三类典型用户。第一类是经常要在网页后台做重复操作的人比如运营要批量改商品信息、测试要反复填表单希望用自然语言驱动 LLM 去点。第二类是做 LLM Agent 方向的开发者需要一个能真实操作浏览器的工具层又不想从零写扩展。第三类是研究 MCP 协议本身的人Chrome MCP 是一个工具数量多、覆盖场景广的现成样本20 多个工具基本把浏览器能力拆得很细。核心特性可以归纳成几条。模型无关任何支持 MCP 的客户端都能接Claude、CherryStudio、Cline、Augment 都行。完全本地MCP 服务跑在本机浏览器数据不出本地。可流式 HTTP默认用 streamableHttp 连接比 stdio 更适合长会话。跨标签页上下文能同时感知多个标签页的内容。内置语义搜索带一个向量库可以对标签页内容做相似度检索。工具覆盖广浏览器管理、截图、网络监控、内容分析、交互、数据管理六大类。理解它的定位之后接下来的安装和配置就顺理成章了装一个 npm 包做桥接加载一个 Chrome 扩展做前端然后在 MCP 客户端里填一段配置。下面按这个顺序走。2. 前置准备Node 环境、mcp-chrome-bridge 安装与 Chrome 扩展加载这一节解决「东西从哪来、装到哪去」的问题。整个链路有两个组件一个是 Chrome 扩展负责真正操作浏览器一个是 mcp-chrome-bridge负责把扩展的能力翻译成 MCP 协议给客户端。两者缺一不可。先看环境要求。Node.js 版本必须大于等于 18.19.0这是硬性门槛低于这个版本 bridge 启动会直接报错。包管理器用 npm 或 pnpm 都行但如果你用 pnpm要注意它 v7 之后默认禁用了 postinstall 脚本这会影响 bridge 的自动注册后面会专门讲。Chrome 或 Chromium 浏览器是必须的版本建议保持较新太老的版本对某些扩展 API 支持不全。第一步下载 Chrome 扩展。扩展不在 Chrome 应用商店里需要从 GitHub Releases 页面手动下载。打开https://github.com/hangwin/mcp-chrome/releases找到最新版本下载扩展压缩包解压到一个你记得住的目录比如~/mcp-chrome-extension。这个目录路径后面加载扩展时要用。第二步全局安装 mcp-chrome-bridge。用 npm 的话直接npm install -g mcp-chrome-bridge用 pnpm 的话因为 postinstall 被禁用需要先打开脚本执行开关再安装# 方法 1全局启用 pre/post 脚本推荐 pnpm config set enable-pre-post-scripts true pnpm install -g mcp-chrome-bridge如果你不想改全局配置或者安装完之后发现自动注册没生效可以手动补一条注册命令# 方法 2手动注册 pnpm install -g mcp-chrome-bridge mcp-chrome-bridge register这里解释一下为什么会有「注册」这一步。mcp-chrome-bridge 安装后需要把自己登记到系统的某个位置让 Chrome 扩展能通过本地端口找到它。postinstall 脚本就是干这个的pnpm 出于安全默认不跑它所以要么打开开关要么手动执行 register。实测下来手动 register 是最稳的做法不依赖包管理器的行为差异。第三步加载 Chrome 扩展。打开 Chrome地址栏输入chrome://extensions/右上角打开「开发者模式」开关。然后点「加载已解压的扩展程序」选中你刚才解压的扩展目录。加载成功后扩展列表里会出现 Chrome MCP Server工具栏上也会有它的图标。第四步连接扩展和 bridge。点击扩展图标打开面板点「连接」按钮。如果 bridge 装好了、注册也成功了这里会显示已连接并给出 MCP 配置信息包括本地端口默认 12306和连接地址。这个地址就是后面要填进 MCP 客户端的 URL。到这一步本地环境就齐了。如果连接按钮点了没反应八成是 bridge 没注册成功回到第二步手动 register 一次然后重启 Chrome 再试。3. 可复制配置streamableHttp 与 STDIO 两种 MCP 接入片段环境装好之后核心动作是把 Chrome MCP 注册到你的 MCP 客户端里。Chrome MCP 支持两种连接方式选哪种取决于你的客户端支持什么。绝大多数现代客户端都支持 streamableHttp优先用它只有少数只认 stdio 的客户端才需要走第二种。3.1 streamableHttp 配置推荐这是官方推荐方式配置最简单只需要一个 URL。以 CherryStudio 为例在它的 MCP 服务器配置里加上{ mcpServers: { chrome-mcp-server: { type: streamableHttp, url: http://127.0.0.1:12306/mcp } } }这段 JSON 的关键字段是type和url。type必须是streamableHttpurl指向本机 12306 端口的/mcp路径。端口号是 bridge 默认监听的如果你改过 bridge 配置这里要同步改。保存后客户端会尝试连接连上就能在工具列表里看到 chrome 开头的那些工具。如果你用的是 Cline 或 Claude Code 这类客户端配置结构类似只是外层字段名可能不同。Cline 的 MCP 配置也是mcpServers对象填法一致。Claude Code 的话可以在项目里用.mcp.json或者通过claude mcp add命令添加本质还是这个 URL。3.2 STDIO 配置替代方案有些客户端只支持 stdio 连接也就是通过启动一个子进程、用标准输入输出通信。这时候需要找到 bridge 安装后的实际路径把它作为 node 脚本启动。先查安装位置# npm 检查方法 npm list -g mcp-chrome-bridge # pnpm 检查方法 pnpm list -g mcp-chrome-bridge假设输出路径是/Users/xxx/Library/pnpm/global/5那么 stdio 入口脚本的完整路径就是/Users/xxx/Library/pnpm/global/5/node_modules/mcp-chrome-bridge/dist/mcp/mcp-server-stdio.js把这个路径填进配置{ mcpServers: { chrome-mcp-stdio: { command: npx, args: [ node, /Users/xxx/Library/pnpm/global/5/node_modules/mcp-chrome-bridge/dist/mcp/mcp-server-stdio.js ] } } }注意args数组里第一个是node第二个是脚本绝对路径。路径一定要用你机器上实际查出来的别照抄示例里的/Users/xxx。Windows 用户路径形如C:\Users\xxx\AppData\Roaming\npm\node_modules\...反斜杠在 JSON 里要转义成\\或者干脆用正斜杠。3.3 三件套对照不管哪种方式接入一个 MCP 服务本质上就是三件套Base URL、Key、Model ID。Chrome MCP 比较特殊它本身不需要 Key纯本地但如果你是通过 TaoToken 这类聚合服务去调用背后的 LLM那 LLM 那一侧需要 Key 和 Model ID。把两层分开看就清楚了层级配置项Chrome MCP 的值LLM 侧的值MCP 连接Base URLhttp://127.0.0.1:12306/mcphttps://taotoken.net/apiMCP 连接Key无需在控制台申请MCP 连接Model ID无需按需选择MCP 客户端负责把「LLM 的决策」翻译成「对 Chrome MCP 的工具调用」所以 LLM 侧的 Base URL 和 Key 要填对Chrome MCP 侧只要 URL 通就行。如果你还没申请 LLM 的 Key可以去https://taotoken.net/api-keys拿一个模型 ID 在文档里能查到。配置保存后重启客户端让它重新加载 MCP 服务器列表。下一节验证是否真的通了。4. 验证请求从启动服务到观察浏览器真实行为配置填完不代表能用得实际跑一遍确认链路通。验证分三层bridge 服务在不在、MCP 客户端认没认到工具、工具调用能不能真的驱动浏览器。4.1 确认 bridge 服务在监听最直接的办法是看端口。bridge 默认监听 12306用 curl 探一下curl -i http://127.0.0.1:12306/mcp如果返回里有 HTTP 响应头哪怕是 4xx说明服务活着只是这个 GET 请求不符合 MCP 的调用规范。如果直接 connection refused那就是 bridge 没起来回去检查安装和 register。4.2 在客户端里看工具列表打开你的 MCP 客户端找到 MCP 服务器状态页。CherryStudio 在设置里能看到每个 server 的连接状态和工具数量。连上的话chrome-mcp-server 应该显示 20 多个工具。如果显示连接失败先看客户端日志里的报错常见的是 URL 写错或端口被占。4.3 跑第一个真实案例让 LLM 总结当前页面这是最能说明问题的一步。在客户端里新建一个对话确保选中了带 Chrome MCP 工具的模型然后输入类似这样的话帮我看看我当前打开的标签页里有什么内容用三句话总结一下。LLM 会先调用get_windows_and_tabs列出所有窗口和标签页拿到当前活动标签的 ID然后调用chrome_get_web_content提取页面文本最后生成总结。你在浏览器里能看到标签页被「读取」的过程某些操作会有视觉反馈对话里能看到工具调用的中间结果。如果这一步成功了说明整条链路是通的LLM 决策 → MCP 协议 → bridge → Chrome 扩展 → 浏览器执行 → 结果回传。4.4 再试一个交互案例自动填表单找一个有输入框的页面比如某个搜索页输入在当前页面的搜索框里输入「MCP 协议」然后点搜索按钮。LLM 会调用chrome_get_interactive_elements找到可交互元素识别出搜索框和按钮然后依次调用chrome_fill_or_select填内容、chrome_click_element点按钮。你能看到浏览器里输入框被自动填上、按钮被点击、页面跳转。这个过程不需要你手动干预。4.5 网络监控验证再验证一个偏开发的场景开始捕获当前页面的网络请求然后刷新页面把捕获到的请求列出来。LLM 会调用chrome_network_capture_start开启捕获你手动刷新页面然后它调用chrome_network_capture_stop停止并返回请求列表。这个能力对调试接口很有用等于让 LLM 帮你做了一次抓包。三个案例跑通基本可以确认 Chrome MCP 在你的环境里工作正常。接下来是排错环节把常见的坑提前说清楚。5. 常见报错排查401、local proxy failed、reading choices 与 OAuth 问题实际用下来报错集中在几个地方。我按出现频率排一下每个都给出现象、原因和修法。5.1 401 Unauthorized现象MCP 客户端连上了但一调用工具就返回 401或者 LLM 侧直接报鉴权失败。原因分两种。如果 401 来自 LLM 服务那是你的 API Key 没填、填错、或者额度用完了。去https://taotoken.net/api-keys检查 Key 状态确认 Base URL 是https://taotoken.net/apiModel ID 拼写正确。如果 401 来自 Chrome MCP 本身那基本不会发生因为它本地不校验鉴权出现这种情况通常是客户端把 LLM 的鉴权头错误地转发到了 MCP 请求上检查客户端的 MCP 配置里有没有多余的 headers 字段。5.2 local proxy failed现象客户端日志里出现local proxy failed或类似的本地代理错误工具调用超时。原因通常是 bridge 没启动或者端口被别的程序占了。先确认 12306 端口有没有被监听# macOS / Linux lsof -i :12306 # Windows netstat -ano | findstr 12306如果没进程说明 bridge 没起来重新执行mcp-chrome-bridge register然后重启 Chrome。如果有别的进程占着改 bridge 的监听端口同时更新客户端配置里的 URL。还有一种情况是 Chrome 扩展没点「连接」扩展面板里显示未连接这时候 bridge 虽然在跑但扩展没挂上去也会报这个错。5.3 reading choices 相关报错现象调用工具后返回里出现reading choices或cannot read property choices of undefined。这是 LLM 响应格式解析失败。choices是 OpenAI 兼容接口返回结构里的字段报这个错说明客户端拿到的响应不是预期的 JSON 结构。常见原因是 Base URL 配错了比如把/api漏了或者多加了/v1导致路径不对。确认你的 LLM Base URL 是https://taotoken.net/api不要自己拼/v1/chat/completions客户端一般会自己补。另一个原因是 Model ID 填了一个不存在的模型服务端返回了错误结构客户端解析时找不到 choices。5.4 OAuth 与登录态问题现象让 LLM 操作某个需要登录的网站结果它看到的是登录页或者操作到一半跳转到登录。Chrome MCP 用的是你当前浏览器的登录态所以正常情况下不需要额外 OAuth。如果你遇到这个问题先确认你操作的那个标签页本身是已登录状态。如果标签页是登录的但 LLM 还是看到登录页可能是它操作的是另一个窗口或标签用get_windows_and_tabs确认一下当前活动标签是哪个。另外某些网站的登录态绑定在特定的 Chrome profile 上如果你开了多个 profile扩展只挂在其中一个上要确保操作的是同一个 profile 的标签页。5.5 工具调用没反应现象LLM 说它调用了工具但浏览器毫无动静。先看扩展面板的连接状态再看 bridge 日志。bridge 启动时如果加了日志参数能看到每次工具调用的入参和结果。多数情况是工具名或参数不对比如chrome_click_element需要一个有效的 CSS 选择器选择器写错了就点不到。让 LLM 先调chrome_get_interactive_elements拿到真实的选择器再点成功率会高很多。5.6 排错速查表报错最可能原因第一步动作401Key 错/额度尽检查 API Key 与 Base URLlocal proxy failedbridge 未启动/端口占用lsof 查 12306reading choicesBase URL 或 Model ID 错核对https://taotoken.net/apiOAuth/登录页标签页未登录/profile 不符确认活动标签登录态工具无反应选择器错/扩展未连接先取 interactive elements排错的核心思路是分层定位先确认 bridge 活着再确认扩展连着再确认客户端认到工具最后才是具体工具的参数问题。一层层往下查比盲目改配置快得多。6. 把 Chrome MCP 接进你的 LLM 工作流从验证到长期使用跑通验证、排完错之后剩下的就是怎么把它用起来。这里给几条实际经验都是踩过坑之后总结的。第一工具调用要「先侦察后行动」。让 LLM 直接点某个元素它经常猜错选择器。更稳的流程是先chrome_get_interactive_elements拿到页面上所有可交互元素的清单LLM 从中挑出目标再执行点击或填写。这个两步走能把成功率从「碰运气」提到「基本可靠」。第二语义搜索适合标签页多的场景。如果你同时开了几十个标签页想找「之前看过的那个讲 MCP 配置的页面」用search_tabs_content做语义检索比翻标签快得多。它内置了向量库对内容做相似度匹配不是简单的关键词匹配。第三网络捕获要记得停。chrome_network_capture_start开了之后如果不 stop会一直累积请求内存和结果都会膨胀。养成「开-操作-停」的习惯。第四长期编码或 Agent 场景考虑用 Coding Plan。Chrome MCP 本身是工具层它背后需要一个稳定的 LLM 来驱动。如果你要长时间跑自动化任务按量计费可能不划算包月方案更合适具体可以在https://taotoken.net/coding-plan看。模型对话类的轻量验证用https://taotoken.net/chat就够。接入文档在https://taotoken.net/doc配置细节以文档为准。第五扩展和 bridge 的版本要匹配。Chrome 扩展和 mcp-chrome-bridge 是配套发布的扩展更新了但 bridge 没更新或者反过来都可能出现工具列表对不上、调用报错的问题。升级时两个一起升。第六注意隐私边界。Chrome MCP 是纯本地的浏览器数据不出本机但它能读到你所有标签页的内容。如果你在浏览器里开着敏感页面LLM 是有能力读到的。用的时候心里有数必要时关掉不相关的标签页。最后说一个实际用法把 Chrome MCP 和你的日常调试流程结合。比如你在调一个前端页面让 LLM 打开页面、捕获控制台输出、抓网络请求、截图然后基于这些信息分析问题。这一套下来等于给 LLM 配了一双能看能点的眼睛和手比单纯贴代码给它分析要直观得多。Chrome MCP 的价值就在这它不替代你的浏览器而是让你的浏览器多了一个能听懂自然语言的驾驶员。