BrowserTools MCP 是一个面向 AI 编码助手的 MCP 服务器,配合 Chrome 扩展,把开发者当前正在使用的真实浏览器会话中的控制台输出、网络请求、截图和 Lighthouse 审计结果,转发给 Cursor、Claude Code、Windsurf、Cline、Zed 等兼容 MCP 的客户端。与启动全新自动化浏览器的方案不同,它附着在已登录的页面上,不必重建登录状态。2.0 版本把原先的三个进程合并为一个,取消了未鉴权的本地服务,凭据在离开浏览器前会被清理,并附带测试。多个打开 DevTools 的标签页分别记录遥测,读取工具支持分页和关键词过滤以控制上下文体积,完整日志、HAR 与审计报告以 MCP 资源形式按需拉取。
npx -y @agentdeskai/browser-tools-mcp@latestGive your AI coding agent eyes on the browser. BrowserTools MCP streams console output, network activity, screenshots and Lighthouse audits from your real Chrome session — the one already logged into your app — to any MCP-compatible client: Cursor, Claude Code, Windsurf, Cline, Zed, Gemini CLI, and others.
Version 2.0 is a rewrite. One process instead of three, no unauthenticated local server, credentials scrubbed before they leave the browser, and a real test suite. If you are coming from 1.x, read MIGRATION.md — and upgrade, because 1.2.x has a critical vulnerability. See SECURITY.md.
Tools like Chrome DevTools MCP and Playwright MCP drive a fresh, automated browser. That is the right choice for writing tests. It is the wrong choice for debugging the app you are actually looking at, because since Chrome 136 the browser refuses remote debugging on your default profile — the one holding your logins. So you end up recreating your auth state in a throwaway profile before you can debug anything.
BrowserTools attaches to the session you are already in, through a DevTools extension. You stay logged in, on the page you were already on, and your agent reads what you see. It also reports Lighthouse-grade performance, accessibility and SEO data, which the automation-first servers do not.
Two pieces: an MCP server (one command) and a Chrome extension.
{
"mcpServers": {
"browser-tools": {
"command": "npx",
"args": ["-y", "@agentdeskai/browser-tools-mcp@latest"]
}
}
}
On Windows, if your client cannot find npx, use "command": "cmd" with
"args": ["/c", "npx", "-y", "@agentdeskai/browser-tools-mcp@latest"].
Requires Node 22.19 or newer. Check with node --version; if you use nvm or
asdf, make sure your editor inherits the same version.
chrome://extensions and turn on Developer mode.chrome-extension directory.That is the whole setup. There is no second server to start — the MCP server runs the connector itself.
Open Chrome DevTools (F12) on the page you want to inspect. Capture begins as soon as DevTools is open; the BrowserTools panel is only for settings and status. Then ask your agent something like "check the console for errors" or "run an accessibility audit on this page".
Not working? Run npx @agentdeskai/browser-tools-mcp --doctor, which reports
exactly which piece is missing.
To watch capture happen live — useful when checking a fresh install — start the
connector with --verbose:
npx @agentdeskai/browser-tools-server --verbose
· console error tab 42 Uncaught TypeError: total is not a function
· network 500 POST tab 42 https://myapp.local/api/pay (1310ms)
Without it the connector only reports connect and disconnect, so a working setup and a silent one look the same.
| Tool | What it does |
|---|---|
getConsoleLogs | Console output, filterable by keyword with paging |
getConsoleErrors | Error-level output and uncaught exceptions |
getNetworkLogs | XHR/fetch requests with status, timing and bodies |
getNetworkErrors | Only failed and 4xx/5xx requests |
getSelectedElement | The element selected in the Elements panel |
getPageInfo | Which page the browser is currently on |
getConnectionStatus | Whether the extension is connected, and capture counts |
listBrowserTabs | Every tab with DevTools open, and the id to address it by |
takeScreenshot | Screenshot returned as an image, plus its file path |
refreshBrowser | Reloads the inspected tab |
getBrowserStorage | localStorage, sessionStorage and cookies (values gated) |
wipeLogs | Clears captured telemetry before a clean reproduction |
runAccessibilityAudit | Lighthouse accessibility audit |
runPerformanceAudit | Lighthouse performance audit with Core Web Vitals |
runSEOAudit | Lighthouse SEO audit |
runBestPracticesAudit | Lighthouse best-practices audit |
Three prompts ship alongside them — debuggerMode, auditMode and
nextjsSeoAudit — giving your agent a systematic workflow instead of a wall of
static text in every tool listing.
All tools declare MCP output schemas, so clients receive structured data rather than prose they have to parse, and read-only tools are annotated as such so clients can auto-approve them safely.
Every tab with DevTools open is tracked separately. Telemetry is attributed to the tab that produced it, and retention is per tab, so a chatty page cannot push out the history of the one you care about.
Tools act on the current tab — the one you most recently opened DevTools on.
A tab whose connection drops and comes back does not steal that position, which
is what used to make screenshots capture the wrong page. Every result reports
the tabId and url it came from, plus otherTabs, so a wrong-tab answer is
visible rather than silent. To target a specific tab, call listBrowserTabs and
pass its tabId to any tool; pass allTabs: true to read across every tab.
Whole-history payloads are exposed as MCP resources rather than inlined, and
tools link to them with resource_link so your agent fetches them only when it
decides to:
| Resource | What it is |
|---|---|
browser-tools://console/{tabId|all} | Every console entry, with no per-call budget |
browser-tools://network/{tabId|all} | Every captured request, including bodies |
browser-tools://har/{tabId|all} | The same traffic as a HAR 1.2 file |
browser-tools://screenshot/{name} | A screenshot you captured earlier |
browser-tools://audit/{reportId} | The unabridged Lighthouse result behind a summary |
Log tools attach a link when a read had to be cut short; network reads always
offer the HAR; screenshots always link to the stored image, which is the only
way to see one too large to inline. The last 20 full Lighthouse reports are kept
under audits/ in the screenshot directory.
Log payloads are the usual cause of a blown context window. Every read tool
takes limit and offset, and the log tools take keyword filters:
getConsoleErrors({ keywords: ["hydration"], limit: 20 })
getNetworkLogs({ urlKeywords: ["/api/"], bodyKeywords: ["quota"], limit: 10 })
Results are returned newest-first and always report total alongside
returned, so an agent knows when it is only seeing part of the picture.
This tool captures whatever your browser sees, so it treats that data carefully:
127.0.0.1 and refuses non-loopback
addresses. In 1.x it bound 0.0.0.0, reachable by anyone on your network.Authorization, Cookie and
similar headers, plus JWTs, cloud keys and vendor tokens found anywhere in
captured strings, become [REDACTED].--audit-allow-origin), and every request the audit browser makes —
redirects and subresources included — is checked again as it happens. A
local page may load only the local origins that are open in a tab or
allowlisted, so if your app calls an API on another local port, open that
too or allowlist it. Audits connect directly, not through a system proxy.
Behind a fake-IP proxy (Clash, sing-box, Surge), which hides where names
really go, audits are refused unless you pass
--audit-allow-private-network; see SECURITY.md.Report vulnerabilities per SECURITY.md.
Flags, or the matching BROWSER_TOOLS_* environment variables:
| Flag | Purpose |
|---|---|
--port | Connector port (default 3025) |
--screenshot-dir | Where screenshots are written |
--only | Expose only these tools |
--exclude | Hide these tools |
--doctor | Check the setup and exit |
--verbose | Print each captured entry as it arrives |
--host | Loopback address to bind (default 127.0.0.1) |
--connect | Attach to a connector already running elsewhere |
--token | Auth token to use with --connect |
--no-redact | Disable credential scrubbing (not recommended) |
--audit-allow-origin | Loopback/private origins audits may target or load without an open tab |
--audit-allow-private-network | Let audits reach any loopback/private address except the audit's own ports (not recommended); also needed behind a fake-IP proxy |
To share one browser session between several MCP clients, start the connector
once with npx @agentdeskai/browser-tools-server and every client will attach to
it automatically.
screenshotMaxBytes, 3 MB by default).
A capture that would exceed it is re-encoded as JPEG and, if still too large,
downscaled. A viewport capture of dense content on a high-DPI display can
otherwise run past 13 MB, which is more than a model's context can take and
past the read buffer newer MCP stdio transports enforce. If an image still
cannot fit, it is written to disk and the tool returns the path instead of
inlining it.browser/chrome shim, browser_specific_settings, and a capture mode that
does not need chrome.debugger — but it has never been loaded in Firefox, and
nothing in the test suite covers it. Screenshots in particular go through the
DevTools protocol and will not work there. Treat Firefox as unsupported until
someone has actually run it; a report either way is welcome.--doctor reports which one will be used. Set CHROME_PATH to override.
Arc is supported on a best-effort basis and has not been verified headless.npm install
npm run build
npm test # unit + integration, no browser required
npm run test:e2e # real Chromium with the extension loaded
npm test runs in seconds. The end-to-end suite launches a headed Chromium with
the extension installed, drives fixture pages, and asserts the whole capture
path — run npx playwright install chromium first.
MIT
内容由编辑整理,部分信息来自 GitHub 与项目官网,版权归原作者所有。发现错误?报告问题