Chrome DevTools MCP Setup Guide: Agent Debugging (2026)

Something breaks in the browser. You open DevTools, copy the red console error, paste it into your AI assistant, go back for the failed network request, paste that too, then try to describe the layout shift in words. Your agent writes the code, but it’s debugging blind — working from whatever you remembered to copy. Chrome DevTools MCP takes you out of that loop. It’s the official Model Context Protocol server from the Chrome DevTools team, and it hands your coding agent a real Chrome browser to drive: the console, the network tab, performance traces, heap snapshots and all. Setup is one command. Here’s what it is, what the October 2026 additions change, and how to wire it up in minutes.

Facts verified October 21, 2026 against the official Chrome DevTools blog, the chrome-devtools-mcp GitHub repository README, release notes and configuration docs.

Table of Contents

What Chrome DevTools MCP actually is

Chrome DevTools MCP is an MCP server built and maintained by Google’s Chrome DevTools team. Once registered with your MCP client, your coding agent can open pages, click and fill forms, read console messages, inspect network requests, take screenshots, record performance traces, run Lighthouse audits, and query heap snapshots — in a real Chrome window you can watch, rather than through second-hand descriptions you paste into chat.

The project has picked up real traction: the repository sits at 53,928 stars on GitHub (checked October 21, 2026), it went stable 1.0 on May 18, 2026 (announced at Google I/O 2026), and it’s Apache-2.0 open source — no pricing, no tiers, no paid plan anywhere in the official docs.

Google’s get-started docs name Antigravity, Gemini CLI, Claude Code, Cursor, Copilot, Codex and Gemini Code Assist as supported clients, with “and more” — the official client-configurations doc lists around two dozen configured clients. The only things you need are Node.js LTS, npm, and current stable Chrome (or Chrome for Testing).

What your agent can do with it

The point of Chrome DevTools MCP is grounding: the agent stops guessing from your screenshots and starts reading the browser itself. A typical debugging session looks like this:

navigate_page → list_console_messages → list_network_requests →
take_screenshot → performance_start_trace → performance_stop_trace →
performance_analyze_insight

Concretely, that covers: visual/UI fixes (the agent sees the actual render), flaky interactions, runtime and network debugging, and performance work — the agent records a trace itself and reads the insights instead of you describing a waterfall chart from memory.

What the October 2026 additions change

Google’s New in DevTools – October 2026 roundup (published September 22, 2026) documents a “DevTools for agents” section — new security controls, performance tuning, and memory analysis capabilities for coding agents. Here’s each item, with the nuance the release notes add:

1. JavaScript execution controls

You can now configure --no-javascript-evaluation (or turn off the JavaScript execution tools entirely) so the agent inspects pages without evaluating scripts — useful when you want the agent to read a page’s structure without side effects. The repo release notes confirm this extends across navigations and initialization scripts.

2. On-demand source maps

There’s now an option to disable source maps and lazy-load them on demand (--source-maps, default true), preventing the high memory usage that comes with loading maps for large sites. If your agent has been crawling on a big app, this is the flag to reach for first.

3. Configurable file system roots

The CLI now supports configurable file system roots. One nuance worth knowing: the blog says the CLI “includes --allow-unrestricted-paths by default” — that’s CLI-only. The MCP server default is still restricted (to the OS temp dir when no roots are configured), which is the safer posture for an agent that writes files.

4. Heap snapshot inspection

Agents can now query heap snapshot objects directly by retained size or property name. Note the naming gotcha: the October blog calls it query_heapsnapshot, but the current tool reference names it query_heapsnapshot_objects — the tool was renamed after the blog shipped, so use the new name. Two more catches: the memory tools require --memoryDebugging=true to be active at all, and they’re off by default.

5. Agent Plugins 1.0

The server supports the Agent Plugins 1.0 package, letting agents load and execute modular plugin extensions — a small step toward reusable agent tooling rather than one-off prompts.

6. PWA automation tools

Dedicated tools for automating Progressive Web App installation and lifecycle checks (install_pwa, launch_pwa, uninstall_pwa, get_os_app_state). They’re opt-in via --categoryPwa=true (default false).

7. Console stack traces

list_console_messages can now return optional stack traces — the difference between “something logged an error” and “here’s exactly where.”

And the newer releases (1.10.0 / 1.11.0)

Five more additions landed after the October blog was written, in releases 1.10.0 (September 23) and 1.11.0 (October 15, 2026): a paginated get_css_styles tool, a dedicated configuration file with discovery in predefined locations, chunked performance trace parsing with a 1.2 GB default buffer, automatic JavaScript dialog handling during input actions, and persistent console history across same-document navigations. If a guide you read doesn’t mention these, it’s out of date.

Setting it up: Claude Code (one command)

This is the exact syntax from the official repo docs:

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

The --scope user flag makes the server available in all your projects. Then verify the connection with /mcp inside a session (or claude mcp list from the terminal) and test it with a prompt like:

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

Chrome should open, record a trace, and report back. Total time from zero: about two minutes.

Setting it up: Cursor, VS Code, Windsurf, JetBrains

For clients that take a JSON config, the official shape (from the repo README and Google’s get-started docs) is:

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

Paste that into your client’s MCP config, restart the client, and confirm the server shows as connected. The -y flag keeps npx from pausing for an install confirmation — the official config includes it, so don’t leave it out.

Flags worth setting on day one

The defaults are sensible, but four flags are worth knowing before your first real session:

--isolated (default false) — launches Chrome with a temporary user-data directory that’s cleaned up automatically. Use this when the agent only needs your dev environment: no cookies, no sessions, no saved logins leaking into the agent’s browser.
--headless (default false) — runs without a visible window. Faster for CI-style checks; keep the visible window while you’re learning what the agent actually does.
--no-javascript-evaluation — let the agent inspect pages without executing their scripts. Good for reading structure and styles without side effects.
--memoryDebugging=true — required before any of the heap snapshot tools (including query_heapsnapshot_objects) will do anything.

And one privacy note: Google collects usage statistics by default. Opt out with --no-usage-statistics, and opt out of the CrUX API queries the performance tools can make with --no-performance-crux.

DevTools MCP vs Playwright MCP

If you already have Playwright’s MCP server configured, this isn’t a replacement — the community framing you’ll see everywhere is Steve Kinney’s line: “Playwright is in the business of driving a browser, and Chrome DevTools MCP is in the business of debugging one.” (To be precise, that’s the established community/press framing, not an official Google or Microsoft position — and there’s real overlap, since DevTools MCP also does input automation via Puppeteer. “Complementary” is the accurate word, not “non-overlapping.”)

Rule of thumb: Playwright MCP drives flows — multi-step user journeys, form submissions, test scripts. DevTools MCP answers why something broke — console errors, network failures, slow renders, memory growth. Run both; they solve different halves of the problem.

What it won’t do (yet)

Honest limits, so you don’t waste an afternoon:

WebMCP is experimental. The ability for websites to expose their own tools to agents (list_webmcp_tools, execute_webmcp_tool) exists in the tool reference but is flag-gated (--categoryExperimentalWebmcp=true plus Chrome launched with --enable-features=WebMCP) and was deliberately not part of the October 2026 blog’s agent list. Treat it as a preview.
The agent sees what Chrome sees, nothing more. Cross-browser differences (Firefox, Safari quirks) are still your job — the server officially supports Google Chrome and Chrome for Testing only.
Dialogs and permissions are the agent’s weak spot. Automatic dialog handling during input actions is new in 1.10.0; anything exotic will still stall and need you.
Keep it out of sensitive profiles. Use --isolated or a dedicated Chrome profile, never your everyday profile — the debugging port is local, but an agent driving your logged-in tabs is a footgun you don’t need.

Try this today

If you’ve got Claude Code installed, run the one-liner, then hand the agent something real: a page with a console error you’ve been ignoring, a slow interaction you keep meaning to profile, or a layout shift you can’t reproduce on demand. The moment you stop being the copy-paste middleman between DevTools and your agent, the tool has paid for itself.

Chrome DevTools MCP: Give Your Coding Agent a Real Browser (2026 Guide)