BrowserTools MCP: attach an MCP agent to the Chrome session you are already logged into

The problem: Chrome 136 closed the door on debugging your logged-in profile

Most browser-facing MCP servers drive a fresh, automated browser through the Chrome DevTools Protocol. That model is correct when the job is writing tests. It is the wrong model when the job is debugging the application you are currently looking at, because since Chrome 136 the browser refuses remote debugging on your default profile, the one holding your logins. The practical result is that you recreate your authentication state in a throwaway profile before you can inspect anything, and the session you reproduce is never quite the session that broke.

BrowserTools MCP takes the other route. It attaches to the browser session you are already in through a DevTools extension, so you stay logged in, stay on the page you were already on, and the agent reads what you see. The intended audience is a developer working inside an MCP-compatible client (Cursor, Claude Code, Windsurf, Cline, Zed, Gemini CLI) who spends real time in DevTools and wants that context to reach the model without copy-paste. It also returns Lighthouse-grade performance, accessibility and SEO data, which the automation-first servers do not.

One connector process, one extension, per-tab telemetry

Version 2.0 is described in the README as a rewrite: one process instead of three, no unauthenticated local server, credentials scrubbed before they leave the browser, and a real test suite. The repository layout matches that description, with browser-tools-mcp and browser-tools-server as npm workspaces under a private root package, plus a chrome-extension directory loaded unpacked into Chrome.

The data flow is extension to connector to MCP client. The Chrome extension captures console output, network activity and screenshots from the tab under inspection. The connector, run by the MCP server itself, binds 127.0.0.1 and refuses non-loopback addresses. The client then calls tools such as getConsoleLogs, getNetworkLogs, getSelectedElement or runAccessibilityAudit.

Every tab with DevTools open is tracked separately, and telemetry is attributed to the tab that produced it. 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, meaning the one you most recently opened DevTools on, and a tab that reconnects does not steal that position. Each 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 you call listBrowserTabs and pass its tabId; allTabs: true reads across every tab.

The design choice worth noting is how large payloads are handled. Whole-history data is exposed as MCP resources rather than inlined, and tools link to them with resource_link so the agent fetches them only when it decides to. Console history, network history, a HAR 1.2 export, stored screenshots and unabridged Lighthouse reports all live behind browser-tools:// URIs. Read tools still take limit and offset, and log tools take keyword filters. Results come back newest-first and report total alongside returned, which tells the agent when it is only seeing part of the picture. That is a deliberate trade: the agent must make a second call to see everything, in exchange for not blowing the context window on the first one.

Installing BrowserTools MCP for Cursor or Claude Code

Setup is two pieces. First point your MCP client at the server by adding this entry to its configuration, which launches the published package through npx:

{
  "mcpServers": {
    "browser-tools": {
      "command": "npx",
      "args": ["-y", "@agentdeskai/browser-tools-mcp@latest"]
    }
  }
}

On Windows, if your client cannot find npx, the README gives a variant that routes through cmd:

{
  "mcpServers": {
    "browser-tools": {
      "command": "cmd",
      "args": ["/c", "npx", "-y", "@agentdeskai/browser-tools-mcp@latest"]
    }
  }
}

The server requires Node 22.19 or newer, and the workspace package.json sets the same floor in its engines field. Check it before you start:

node --version

If you use nvm or asdf, the README warns that your editor must inherit the same version. Second, load the extension: clone or download the repository, open chrome://extensions, turn on Developer mode, choose Load unpacked and select the chrome-extension directory. There is no second server to start, because the MCP server runs the connector itself.

For a first real use, open Chrome DevTools with 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 to check the console for errors, or to run an accessibility audit on the page. If nothing happens, the README points at a diagnostic command:

npx @agentdeskai/browser-tools-mcp --doctor

It reports which piece is missing. To watch capture happen live, the README shows starting the connector with --verbose, which prints lines such as a console error with its tab id and message, or a network 500 with method, URL and duration. Without verbose output the connector only reports connect and disconnect, so a working setup and a silent one look identical.

What the 2.0 rewrite actually changed, and what it costs you

The security posture is the headline change. In 1.x the connector bound 0.0.0.0, and the README states plainly that 1.2.x has a critical vulnerability, pointing readers at SECURITY.md and MIGRATION.md. In 2.0 the connector is loopback only and credentials are scrubbed before they leave the browser. Storage access is gated: getBrowserStorage returns localStorage, sessionStorage and cookies, but the README describes values as gated rather than freely readable.

The cost of the rewrite is an upgrade path. If you are running 1.x, the README does not describe rollback, and MIGRATION.md is where the project puts the transition detail. Anyone pinning an old version to avoid the change is holding a known vulnerability.

A second cost is environmental. Node 22.19 or newer is a hard floor, and the npx launch means your MCP client must be able to spawn a process that resolves the published package. On Windows that is the documented failure point. Neither of these is unusual for an MCP server, but both are the kind of thing that produces a silent no-connection state rather than an error message, which is why the --doctor flag exists.

Where BrowserTools MCP is the wrong tool

This is not a test automation framework. It has no scripting API for driving a browser, no headless mode, and no way to run unattended in CI. If your goal is a repeatable end-to-end suite, a Playwright-based server is the correct instrument and this one will fight you.

It also depends on a human having DevTools open. Capture begins when DevTools opens, so an agent working alone against a page nobody is inspecting gets nothing. The per-tab model is a strength when you are debugging three tabs and a liability when you want a single merged stream without asking for allTabs.

Finally, the tool captures whatever your browser sees. That includes cookies and request bodies. Loopback binding and credential scrubbing reduce the exposure but do not make it zero, and the README does not claim otherwise. If you routinely browse production admin panels in the same profile you debug in, that is a decision to make deliberately rather than by default.

BrowserTools MCP versus a CDP-driven Playwright MCP server

The comparison the project itself draws is with Chrome DevTools MCP and Playwright MCP. The difference is not features, it is which browser is being observed. A CDP-driven server launches or attaches to an automated browser under its own control. That gives it determinism: same profile, same state, same result on every run, which is exactly what a test needs. It also means the browser is not the one you are logged into, and since Chrome 136 you cannot point it at your default profile.

BrowserTools inverts both properties. You get your real session, your real logins, your real page, and the agent sees what you see. You lose determinism, because the browser is a live thing you are also typing into. For interactive debugging of an authenticated app, that trade is worth making. For regression testing, it is not, and the README does not pretend otherwise.

The second difference is audit data. BrowserTools exposes Lighthouse accessibility, performance, SEO and best-practices audits as tools, alongside three prompts (debuggerMode, auditMode, nextjsSeoAudit) that give the agent a workflow rather than a wall of tool descriptions. The automation-first servers do not report Lighthouse-grade data, according to the README.

Licence, maintenance and upgrade cost

The project is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and licence text are retained. That is a permissive choice with no copyleft obligation on your own code, though the usual caveat applies: this is a description of the licence identifier, not legal advice, and if you are embedding the connector in a product you should read LICENSE yourself.

Maintenance is current. The last push was on 2026-08-12, and v2.0.2 shipped the same day, five days after v2.0.0 on 2026-08-10. The release notes describe v2.0.2 as fixing five defects found while specifying 2.1, which tells you the project is still moving and that a 2.1 is planned. The gap before that is instructive: v1.2.0 landed on 2025-03-10, so the 2.0 line represents roughly five months of work landing in one stretch.

Upgrade cost is concentrated in the 1.x to 2.x jump. The architecture changed from three processes to one, so any local scripts or launch configuration you built around the old server layout will need reworking, and MIGRATION.md is the document to read. Within the 2.x line the surface looks stable: the workspace root exposes build, typecheck, test, test:unit, test:integration, test:e2e and test:all scripts through vitest, so you can run the project's own suite against a checkout before trusting it.

Editorial conclusion

Adopt BrowserTools MCP if you debug an authenticated app in a real Chrome profile and want your agent to read the console and network tab you are staring at. Skip it if your work is scripted browser automation or CI testing, where a fresh automated browser is the correct model. Before installing, confirm Node is 22.19 or newer, confirm your client can reach npx on Windows, and read SECURITY.md and MIGRATION.md if you are coming from 1.x, because the README states 1.2.x carries a critical vulnerability. After setup, run npx @agentdeskai/browser-tools-mcp --doctor to see which piece is missing rather than guessing.

Frequently asked questions

Official sources

1. AgentDeskAI/browser-tools-mcp on GitHub
2. License: MIT
3. Project website
4. README
5. Releases