BrowserTools MCP

Give 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.

---

Why this instead of a CDP-based server

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.

Install

Two pieces: an MCP server (one command) and a Chrome extension.

1. Point your MCP client at the server

{
  "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.

2. Load the Chrome extension

1. Download or clone this repository.
2. Open chrome://extensions and turn on Developer mode.
3. Choose Load unpacked and select the chrome-extension directory.

That is the whole setup. There is no second server to start — the MCP server runs the connector itself.

3. Use it

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.

Tools

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.

Several tabs at once

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.

Large data stays out of the context window

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 Lig