BrowserTools MCP

Streams console output, network traffic, screenshots and Lighthouse audits from your real Chrome session into any MCP-compatible coding agent.

Stars
★ 7.3k
Last updated
4d ago
License
MIT
Primary language
TypeScript

At a glance

Works with
Universal · cross-platformClaude Code
You'll need
Node.js 22.19 or newerChrome (or another Chromium-based browser) for auditsChrome extension loaded via chrome://extensionsShell / CLINetwork accessLocal filesystemMCP Server
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.

  1. 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.
  2. Debugging an authenticated dashboard where recreating login state in a throwaway Playwright or Chrome DevTools MCP profile would be painful.
  3. Chasing failing or slow API calls with getNetworkLogs and getNetworkErrors filtered by URL or body keywords, then pulling the HAR resource for full analysis.
  4. Running runAccessibilityAudit or runPerformanceAudit with Core Web Vitals before shipping a release.
  5. Checking a Next.js site's SEO by combining the bundled nextjsSeoAudit prompt with runSEOAudit.
  6. 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 --version

Add 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 --doctor

How 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 --verbose

Common 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:3000

To share one browser session across several MCP clients, start the connector once and let clients attach:

npx @agentdeskai/browser-tools-server

For working on the project itself:

npm install
npm run build
npm test
npx playwright install chromium
npm run test:e2e

What are this agent's strengths and limitations?

Pros
  • 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.
Limitations
  • 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?

FollowAgents source review · FARS-2.1
Good
81/ 100 5-point scale 4.1 / 5
Trust 22/29
Reliability 12/14
Adaptability 15/18
Convention 15/18
Effectiveness 12/13
Verifiability 5/8
Why each dimension lost points
Trust22 / 29 · 3.8/5

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.

Reliability12 / 14 · 4.3/5

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.

Adaptability15 / 18 · 4.2/5

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.

Convention15 / 18 · 4.2/5

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.

Effectiveness12 / 13 · 4.6/5

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.

Verifiability5 / 8 · 3.1/5

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.

Risks and how to mitigate them
  • 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.
Evidence confidence: Low Reviewed Oct 20, 2026 Reviewed revision 349129ed6f87
See the full review method →

FAQ

Can someone else on my network see the captured logs?
No in 2.0: the connector binds 127.0.0.1 and refuses non-loopback addresses, the HTTP API requires a per-run token, and the WebSocket accepts browser-extension origins only. The README notes 1.x bound 0.0.0.0 and scanned private ranges, and that behavior is gone.
Does using it add any model API costs?
Not by itself. The project is MIT-licensed, the MCP server runs locally through npx, and it calls no vendor cloud; cost depends entirely on the MCP client and model you already use.
My first page load's requests are missing — why?
This is a documented limit: network capture starts when DevTools opens. Open DevTools first and reload the page to record a complete page load.
Will huge screenshots or long logs blow up the context window?
Screenshots are capped by screenshotMaxBytes (3 MB default) and re-encoded or downscaled; if still too large they are written to disk and the path is returned. Log and network history are exposed as MCP resources, reads accept limit/offset and keyword filters, and results report total alongside returned.
Can an audit reach my internal services?
By default no: link-local and cloud metadata addresses are never audited, and localhost or private pages are audited only while open in a connected tab or allowlisted via --audit-allow-origin, with every request including redirects and subresources re-checked. Behind a fake-IP proxy you must pass --audit-allow-private-network.
View on GitHub ↗ Install ↓

Compare agents like this one

The same FARS review applied across the shortlist this agent qualifies for.

Related agents