install、list、reload、trigger、uninstall，以及 service-worker 日志）。Extension.js 的 MCP 服务器（@extension.dev/mcp）覆盖同样的扩展能力，但具备构建感知，并支持跨浏览器。
它们是互补关系，而不是竞争关系。两个一起运行：让 chrome-devtools-mcp 驱动 Chrome 本身，让 Extension.js 接管一切与你项目相关的事——构建、热重载、生成的 manifest、storage、跨上下文的日志，以及在 Firefox、Edge 和 Safari 上的同一套工作流。
何时该用哪一个
一个有用的经验法则：如果任务涉及到你的项目（源码、构建、manifest、重载），就用 Extension.js；如果任务面向浏览器本身（页面、网络、性能），就用 chrome-devtools-mcp。
同时安装两个服务器
Extension.js 的工具都加了extension_* 命名空间前缀，因此永远不会与 chrome-devtools-mcp 的工具冲突。熟悉其中一个的 agent 可以无缝迁移到另一个。
chrome-devtools-mcp 的扩展工具（
--categoryExtensions）目前要求使用 pipe
连接。在 Chrome 149 之前，通过 WebSocket 端点（browserUrl / wsEndpoint）
附加到一个已经在运行的浏览器，对 extension 类别是不支持的。Extension.js
连接的是它为你的开发会话启动的那个浏览器，因此它的扩展工具今天就能用。能力对照表
chrome-devtools-mcp 每一个扩展相关动作在 Extension.js 中都有对应物，再加上围绕它构建的整套构建平台。action / command 触发器的工作原理——以及它们唯一的注意点
chrome-devtools-mcp 是通过点击真实的工具栏按钮来触发 action 的，这需要一个可见的窗口与真实的用户手势。Extension.js 走的是另一条路：它在构建阶段就捕获扩展的chrome.action.onClicked（以及 chrome.commands.onCommand）监听器，并在你需要时重放它们。这让触发变得可脚本化且可重现——这正是 agent 化测试的天然模式——而且因为它只触及 addListener，它在 Chromium 和 Firefox 上都能工作（在两者上都已验证）。一份 background.service_worker 源码也能在 Firefox 上工作——由于 Firefox 不运行 service-worker background，Extension.js 会把它翻译为 Firefox 构建目标里的 background.scripts 事件页面。
需要真实手势点击？请用 chrome-devtools-mcp
两者是互补的，而不是竞争关系：extension_open（surface: "action"）——日常路径。重放处理器，跨浏览器、无头、无手势（不授予activeTab）。处理绝大多数处理器测试场景。- chrome-devtools-mcp 的
trigger_extension_action——通过 Puppeteer（在受支持的 pipe 传输上）发起一次真实的 action 调用，因此activeTab会像真实用户点击那样被授予。仅限 Chromium。只有当你的处理器确实依赖手势时才需要它。
设计上即安全
重放包装只注入到你的开发构建里——agent 桥仅依赖一个只在extension dev / preview 期间存在的控制端口，生产构建中不会添加任何内容。addListener 包装会透明地委托给原始实现，因此无论是否启用桥，你的扩展行为都完全一致。
下一步
- 把文档也接入你的助手：通过 MCP 与 llms.txt 提供 AI 访问。
- 把检查接入流水线：CI 模板。
- 让同一个扩展运行在所有地方：跨浏览器兼容性。