chrome-devtools-mcp: Giving Coding Agents a Real Browser to Drive
This MCP server lets coding agents control and inspect a live Chrome browser via DevTools for debugging, performance analysis and reliable Puppeteer-based automation.
At a glance
- What is it?
- This MCP server exposes Chrome DevTools to AI coding assistants, covering setup, tooling, privacy defaults, and the cases where it is the wrong fit.
- Who is it for?
- Adopt chrome-devtools-mcp if your coding agent needs live browser control for debugging, network inspection, or performance analysis, and you accept the privacy trade-offs. Skip it if you need guaranteed support for non-Chrome browsers, want zero telemetry by default, or prefer a stateless automation tool.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
Why an Agent Needs Its Own Chrome
A coding agent that only sees static files cannot catch runtime errors, layout shifts, or slow network calls. chrome-devtools-mcp solves that by giving the agent a live Chrome instance to inspect and control. The README positions it for assistants like Claude, Cursor, and Copilot, with Antigravity and IBM Bob also listed. The target user is a developer who wants the agent to do more than write code: to open a page, read console errors, watch network traffic, and take screenshots. The tool is not a testing framework. It is a control plane for a browser, and the agent decides what to do with that control.
The Mechanism: MCP Server, Puppeteer, and DevTools
The project is a Model Context Protocol server written in TypeScript. It uses puppeteer to automate Chrome actions and the DevTools frontend to record traces and extract performance insights. When the agent calls a tool, the server translates it into a Chrome DevTools Protocol operation. The README highlights three capabilities: performance tracing with actionable insights, network request analysis, and console message inspection with source-mapped stack traces. Automation is described as reliable because the server waits for action results instead of firing commands blindly. That wait mechanism is the difference between flaky scripts and an agent that knows when a click actually landed. The architecture is thin: a Node process that speaks MCP on one side and CDP on the other.
Getting It Running: Config Snippets and Flags
Installation is a one-line npx command inside an MCP client config. The base configuration is a JSON block with "command": "npx" and "args": ["-y", "chrome-devtools-mcp@latest"]. For basic tasks, the README suggests adding "--slim" and "--headless" to reduce the tool surface and run without a visible window. For Antigravity, the recommended setup passes "--browser-url=http://127.0.0.1:9222" so the server connects to the browser the IDE already runs. Claude Code users can install via CLI with "claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest". There is also a plugin marketplace path for Claude Code that adds skills alongside the MCP tools. The CLI is mentioned in the docs but not detailed in the README, so the MCP route is the primary one.
Performance Insights and the CrUX Data Exchange
The performance feature records traces and then sends trace URLs to the Google CrUX API to fetch real-user experience data. The README calls this a holistic picture because it pairs lab data from the trace with field data from Chrome User Experience Report. That exchange is a privacy consideration. The URL of your trace goes to Google. You can disable it with the "--no-performance-crux" flag. This is a design trade-off: the tool trades a little privacy for context that a local trace alone cannot provide. If you are debugging a public site, the field data may be useful. If you are working on an internal app with sensitive URLs, you should disable the flag. The README is explicit about the data flow, which is more than most tools offer.
Usage Statistics Are On by Default
Google collects usage statistics by default. The README lists tool invocation success rates, latency, and environment information as examples. Opting out requires passing "--no-usage-statistics" in the args array. There is an environment variable escape hatch: setting CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS or CI disables collection. The README notes that this is independent from Chrome's own metrics, so disabling one does not disable the other. This default-on telemetry will surprise some users. The flag is easy to add, but a tool that sends data without asking is a dealbreaker for teams under strict data policies. At minimum, read the Google Privacy Policy before wiring this into a shared development environment.
Update Checks and Version Pinning
The server periodically checks the npm registry for updates and logs a notification. You can disable this with the CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS environment variable. The README recommends using "chrome-devtools-mcp@latest" so the client always gets the newest version. That is convenient but risky for reproducibility. A later release could change tool signatures or behavior, and your agent's prompts may break. If you need stable behavior, pin a specific version like "chrome-devtools-mcp@1.8.0" instead of using latest. The update check itself is harmless, but the recommendation to always run latest is a maintenance cost that the README glosses over.
Limitations: Browser Support and Security Boundaries
The README is blunt about browser support: only Google Chrome and Chrome for Testing are officially supported. Other Chromium-based browsers may work but are not guaranteed. The project commits to fixing issues for the latest Extended Stable Chrome, so if you are on an older Chrome version, you may be out of luck. The bigger limitation is the security model. The tool exposes the entire browser instance to the MCP client, letting it inspect, debug, and modify any data. The README warns against sharing sensitive or personal information with MCP clients. That is not a hypothetical. An agent with this tool can read cookies, local storage, and network request bodies. If your MCP client is a hosted service, that data leaves your machine. This is the wrong tool for any workflow that handles credentials or personal data without a sandbox.
Alternatives and the Slim Mode Trade-off
The main alternative is not another MCP server but a different approach: using a headless browser directly with Puppeteer or Playwright in a test script. That gives you the same Chrome control without an MCP layer and without the telemetry. The difference is that the agent cannot dynamically inspect pages in real time; it runs a pre-scripted flow. chrome-devtools-mcp is for interactive, agent-driven debugging, not for repeatable test suites. The project itself acknowledges this with its "--slim" mode, which strips down the toolset for basic browser tasks. Slim mode is a lighter weight option for agents that only need navigation and screenshots. If that is your use case, slim mode is a reasonable middle ground, but for pure automation, a plain Puppeteer script has fewer moving parts and no privacy flags to remember.
Editorial conclusion
Adopt chrome-devtools-mcp if your coding agent needs live browser control for debugging, network inspection, or performance analysis, and you accept the privacy trade-offs. Skip it if you need guaranteed support for non-Chrome browsers, want zero telemetry by default, or prefer a stateless automation tool. Before adopting, verify your Chrome version meets the requirement, decide whether to pass --no-usage-statistics and --no-performance-crux, and confirm your MCP client can handle the server's full browser access. The tool is a direct bridge between an agent and Chrome, not a general-purpose test runner, so treat it as a debugging aid rather than a CI replacement.
Community notes