Chrome diagnostics are the reason to choose it
Chrome DevTools MCP gives a coding agent access to the browser evidence developers usually gather by hand. It can inspect console messages and network requests, take screenshots, automate input, and record performance traces with DevTools insights. Source-mapped stack traces help connect a browser exception to authored code. The project also ships a standalone CLI, so MCP is not the only way to call the tools.
The distinction matters after a bug reaches Chrome. A generic browser agent may confirm that a button does nothing. This server can also inspect the console error, failed request, and page state around that click. For basic work, --slim exposes just 3 tools for navigation, script evaluation, and screenshots. The full server earns its place when the investigation needs Chrome's debugging surface.
The one-line setup still needs Chrome and a profile plan
The usual configuration runs npx -y chrome-devtools-mcp@latest from an MCP client. The README requires Node.js LTS, npm, and current stable Chrome or newer. There is no application API key to obtain for a local launch. Client instructions cover Claude Code, Codex, Cursor, Copilot, Gemini CLI, and several other hosts, which removes much of the config-file guesswork.
By default, the server creates a Chrome profile under the user's cache directory and reuses it on later runs. Only 1 browser can use that profile at a time. Passing --isolated creates a temporary profile and deletes it when Chrome closes, a better fit for parallel agent sessions and disposable test state. Connecting to a browser already running on port 9222 preserves its state, but the documentation warns that any local application able to reach that debugging port can control it.
What happened when we ran it
Our sandbox installed commit 45c1c6c in 57 seconds, pulling 1,130 npm packages and occupying 615 MB on disk. The TypeScript build then succeeded in 38 seconds. Npm audit found 0 known vulnerabilities: 0 critical, 0 high, 0 moderate, and 0 low. We ran it in a fresh unprivileged Debian container with Node 22, 3 CPUs, 8 GB of RAM, and no secrets.
The test command exited with code 1 after 131 seconds. Its final stack passed through Puppeteer's Connection._rawSend, TargetManager.initialize, CdpBrowser._attach, CdpBrowser._create, and ChromeLauncher.launch, followed by the failing-tests summary. The log tail does not include the originating exception or a test count. It shows where execution ended, not whether a missing package, Chrome policy, or project defect caused it.
The source tree itself was large: 115,104 files, about 12,206,870 lines, and 1,546.8 MB checked out. Our scan found 8 CI workflow files, a tests directory, and no Dockerfile. Those facts make the passing build useful but incomplete evidence for source contributors. commit 45c1c6c compiled in our environment. Its supplied browser-backed suite did not finish cleanly there.
A dedicated browser profile is the sensible security boundary
The README says an MCP client can inspect, debug, and modify data in the connected browser. A personal Chrome profile may contain active sessions, private pages, saved form state, and tabs unrelated to the task. Give the server a separate profile with test accounts and only the pages it needs. The --isolated option handles disposable work, while a named user-data directory suits repeatable authenticated testing.
Two outbound data choices are enabled by default. Usage statistics include tool success, latency, and environment information. The --no-usage-statistics flag disables them. Performance analysis may send trace URLs to Google's CrUX API for field data, and --no-performance-crux turns that off. The server also checks npm for updates unless its update-check environment variable is set. Teams with privacy or reproducibility rules should put all 3 choices in checked configuration.
Sandboxed and remote Chrome need extra engineering
The troubleshooting guide says some macOS and Linux MCP sandboxes prevent Chrome from creating its own sandbox, and Chrome will not start as root. Its documented workaround is to run Chrome outside the client sandbox and connect with --browser-url. That advice is relevant to our failed 131-second run, but it does not explain it: our container was already unprivileged, and the supplied log tail does not expose the original error.
Remote debugging deserves the same care as a production admin socket. Chrome now requires a non-default user-data directory for the documented port-forwarding setup. Open issue 2837 also reports that --blockedUrlPattern and --allowedUrlPattern may treat non-default ports and trailing-dot hostnames differently from an operator's intent. Until that issue is resolved, use OS and network isolation rather than trusting URL patterns as the only containment layer.
The October 1 push shows active maintenance
GitHub showed 52,851 stars, 76 open issues, and 24 open pull requests on October 1, 2026. The repository was pushed that day. Release 1.10.1 shipped on September 23 with a Rollup export-condition fix, shortly after 1.10.0. Those dates and the live pull-request queue point to active work, even though the combined GitHub count of 100 must not be described as 100 bugs.
The project is also candid about its testing cost. Open issue 2639 says many tests use a real browser and are slow, then proposes moving more tool-handler and formatter checks to mocks while retaining fewer high-level browser tests. That context matches the operational lesson from our run: the npx entry is easy, while browser parity is the real setup task. If your agent only needs the 3 slim actions, start there. Add the full DevTools surface when a trace, network record, or source-mapped exception will change the diagnosis.