chrome-devtools-mcp: an MCP server that hands your coding agent a live Chrome session

The gap chrome-devtools-mcp fills for coding agents

An agent that writes front-end code usually has no way to see what the page actually did. It can read source, run a build, and maybe fetch a URL, but the console error, the failed request, the long task in the trace are all invisible. chrome-devtools-mcp closes that gap by running as a Model-Context-Protocol server that a coding assistant connects to. The README describes it as giving the assistant "access to the full power of Chrome DevTools for reliable automation, in-depth debugging, and performance analysis".

The intended audience is narrow and specific: people using an MCP-capable agent (the README names Antigravity, Claude, Cursor and Copilot) who are working on something that runs in a browser. It is not a general web scraping tool, and it is not a replacement for a test runner. It is the debugging and inspection layer that sits between an agent and a Chrome process.

Puppeteer drives the browser, DevTools supplies the data

The mechanism has two halves. According to the README, the server uses puppeteer to automate actions in Chrome and to wait for action results automatically, which is why the tool list includes navigation and interaction rather than only inspection. The second half is Chrome DevTools itself: the server records traces through DevTools and extracts performance insights from them, reads network requests, takes screenshots, and collects browser console messages with source-mapped stack traces.

Source-mapped stack traces matter more than they sound. Minified or bundled output is the normal state of a modern front-end, so a raw console error is close to useless to an agent that has to locate the original file. The mapping is what turns a console message into an edit.

One design detail worth flagging: performance tooling may send trace URLs to the Google CrUX API to fetch real-user experience data, per the README, so field data is presented alongside lab data. That is an outbound network call from a debugging session. The --no-performance-crux flag disables it.

Installing chrome-devtools-mcp and running a first session

The requirements are short: a Node.js LTS version, current stable Chrome or newer, and npm. The README's default client config uses npx so no global install is needed. Add this to your MCP client's server list:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest"]
    }
  }
}

The README notes that pinning @latest keeps the client on the newest server version. If you only need basic browser tasks, the documented slim mode adds --slim and --headless to the same args, which trims the tool surface.

For Claude Code specifically, the README gives a CLI path instead of hand-editing JSON:

claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest

The --scope user flag makes the server available across projects rather than only the current one. Antigravity takes a different route, because it has its own built-in browser. Its documented config passes --browser-url=http://127.0.0.1:9222 so the server attaches to the browser Antigravity is already using:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--browser-url=http://127.0.0.1:9222"]
    }
  }
}

In that mode the README is explicit that the server will not launch a browser for you: if nothing is listening on 9222, you have to start the browser first. A first useful task is to point the agent at a local page and ask it to open the page, report console messages, and list failed network requests. The README points to a separate tool reference document for the exact tool names, so check that file rather than guessing at capabilities.

If you are working on Windows under WSL, note that the server has to reach a Chrome binary; the repository does not document a WSL-specific setup path, so treat that as unverified ground.

What the server sends home, and how to stop it

Two background behaviours are on by default and both are documented. Usage statistics (tool invocation success rates, latency, environment information) are collected by Google and enabled unless you opt out. The README gives the opt-out as an argument:

"args": ["-y", "chrome-devtools-mcp@latest", "--no-usage-statistics"]

Collection is also disabled when the CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS or CI environment variables are set, which means CI runs are already excluded. The README stresses that this is independent of Chrome's own metrics: opting out of one does not opt you out of the other.

The second behaviour is an update check. The server periodically queries the npm registry and logs a notification when a newer version exists. Set CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS to stop it. In an air-gapped or registry-restricted environment, that check will fail quietly or noisily depending on your network policy, and disabling it is the cleaner option.

The browser content exposure is the real limitation

The README's first disclaimer is the one to read twice: the server exposes the contents of the browser instance to MCP clients, which can inspect, debug and modify any data in the browser or DevTools. That is the whole point of the tool and also its sharpest edge. An agent with this server attached can read cookies, local storage, authenticated API responses and form values from whatever profile it is driving, and that content flows to the model provider behind your client.

There is no documented per-domain allowlist, no documented redaction layer, and no documented read-only mode. The mitigation the README offers is behavioural: avoid sharing sensitive or personal information you do not want to share with MCP clients. In practice that means a dedicated Chrome profile with no logged-in sessions for anything you would not paste into a chat window.

Browser support is the second constraint. Official support covers Google Chrome and Chrome for Testing only. Other Chromium-based browsers "may work, but this is not guaranteed", and the README tells you to use them at your own discretion. If your product ships to Firefox or Safari, this tool will not tell you anything about those engines. And if you are looking for a deterministic, assertion-based regression suite that runs on every commit, this is the wrong category of tool: an agent-driven browser session is exploratory, not a test harness.

chrome-devtools-mcp versus Playwright MCP

The comparison people search for is against Playwright MCP, and the difference is in what each one is built on. chrome-devtools-mcp is built on puppeteer and the Chrome DevTools front end, so its performance story comes from DevTools traces and its debugging story from DevTools panels: console messages with source maps, network request inspection, screenshots. It is Chrome-only by policy.

Playwright MCP, by contrast, is built on the Playwright browser automation stack, whose distinguishing feature is a single API across Chromium, Firefox and WebKit. If your reason for automating a browser is that you need to check behaviour on more than one engine, or you want the accessibility-tree based interaction model that Playwright's tooling exposes, that is a different foundation and a different answer. The honest framing is that these are not competing implementations of one thing: one is a DevTools bridge for a single engine, the other is a cross-engine automation layer. Pick by which browser matrix you actually have to cover. The README does not offer a comparison table or benchmarks, so any claim about which is faster would be invented.

Licence, release cadence and the cost of staying current

The project is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files. The repository carries a LICENSE file and a third_party/ directory, and the build runs a script that appends Lighthouse notices to the bundle, which tells you the shipped artifact embeds third-party code with its own attribution requirements. If you vendor the built output rather than installing from npm, read those notices before redistributing. Nothing here is legal advice; the Apache-2.0 text governs.

On cadence, the last push to the repository was on 2026-08-25, and the release history shows v1.6.0 on 2026-07-14, v1.7.0 on 2026-08-10 and v1.8.0 on 2026-08-25, while package.json on the default branch already reads version 1.9.0. That is a steady release rhythm, and it is also the upgrade cost: the README recommends chrome-devtools-mcp@latest, so your client silently picks up new tool surfaces, new arguments and new default behaviours on restart. The usage statistics and update check settings are the clearest example of defaults that can change under you. If you need reproducibility, pin an explicit version in the args array instead of @latest and bump it deliberately.

Skills, plugins and the CLI path

Beyond the plain MCP server, the repository ships plugin manifests for several clients: .claude-plugin/, .cursor-plugin/, a gemini-extension.json, a plugin.json and a skills/ directory. The README shows the Claude Code plugin route as a marketplace add followed by an install command, and warns that if you previously installed the MCP server manually you should remove it first so the two do not conflict.

There is also a CLI documented in docs/cli.md for use without MCP at all, and package.json declares two binaries, chrome-devtools-mcp and chrome-devtools. That matters if your agent host does not speak MCP, or if you want to script a single inspection step in a shell pipeline. The README does not document rollback or uninstall steps for the plugin route, so plan on removing the marketplace entry manually if you back out.

Editorial conclusion

Adopt chrome-devtools-mcp if your agent already runs against a local dev server and you want real DevTools data (console, network, traces) rather than screenshots of a headless page. Skip it if you need cross-browser coverage, since the README restricts official support to Google Chrome and Chrome for Testing, or if the page under test holds credentials you are unwilling to expose to an MCP client. Before wiring it into a shared config, start it once with --no-usage-statistics and confirm which Chrome binary it launches, because the default config lets the server pick the browser.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes