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

The problem is Chrome 136, not the lack of a browser tool

Plenty of MCP servers can drive a browser. The README's argument is about which browser they drive. Since Chrome 136, the browser refuses remote debugging on your default profile, and that profile is the one holding your logins. So a CDP-based server has to launch a separate automated browser and you rebuild your auth state in it before you can look at anything. BrowserTools MCP takes the other route: a DevTools extension attaches to the session you are already in, on the page you are already on. The target user is an engineer debugging an authenticated application, not an engineer writing end-to-end tests. The README states that position directly: automation-first servers are the right choice for writing tests and the wrong choice for debugging the app you are actually looking at. That is a narrow audience, and the project is honest about being narrow.

One process, a loopback socket, and a DevTools panel that only holds settings

Version 2.0 collapsed three processes into one. The MCP server runs the connector itself, so there is no second server to start. Capture begins when Chrome DevTools is open on a page. The BrowserTools panel in DevTools is for settings and status only, not for starting capture. Each tab with DevTools open is tracked separately, telemetry is attributed to the tab that produced it, and retention is per tab, so a noisy page cannot evict the history of the tab 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 take that position. Every result reports the tabId and url it came from plus otherTabs, so a wrong-tab answer is visible rather than silent. If you need to address a specific tab, call listBrowserTabs and pass its tabId.

Sixteen tools, three prompts, and resources for the data that would otherwise flood the context window

The README's tool table lists 22 tools, including listTabs, readTab, navigateBrowser, navigateTab, softClick and softType for working with tabs. The rest split into log reads (getConsoleLogs, getConsoleErrors, getNetworkLogs, getNetworkErrors), page inspection (getSelectedElement, getPageInfo, getBrowserStorage, listBrowserTabs, takeScreenshot, refreshBrowser), housekeeping (getConnectionStatus, wipeLogs) and four Lighthouse audits covering accessibility, performance, SEO and best practices. Three prompts ship with it: debuggerMode, auditMode and nextjsSeoAudit. All tools declare MCP output schemas, so clients get structured data instead of prose, and read-only tools are annotated so clients can auto-approve them. The README's table notes that getConsoleLogs is filterable by keyword with paging, and that takeScreenshot returns the screenshot as an image plus its file path.

Install: one JSON block, one unpacked extension, and a doctor command

The MCP client config is a single entry: command npx with args ["-y", "@agentdeskai/browser-tools-mcp@latest"] under the server name browser-tools. On Windows, if the client cannot find npx, the README says to use "command": "cmd" with "args": ["/c", "npx", "-y", "@agentdeskai/browser-tools-mcp@latest"]. Node 22.19 or newer is required; check with node --version, and if you use nvm or asdf make sure the editor inherits the same version, because an editor launched from a different shell will not. The extension side is manual: clone or download the repository, open chrome://extensions, turn on Developer mode, choose Load unpacked, and select the chrome-extension directory. When nothing works, npx @agentdeskai/browser-tools-mcp --doctor reports which piece is missing. For watching capture live, the README shows starting the connector with npx @agentdeskai/browser-tools-server --verbose, which prints lines like a console error with tab id and message, or a network 500 with method, URL and duration. Without --verbose the connector only reports connect and disconnect, so a working setup and a silent one look identical. That is a real usability gap rather than a feature.

The 1.x to 2.0 jump is a security migration, and skipping it is not an option

The release history is unusually blunt. v2.0.2 is labelled five defects found while specifying 2.1, v2.0.3 is labelled Security, and v2.0.4 followed a day later. The README says 1.x is unsupported, has known critical vulnerabilities (remote code execution, unauthenticated access to captured data) and tells readers to upgrade, pointing at MIGRATION.md and SECURITY.md. Two specific changes are named: one process instead of three, and no unauthenticated local server. The README also lists credentials scrubbed before they leave the browser and a real test suite as part of the rewrite. If you have a 1.x install anywhere, the version number in your MCP config is the thing to check, and note that the config in the README pins @latest rather than a fixed version, which means an upgrade can arrive without you changing anything. Whether that is convenient or risky depends on your tolerance for unannounced changes.

Where it stops being the right tool

The extension is loaded unpacked, so it is a developer-machine setup, not something you roll out to a fleet or run in CI. Capture depends on DevTools being open, which means it is tied to a human sitting in front of Chrome. A CDP-based server such as Chrome DevTools MCP or Playwright MCP drives a fresh automated browser, which is exactly what you want for repeatable test runs, headless execution and scripted navigation; BrowserTools MCP cannot do those things and does not claim to. The trade is that a CDP server makes you recreate auth state in a throwaway profile, which the README frames as the cost you avoid here. There is a second, quieter limit: the tool sees what your browser sees, including cookies and storage, and getBrowserStorage returns localStorage, sessionStorage and cookies with values gated. That gating is a mitigation, not a guarantee, so treat it as unverified. For a page that only reproduces behind a corporate SSO flow or a device-bound session, the attach-to-my-session model is the whole point; for anything you want to run unattended, it is the wrong shape.

Maintenance cost, licence, and what the version cadence implies

The project is MIT licensed, which permits commercial use and modification; attribution requirements and what happens to the licence if the project changes hands are questions for your own counsel, not something to infer here. The cadence is worth reading carefully. The recent releases are v2.0.2 on 12 August 2026, then v2.0.3 (Security) on 26 October and v2.0.4 on 27 October 2026. The 2.x line is young, and v2.0.2's own title says its fixes are defects found while specifying 2.1. Two maintenance obligations follow for anyone adopting it. First, the Chrome extension is loaded unpacked from a cloned repository, so keeping it current is a manual pull rather than an automatic store update. Second, the MCP server is pulled with @latest, so server-side changes arrive on their own while the extension stays wherever you last cloned it. Those two halves can drift apart. The --doctor command is the closest thing to a diagnostic, and it reports which piece is missing rather than whether the pieces match.

Editorial conclusion

Adopt BrowserTools MCP if you debug pages behind a login and want your agent reading the session you already have open; skip it if you need scripted, repeatable browser automation in CI, where a CDP-driven server is the right shape. Before trusting it, run npx @agentdeskai/browser-tools-mcp --doctor, confirm Node 22.19 or newer with node --version, and read MIGRATION.md and SECURITY.md if any 1.x install is still in use.

Frequently asked questions

Official sources

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