chrome-devtools-mcp: Google's Official MCP Server That Lets AI Agents Drive Chrome DevTools
If you're using Claude Code, Cursor, or any MCP-capable AI agent for frontend work, there's now an official way to let your agent drive Chrome directly — and it's maintained by Google's Chrome DevTools team.
The package is called chrome-devtools-mcp, it's Apache-2.0 licensed, and as of April 2026 it's at v0.21.0 after 43 releases in 7 months. This isn't a one-off experiment — Chrome team is shipping it on a roughly weekly cadence.
Here's what changed for me after installing it, and what you need to know before doing the same.
TL;DR
- Official Google MCP server wrapping Chrome DevTools via Puppeteer
- 29 tools across 7 categories (input, navigation, performance, network, debugging, emulation, memory)
- One-line install for Claude Code:
claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest - Chrome M144+ ships
--autoConnect— AI attaches to your already-running Chrome session (keeps logins, cookies, extensions) - Not a Playwright MCP replacement. Different use case (live debugging vs deterministic E2E tests)
- Security-sensitive: browser content is shared with your MCP client; disable telemetry with
CI=1
What it actually does
Before chrome-devtools-mcp, asking an AI agent to debug a web page meant a lot of manual copy-pasting. You'd screenshot the Network tab, paste console errors as strings, describe what you see. The AI was always one abstraction layer away from the actual browser state.
With the MCP server installed, your agent can:
- Navigate pages (
navigate_page,new_page, multi-tab control) - Click, type, drag, fill forms (
click,fill_form,upload_file,press_key) - Read the actual DevTools Performance trace (
performance_start_trace,performance_analyze_insight) - Execute Lighthouse audits (
lighthouse_audit) — including CrUX real-user data - Inspect every HTTP request natively, not via screenshot (
list_network_requests,get_network_request) - Read console messages with sourcemap-resolved stack traces (
list_console_messages) - Take memory heap snapshots for leak hunting (
take_memory_snapshot)
The full list is 29 tools, all surfaced via the standard MCP protocol. Any agent that speaks MCP — Claude Code, Cursor, Cline, Zed, Gemini CLI — can use them identically.
Installation
Method 1: MCP server only
claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest
--scope user makes it available across all your Claude Code projects. Use --scope project to limit to the current workspace.
Method 2: Plugin (MCP + Skills)
/plugin marketplace add ChromeDevTools/chrome-devtools-mcp
/plugin install chrome-devtools-mcp
The plugin bundle adds Chrome-curated Skills (prompt presets) alongside the MCP server. Higher-level commands like "run a performance audit" just work.
Requirements
- Node.js v20.19 or newer (LTS)
- Chrome Stable (M144+ recommended for
--autoConnect) - npm (comes with Node)
After installing, restart Claude Code and run /mcp to verify chrome-devtools (29 tools available) is listed.
The feature that changed my workflow: --autoConnect
Chrome M144 (December 2025) added support for --autoConnect. Instead of spawning a fresh Chrome instance every time, the MCP server attaches to your existing Chrome via remote debugging.
# 1. Start Chrome with remote debugging enabled
open -a "Google Chrome" --args --remote-debugging-port=9222
# 2. Register MCP pointing at it
claude mcp add chrome-devtools-live --scope local \
npx chrome-devtools-mcp@latest --autoConnect
Why this matters: your existing browser state — SSO sessions, extensions, developer tools panel position, the exact tab you were debugging — is preserved. You can manually reproduce an issue, hand off to AI mid-session, and the AI sees the same DOM you see.
Playwright MCP doesn't do this. Playwright is intentionally designed for test isolation, spawning fresh contexts. Different philosophy, different use case.
chrome-devtools-mcp vs Playwright MCP
This is the question that comes up every time.
| Concern | chrome-devtools-mcp | Playwright MCP |
|---|---|---|
| Primary purpose | Live debugging, performance audits | Deterministic E2E tests |
| Browser support | Chrome only | Chrome / Firefox / WebKit |
| Performance tracing | Native | Not supported |
| Lighthouse audit | Built in | Not supported |
| CrUX real-user data | Yes | No |
| Test isolation | Weak (by design) | Strong |
| CI/CD fit | Moderate | Excellent |
Rule of thumb: writing regression tests → Playwright MCP. Debugging why production is slow or a specific user hits an error → chrome-devtools-mcp. Most teams benefit from having both installed.
Real-world workflow examples
Weekly performance audit
Every Monday, for these 5 landing pages:
1. Run Lighthouse audit (mobile and desktop)
2. Compare Core Web Vitals (LCP, CLS, INP) to last week's numbers
3. Flag any score regressions > 5 points
4. Diagnose the root cause in the network waterfall
5. Output a markdown report
This used to be a 2-hour manual process. Now it's a 10-minute async handoff.
Pre-deploy smoke test
On localhost:3000:
1. Load home page — fail if any console errors
2. Complete signup form — fail if not redirected to onboarding
3. Authenticate and load dashboard — fail if any 4xx/5xx requests
4. Screenshot each step
5. Bail with error analysis on first failure
Production incident triage
With --autoConnect attached to your logged-in Chrome, you can say "reproduce the bug the customer reported on /app/settings" and the AI navigates there, clicks through, captures console + network, and returns the sourcemap-resolved stack trace.
Useful flags
-
--slim— reduces the tool surface to 3 essentials (navigate, click, snapshot). Saves MCP tokens when you don't need the full kit. -
--isolated— runs in an isolated Chrome profile, doesn't touch your personal session. -
--headless— for CI/CD. -
--browserUrl http://localhost:9222— explicit version of--autoConnect. -
--channel beta|canary|dev— target a non-Stable Chrome channel. -
--no-usage-statistics— opt out of Google telemetry (also respectsCI=1). -
--no-performance-crux— skip CrUX real-user data lookups.
Security caveats (do not skip)
1. Browser content is sent to your MCP client.
Anything rendered in the browser — DOM, cookies, localStorage — can end up in your AI model's context. Do not run DevTools MCP on tabs where you're logged into a bank, an internal admin panel, or anything with sensitive PII, unless you're comfortable with that data reaching your model API provider.
Mitigation: use --isolated to separate from your personal profile, or start Chrome with a dedicated profile argument.
2. Telemetry is on by default.
Google collects anonymized usage statistics. If that's not acceptable for your compliance requirements, set CI=1 in your shell env or append --no-usage-statistics.
3. Remote debugging port must be localhost-bound.
--autoConnect works by connecting to Chrome's remote debugging port (default 9222). If that port is exposed to your LAN or a public IP, anyone on the network can read your browser state or execute scripts in your session.
Verify binding with:
lsof -i :9222
You want to see 127.0.0.1:9222 or localhost:9222, never 0.0.0.0:9222. On shared networks, avoid the port-based flow entirely and let MCP spawn its own isolated Chrome.
FAQ
Does it work with Chromium forks like Edge, Brave, Arc?
Officially Chrome Stable only. Chromium-based browsers may work for basic cases but performance-analysis tools can be unreliable.
Is the Lighthouse audit slower than CLI Lighthouse?
A bit — you're paying the AI round-trip cost. If you only need raw scores, stick with CLI Lighthouse. If you want scores + root-cause analysis + a fix, the MCP path saves time overall.
Is it free?
Yes. Apache-2.0 open source, Google-maintained. No API keys, no subscription.
Verdict
If you use an MCP-capable AI agent for frontend work and you haven't installed chrome-devtools-mcp yet, you're leaving the single highest-leverage automation on the table. The install is five minutes, the learning curve is shallow, and the maintainer is the Chrome team itself.
The workflows that save the most time for me: weekly Lighthouse audits with regression diagnosis, pre-deploy smoke tests, and production incident triage with --autoConnect. If any of those land in your week, DevTools MCP is a straightforward win.
References
- Official repo: github.com/ChromeDevTools/chrome-devtools-mcp
- npm package: npmjs.com/package/chrome-devtools-mcp
- Chrome DevTools AI Agents docs: developer.chrome.com/docs/devtools/agents
- Announcement blog post: developer.chrome.com/blog/chrome-devtools-mcp
-
--autoConnectwalkthrough: developer.chrome.com/blog/chrome-devtools-mcp-debug-your-browser-session
Top comments (0)