BrowserTools MCP
Streams console output, network traffic, screenshots and Lighthouse audits from your real Chrome session into any MCP-compatible coding agent.
- Source repo
- AgentDeskAI/browser-tools-mcp
- Stars
- ★ 7.3k
- Last updated
- 4d ago
- License
- MIT
- Primary language
- TypeScript
- FA score
- 81/100 · Good
At a glance
- Works with
- Universal · cross-platformClaude Code
- You'll need
- Typical use
- A frontend developer asks the agent in Cursor to read console errors from the page they are already looking at, instead of copy-pasting stack traces.
- Main limitation
- Setup is genuinely two steps: configure the MCP server and manually load a Chrome extension, then open DevTools each session.
- Source review
- 81/100 · Good
What does this agent do, and when should you use it?
BrowserTools MCP is a two-part tool: an MCP server launched with npx (@agentdeskai/browser-tools-mcp) and a Chrome extension you load unpacked. Instead of driving a fresh automated browser, it attaches to the Chrome session you are already logged into via a DevTools extension, capturing console logs, XHR/fetch activity, the selected element, page info, screenshots and browser storage. It exposes these through 16 tools plus three bundled prompts (debuggerMode, auditMode, nextjsSeoAudit) and a set of MCP resources to clients such as Cursor, Claude Code, Windsurf, Cline, Zed and Gemini CLI. Version 2.0 collapses three processes into one, binds only to 127.0.0.1, requires a per-run token, and scrubs Authorization/Cookie headers, JWTs, cloud keys and vendor tokens before data leaves the browser. It also runs Lighthouse accessibility, performance, SEO and best-practices audits from a separate browser process that is blocked from internal networks and cloud metadata endpoints by default. Node.js 22.19 or newer is required, and the project is MIT licensed.
Capture begins on any tab where DevTools is open; the extension forwards telemetry to a local connector, and the MCP server exposes getConsoleLogs, getConsoleErrors, getNetworkLogs, getNetworkErrors, getSelectedElement, getPageInfo, getConnectionStatus, listBrowserTabs, takeScreenshot, refreshBrowser, getBrowserStorage, wipeLogs, plus runAccessibilityAudit, runPerformanceAudit, runSEOAudit and runBestPracticesAudit. Each DevTools tab is tracked and retained separately; tools act on the current tab (the most recent one to open DevTools) unless you pass a tabId or allTabs, and every result reports its tabId, url and otherTabs. Whole-history payloads are served as MCP resources — browser-tools://console/{tabId|all}, browser-tools://network/{tabId|all}, browser-tools://har/{tabId|all}, browser-tools://screenshot/{name} and browser-tools://audit/{reportId} — and tools link to them with resource_link instead of inlining. Log reads accept limit, offset and keyword filters and return newest-first with both total and returned. Audits launch a separate Chromium browser and keep the last 20 full Lighthouse reports under audits/ in the screenshot directory.
- A frontend developer asks the agent in Cursor to read console errors from the page they are already looking at, instead of copy-pasting stack traces.
- Debugging an authenticated dashboard where recreating login state in a throwaway Playwright or Chrome DevTools MCP profile would be painful.
- Chasing failing or slow API calls with getNetworkLogs and getNetworkErrors filtered by URL or body keywords, then pulling the HAR resource for full analysis.
- Running runAccessibilityAudit or runPerformanceAudit with Core Web Vitals before shipping a release.
- Checking a Next.js site's SEO by combining the bundled nextjsSeoAudit prompt with runSEOAudit.
- Working with several open tabs and using listBrowserTabs to pick the right tabId so screenshots and logs come from the intended page.
How do you install or deploy this agent?
You need Node.js 22.19 or newer; verify first:
node --versionAdd the server to your MCP client configuration:
{
"mcpServers": {
"browser-tools": {
"command": "npx",
"args": ["-y", "@agentdeskai/browser-tools-mcp@latest"]
}
}
}On Windows, if the client cannot find npx, use:
{
"mcpServers": {
"browser-tools": {
"command": "cmd",
"args": ["/c", "npx", "-y", "@agentdeskai/browser-tools-mcp@latest"]
}
}
}Then clone the repository, open chrome://extensions, enable Developer mode, choose Load unpacked and select the chrome-extension directory. There is no second server to start. Verify the setup with:
npx @agentdeskai/browser-tools-mcp --doctorHow do you use this agent?
Open Chrome DevTools (F12) on the page you want to inspect — capture starts immediately; the BrowserTools panel is only for settings and status — then ask your agent things like "check the console for errors" or "run an accessibility audit on this page". To watch capture happen live during a fresh install:
npx @agentdeskai/browser-tools-server --verboseCommon flags cover port, screenshot directory, tool allow/deny lists and audit origin allowlisting:
npx @agentdeskai/browser-tools-mcp --port 3025 --screenshot-dir ./shots --only getConsoleErrors,getNetworkLogs --audit-allow-origin http://localhost:3000To share one browser session across several MCP clients, start the connector once and let clients attach:
npx @agentdeskai/browser-tools-serverFor working on the project itself:
npm install
npm run build
npm test
npx playwright install chromium
npm run test:e2eWhat are this agent's strengths and limitations?
- Attaches to your real, already-logged-in Chrome session, sidestepping Chrome 136's restriction on remote debugging for the default profile.
- 2.0 runs as a single process on 127.0.0.1 with per-run token auth and scrubs Authorization, Cookie, JWT and cloud-key credentials before they leave the browser.
- Beyond logs and network data it delivers Lighthouse-grade performance, accessibility, SEO and best-practices audits, which automation-first servers generally lack.
- Whole-history data is exposed as MCP resources with resource_link, and read tools support limit/offset plus keyword filters while reporting total vs. returned.
- Per-tab retention with tabId, url and otherTabs in every result makes wrong-tab answers visible instead of silent.
- Includes a --doctor self-check, --only/--exclude tool filtering, and an MIT license.
- Setup is genuinely two steps: configure the MCP server and manually load a Chrome extension, then open DevTools each session.
- Network capture starts only when DevTools opens, so early page-load requests are missed unless you reload.
- Default console capture shows Chrome's "started debugging this browser" banner unless you switch the panel to Wrap page console.
- Firefox is untested and screenshots (which rely on the DevTools protocol) will not work there; Arc is best-effort and unverified headless.
- Audits spawn a separate browser and can take up to a minute, and their loopback/private-network rules take reading.
- Upgrading from 1.x is mandatory, not optional: 1.2.x has a critical vulnerability and older builds bound 0.0.0.0 and scanned private ranges.
How does this agent compare with similar options?
The README explicitly positions this against CDP-based servers such as Chrome DevTools MCP and Playwright MCP: those drive a fresh automated browser, which suits writing tests but forces you to recreate auth state because Chrome 136+ refuses remote debugging on your default profile. BrowserTools MCP attaches to the existing session through a DevTools extension and adds Lighthouse-grade performance, accessibility and SEO data the automation-first servers do not report.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| BrowserTools MCP This agent | 81 · Good | — | ★ 7.3k | 4d ago | TypeScript | Claude Code |
| JS Reverse MCP | 82 · Good | MCP serverFree | ★ 3k | 1mo ago | TypeScript | Codex · Claude Code |
| Interceptor | 57 · Major gaps | CLIFree | ★ 557 | 6d ago | TypeScript | Codex · Claude Code · Claude.ai |
| OpenTabs | 49 · Major gaps | CLIFree + model costs | ★ 989 | 2mo ago | TypeScript | Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
README and SECURITY.md document 2.x privilege reduction: loopback-only binding, refusal of non-loopback, per-run bearer token, extension-only WebSocket Origin, removal of the AppleScript path, and screenshot name allowlisting, with a cited connector-security regression test — adequate least_privilege evidence (3). Destructive/external actions (refreshBrowser, wipeLogs, audit launching a separate browser) rely on MCP client approval; the repo provides no own confirmation mechanism, so user_confirmation is 2. Data-flow transparency (redaction, double scrubbing, headers off by default, storage values gated) is well evidenced (3). Sensitive data handling has best-effort redaction plus tests (3). Dependency security shows only CI npm audit --audit-level=moderate; no lockfile or dependency list visible, so 2. External effects: audit browser has SSRF/metadata guards, but --audit-allow-private-network and --no-redact are high-risk switches only warned in docs, so 2. Rollback is limited to 1.x→2.x migration notes with no runtime undo/recovery, so 1. Source attribution has MIT copyright and GHSA id, but publisher is unverified, so 2.
README, tests and CI corroborate each other (multi-tab attribution, screenshot budget, redaction, audit egress), giving good self-consistency (3). Dependency availability only declares Node>=22.19 and npx install with no lockfile, so 2. Failure messages include --doctor, --verbose, explicit errors (unknown tab, AuditError naming refused host), so 3.
Targets multiple MCP clients (Cursor, Claude Code, Windsurf, etc.) with clear scenarios (3). Capability boundaries are well defined in the Tools table and Known limits (3). Trigger precision depends on DevTools-open capture and current-tab semantics, with implicit triggering and multi-tab ambiguity, so 2. Environment fit covers multi-OS CI and several Chromium browsers, but Firefox is explicitly unverified and audits fail behind fake-IP proxies, so 2.
README is well structured and layered (3). Install notes include Windows variant and --doctor (3). Naming stability is weakened by the 2.0 rewrite and 1.x breaking changes, so 2. Examples exist as tool-call snippets but no FAQ, so 2. Known limitations are thorough (3). MIT license is complete (3). Versioning has 2.0 rewrite and migration notes but no CHANGELOG file, so 2. Maintenance responsibility has a SECURITY reporting channel and 72-hour response, but publisher is unverified, so 2.
Outputs use structured schemas, resource_link, paging and total/returned, giving high usability (3). Differentiated value versus CDP automation servers (attaching to the logged-in session, Lighthouse) is clear (3). Cost side: audits launch a separate browser taking up to a minute and screenshots have a byte budget, so cost_benefit is 2.
Many README claims trace to SECURITY.md and test files (GHSA, regression test paths), but some are assertions without direct file support, so 2. Cross-source corroboration exists (README/SECURITY/tests/CI) but nothing was independently executed, so 2. Fact/inference separation is reasonable though README contains marketing-style comparisons, so 2.
- Publisher identity is unverified; verify npm package and repository ownership before installing.
- 1.x carries a CVSS 9.8 critical vulnerability (GHSA-xvrv-w8pg-f25f); use 2.x and avoid old versions.
- --no-redact and --audit-allow-private-network materially weaken security boundaries; use only with explicit awareness.
- Redaction is pattern-based best-effort, not a guarantee; bespoke token shapes may leak.
- Firefox is unverified and screenshots will not work there; audits fail behind fake-IP proxies.
- This is a static source review with no tests executed; confidence is low.