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. The connector binds 127.0.0.1 and, per the README, refuses non-loopback addresses; in 1.x it bound 0.0.0.0, which is the vulnerability the 2.0 notes point at. 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; allTabs: true reads across every tab.

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

The tool surface splits 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 more interesting decision is what does not go through tool calls. Whole-history payloads are exposed as MCP resources, and tools link to them with resource_link so the agent fetches them only when it decides to. Those resources are browser-tools://console/{tabId|all}, network, har, screenshot/{name} and audit/{reportId}. Log tools attach a resource link when a read was cut short; network reads always offer a HAR 1.2 file; screenshots always link to the stored image, which the README notes is the only way to see one too large to inline. The last 20 full Lighthouse reports are kept under audits/ in the screenshot directory. Reads take limit and offset, and the log tools take keywords, with examples like getConsoleErrors({ keywords: ["hydration"], limit: 20 }) and getNetworkLogs({ urlKeywords: ["/api/"], bodyKeywords: ["quota"], limit: 10 }). Results come back newest-first and report total alongside returned, so the agent can tell it is seeing a slice.

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. There is no store listing mentioned. 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.0 is labelled the security rewrite, and v2.0.2 is labelled five defects found while specifying 2.1, which tells you the rewrite shipped with known rough edges that are still being worked through. The README says 1.2.x has a critical vulnerability 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, with the connector now loopback-only rather than bound to 0.0.0.0. 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.2.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; the project does not offer a version-pinning recommendation in the material available.

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, and the material does not describe the gating mechanism in detail, 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, though the material does not discuss attribution requirements or what happens to the licence if the project changes hands; that is a question for your own counsel, not something to infer here. The cadence is worth reading carefully. v1.2.0 landed in March 2025 with SEO, performance and NextJS audits, screenshot auto-paste and bug fixes. Then nothing visible until August 2026, when v2.0.0 and v2.0.2 arrived two days apart. A rewrite of that size after a long quiet period means the 2.x line is young and the 2.1 work is already scoped against defects found in 2.0. 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, and the README does not describe a version-compatibility check between them. 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.2.x install is still in use.

Official sources

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