Chrome DevTools MCP Review: Google's Browser for Agents

Originally published on andrew.ooo — visit the original for any updates, code snippets that aged out, or follow-up posts.

Every coding agent can now write a React component. Almost none of them can tell you why it takes 3.2 seconds to paint, which request 404'd, or why the memory graph climbs every time you open a modal. That gap — shipping code versus seeing it run — is what Chrome DevTools MCP is built to close.

It's an official Google project from the team behind Chrome DevTools and Puppeteer. It exposes a live Chrome instance to any MCP client — Claude Code, Codex, Cursor, Copilot, Gemini CLI, Antigravity — as a set of 58 tools covering input automation, network inspection, performance tracing, heap-snapshot analysis, Lighthouse audits, extension debugging and PWA install flows. As of September 15, 2026 the repo sits at 52,000+ GitHub stars, the npm package pulls ~1.5 million downloads a week, and version 1.9.0 shipped on September 8, 2026 with a new --no-javascript-evaluation safety flag and a package-format for "Agent Plugins 1.0".

I ran it under Claude Code and Codex for a week against a couple of Astro sites and one memory-leaky Vue dashboard. This is the review: what it does well, where it burns tokens, and how it compares to Playwright MCP and the "just use a CLI" crowd.

What Chrome DevTools MCP actually is

Strip the branding and it is three layers stacked on top of Puppeteer:

1. An MCP server (chrome-devtools-mcp on npm, Apache-2.0, TypeScript) that launches or attaches to Chrome and exposes tools over stdio. One npx line to install.
2. The real DevTools engine — the same trace-processing and insight code that powers the Performance panel in Chrome, plus the heap-snapshot parser and Lighthouse 13.4. The agent isn't scraping the DevTools UI; it's calling the same internals.
3. An experimental CLI (chrome-devtools <tool>) that talks to a background daemon over a Unix socket, so you can drive the same tools from a shell script or a skill without loading any MCP definitions into context.

The design principles doc is refreshingly blunt about its priorities: "Token-Optimized: 'LCP was 3.2s' is better than 50k lines of JSON. Files are the right location for large amounts of data." Heavy assets — screenshots, traces, heap snapshots, network bodies — are written to disk and referenced by path, not streamed back into the conversation.

Google is explicit that only Chrome stable and Chrome for Testing are supported. Other Chromium browsers "may work, but this is not guaranteed."

Installation: one JSON block

Add this to your MCP client config (.mcp.json for Claude Code, ~/.cursor/mcp.json for Cursor, ~/.gemini/settings.json for Gemini CLI):

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

Requirements are Node.js LTS, npm, and a current stable Chrome. The browser doesn't start until the first tool call that needs it; connecting to the server alone launches nothing.

The README's smoke test is one prompt:

Check the performance of https://developers.chrome.com

If Chrome opens, navigates, and the agent comes back with an LCP breakdown, you're live.

For basic browsing tasks, there is a --slim mode that collapses the tool surface to three tools — navigate, evaluate, screenshot:

"args": ["-y", "chrome-devtools-mcp@latest", "--slim", "--headless"]

This is the single most important flag for anyone who cares about context cost, and I'll come back to why.

The 58 tools, grouped

The tool reference is auto-generated and worth reading once. The categories:

Category	Count	Highlights
Input automation	10	click, fill_form, drag, upload_file, handle_dialog, click_at (coordinate mode, behind --experimentalVision)
Navigation	6	new_page with isolatedContext, navigate_page with initScript, wait_for text
Emulation	2	emulate (CPU throttle, network profiles, geolocation, UA, viewport, dark mode, extra headers)
Performance	3	performance_start_trace, performance_stop_trace, performance_analyze_insight
Network	2	list_network_requests (paginated, filtered by resource type), get_network_request (headers, cookies, body-to-file)
Debugging	9	evaluate_script, list_console_messages (with source-mapped stack traces), get_css_styles, lighthouse_audit, take_snapshot, screencast_start/stop
Memory	13	take_heapsnapshot, compare_heapsnapshots, get_heapsnapshot_retaining_paths, query_heapsnapshot_objects (behind --memoryDebugging)
Extensions	5	install_extension, reload_extension, trigger_extension_action (behind --categoryExtensions)
PWA	4	install_pwa, launch_pwa, get_os_app_state (behind --categoryPwa)
WebMCP / third-party	4	Call tools the inspected page itself exposes

Two things stand out versus every other browser MCP I've used.

First, the memory category exists at all. Thirteen heap-snapshot tools — retainers, dominators, duplicate strings, class-node queries, snapshot diffing — is not something you get from Playwright MCP, Browser Use, or any CDP wrapper. It's DevTools-team territory.

Second, pageId is required on every page-scoped tool since 1.8.0 (August 25, 2026). That is deliberate: it lets multiple agents or subagents share one server and route calls to their own tab without stepping on each other. It also makes the CLI trivially scriptable.

A real session: finding the LCP problem

Here's an abridged transcript from Claude Code on an Astro blog with a lazy-loaded hero image. Prompt:

Trace the homepage load, tell me what's hurting LCP, and fix it.

The agent's tool calls:

new_page          url=https://staging.example.dev
performance_start_trace  pageId=1 reload=true autoStop=true

The trace stop returns a compact summary, not a 40 MB JSON:

Trace recorded (4.1s). Core Web Vitals:
  LCP: 3,240 ms  (poor)   element: img.hero
  CLS: 0.02      (good)
  INP: n/a (no interaction)
Available insight sets: [main-frame-8f2a]
Insights: LCPBreakdown, LCPDiscovery, RenderBlocking, ImageDelivery

Then:

performance_analyze_insight  pageId=1 insightSetId=main-frame-8f2a insightName=LCPDiscovery

LCPDiscovery:
  - LCP image was NOT discoverable in initial HTML (loaded via JS after hydration)
  - fetchpriority=high not set
  - loading=lazy set on LCP element (this delays it)
  Estimated savings: ~1,900 ms

Claude then dropped loading="lazy", added fetchpriority="high" and a <link rel="preload">, re-ran the trace, and reported LCP down to 1,180 ms. Three tool calls to diagnose, one to verify.

The emulate tool turns the same loop into a mobile test:

emulate  pageId=1 cpuThrottlingRate=4 networkConditions="Slow 4G" viewport="390x844x3,mobile,touch"

Network debugging: the underrated feature

list_network_requests returns a concise table (URLs are truncated as of 1.9.0 — a fix for context bloat). get_network_request on a single reqid gives full request and response headers including Cookie and Set-Cookie, and can dump the body to a .network-response file instead of inline.

Version 1.9.0 also added a bundled cookie-debugging skill, which is telling: Google is starting to ship skills alongside the MCP, acknowledging that the model needs a procedure, not just a tool list.

A practical pattern from Codex on a login bug:

list_network_requests  pageId=1 resourceTypes=["xhr","fetch"]
get_network_request    pageId=1 reqid=17

The response headers showed Set-Cookie: session=...; SameSite=None without Secure on an http://localhost origin — which Chrome silently drops. Two calls, no browser opened by me.

The CLI: the answer to "MCP bloats my context"

Install globally and you get a chrome-devtools binary:

npm i chrome-devtools-mcp@latest -g
chrome-devtools status

chrome-devtools new_page "https://example.com"
chrome-devtools take_screenshot 1 --filePath shot.png
chrome-devtools evaluate_script "() => document.title" --pageId 1
chrome-devtools stop

The first call auto-starts a background daemon and a headless, isolated Chrome; state persists across commands. It's still labelled experimental, and since 1.9.0 the CLI has unrestricted filesystem access unless you pass --workspace=/path.

The loudest criticism of the whole project is context cost. On the Hacker News thread (604 points, 234 comments, March 2026) one commenter said flatly: "CLI. Always CLI. Never MCP. Ever." Another: "Note that this is a mega token guzzler in case you're paying for your own tokens!" Google's response was to ship the CLI and the --slim mode. If you're running a long agentic session, the sane setup is --slim in MCP for the model, and the full CLI reachable from a skill for the heavy diagnostics.

Attaching to your real Chrome (and why you might not want to)

By default the server launches its own Chrome with a dedicated profile at ~/.cache/chrome-devtools-mcp/chrome-profile. Three alternatives:

• --autoConnect (Chrome 144+): enable remote debugging at chrome://inspect/#remote-debugging, and the MCP attaches to your running browser — logged-in sessions, extensions, tabs and all. Chrome shows a permission dialog.
• --browserUrl http://127.0.0.1:9222: manual attach to a Chrome you started with --remote-debugging-port. Useful when the agent runs in a sandbox and Chrome runs outside it.
• --isolated: throwaway temp profile, deleted on exit. Use this for anything untrusted.

The README is blunt: the MCP lets clients "inspect, debug, and modify any data in the browser." An HN commenter, more colourfully: "You're literally one prompt injection away from someone having unlimited access to all of your everything." True of every attach-to-real-browser tool, and the reason 1.9.0 added --no-javascript-evaluation (disables evaluate_script, initScript, and JS in navigations) and configurable filesystem roots. Use them.

What it's genuinely good at

• Performance work. Nothing else gives an agent the actual DevTools insights engine — LCPBreakdown, RenderBlocking, ImageDelivery, DocumentLatency — as structured summaries. The trace buffer default was bumped to 1.2 GB in 1.9.0 to match DevTools.
• Memory leaks. take_heapsnapshot → interact → take_heapsnapshot → compare_heapsnapshots → get_heapsnapshot_retaining_paths is a workflow I had never seen an agent do unaided before.
• Console + source maps. list_console_messages with stack traces resolves to your original TypeScript lines, not the bundle.
• Concurrency. Required pageId and isolatedContext on new_page make multi-agent or parallel-subagent runs boring in the good way.
• Maintained by the source. Releases every two to three weeks, real changelogs, and the Chrome team on the issues.

Honest limitations

• Token cost is real. Full-mode tool definitions consume a meaningful slice of context before you've done anything, and take_snapshot on a dense page is expensive. A Reddit user measured ~14,700 tokens for a single accessibility snapshot of the Hacker News front page across the big browser MCPs. Use --slim, prefer evaluate_script returning small JSON over full snapshots, and let heavy output go to files.
• Chrome only. No Firefox, no WebKit. Playwright MCP wins if cross-browser is the job.
• WebDriver detection. Some sites refuse login when the browser is launched by the server; the docs recommend --autoConnect to a manually started Chrome to get around it.
• Telemetry on by default. Google collects tool-invocation success rates, latency, and environment info. Opt out with --no-usage-statistics; performance tools also hit the CrUX API unless you pass --no-performance-crux. Setting CI=1 disables collection.
• The advanced categories are gated and pipe-only. Extensions and PWA tools don't work over --browserUrl/--wsEndpoint until Chrome 149.
• The CLI is experimental. Version mismatches between CLI and daemon produce warnings, and some args aren't forwarded.

Community reactions

The HN thread is the best read. The top comment recommended an independent chrome-cdp-skill, which prompted Paul Irish (ex-DevTools) to clarify that DevTools MCP "is maintained by the team behind Chrome DevTools & Puppeteer and it certainly has a more comprehensive feature set. I'd expect it to be more reliable."

A user running it with Codex on OpenCode: "It's more reliable and token efficient than other devtools protocol MCPs I've tried. Favourite unexpected use case for me was telling Gemini to use it as a SVG editing REPL."

Another, more sceptical: "I've been using the DevTools MCP for months now, but it's extremely token heavy. Is there an alternative that provides the same amount of detail when it comes to reading back network requests?" — and nobody in the thread had one.

The "MCP is dead, use CLIs" debate ran for dozens of replies. The most reasonable summary: bespoke CLIs still need guidance for models, so token efficiency is an issue either way. Chrome DevTools MCP shipping both is the correct hedge.

Chrome DevTools MCP vs Playwright MCP vs Browser Use

	Chrome DevTools MCP	Playwright MCP	Browser Use
Maintainer	Google Chrome team	Microsoft	Browser Use (YC)
Browsers	Chrome only	Chromium, Firefox, WebKit	Chromium
Performance tracing	✅ Full DevTools insights	❌	❌
Heap snapshots	✅ 13 tools	❌	❌
Network inspection	✅ headers, cookies, bodies	Basic	Basic
Lighthouse	✅ built in (a11y, SEO, best practices)	❌	❌
Attach to running browser	✅ --autoConnect (Chrome 144+)	Via CDP endpoint	Cloud/local
CLI	✅ experimental	✅ playwright-cli	✅
Best for	Debugging, perf, memory	Cross-browser test flows	Autonomous web tasks

The one-sentence version, borrowed from a September 2026 dev.to roundup: Chrome DevTools "goes deeper on live debugging, network behavior, memory, and performance," while Playwright "is a cleaner fit when the job is navigating a flow and proving it works repeatedly." For an agent that browses the open web to complete tasks, Browser Use remains the better-fitting tool. For an agent that is your developer debugging your app, Chrome DevTools MCP is the one to install.

FAQ

Does Chrome DevTools MCP work with Claude Code?
Yes. Add the npx -y chrome-devtools-mcp@latest server to .mcp.json (or run claude mcp add chrome-devtools npx -- -y chrome-devtools-mcp@latest). Claude Code, Cursor, Codex, Copilot, Gemini CLI, Antigravity, VS Code and JetBrains are all covered in the client-configurations guide.

Is it free?
Yes. Apache-2.0 licensed, no account, no API key. You pay only for your own model's tokens — which is the real cost, so use --slim when you don't need the full surface.

Can it use my existing Chrome with my logins?
Yes, with --autoConnect on Chrome 144 or newer after enabling remote debugging at chrome://inspect/#remote-debugging. Be aware this gives the agent everything that profile can see. For untrusted work, use --isolated.

Does it replace Playwright MCP?
Only if you're Chrome-only and your priority is debugging rather than test authoring. Many teams run both: Playwright for regression flows, Chrome DevTools MCP for perf and memory investigation.

How do I reduce token usage?
Start with --slim (three tools), pass --no-page-id-routing if you're single-agent and want shorter calls, use filePath arguments to write traces, screenshots and network bodies to disk, and prefer evaluate_script returning targeted JSON over take_snapshot.

Does Google collect data?
Usage statistics (tool success rates, latency, environment) are collected by default. Disable with --no-usage-statistics or the CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS env var; CrUX lookups disable with --no-performance-crux.

Verdict

Chrome DevTools MCP is the first browser tool for agents I'd call diagnostic rather than merely operational. Playwright MCP and Browser Use let a model drive a page; this lets it understand why the page behaves the way it does, with the same trace engine, heap parser and Lighthouse build that ship in Chrome.

The costs are honest: Chrome-only, token-hungry in full mode, and attaching to your real profile is a security decision. Google has answered all three in the last two releases with --slim, the CLI, --no-javascript-evaluation and filesystem roots.

If your agent writes frontend code, install it in slim mode today and switch on the full surface when something is slow, leaky, or 404ing. 52,000 stars and 1.5 million weekly installs say most people already have.

Sources

• ChromeDevTools/chrome-devtools-mcp on GitHub — README, tool reference, configuration and advanced-usage docs
• CHANGELOG — v1.9.0 (2026-09-08), v1.8.0 (2026-08-25)
• chrome-devtools-mcp on npm — weekly download counts
• Hacker News discussion, March 2026 (604 points, 234 comments)
• r/mcp: browser MCP snapshot token measurements