Chrome DevTools MCP in Claude Code (setup, attach mode, vs Playwright MCP)

TL;DR: Chrome DevTools MCP is the Chrome DevTools team's open-source MCP server. It lets Claude Code, Cursor, Codex or Gemini CLI drive a real Chrome and use DevTools features: network requests, console, screenshots, performance traces, Lighthouse and heap snapshots. Install it with claude mcp add chrome-devtools --scope user -- npx chrome-devtools-mcp@latest. Add --autoConnect (Chrome 144+) to let it attach to the Chrome you're already signed in to. It's great for debugging the page in front of it. It's a poor fit for "map this app's whole API".

Why I wanted it

My agent kept writing frontend fixes it couldn't check. With a browser MCP server it opens the page, reads the console, looks at the failing request and tells me what broke. The Chrome team shipped this as a public preview in September 2025, and it now has around 60 tools (some behind opt-in flags).

Setup

You need Node.js LTS and current stable Chrome.

Claude Code

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

Or the plugin, which also installs skills for a11y, cookies, LCP and memory leaks:

/plugin marketplace add ChromeDevTools/chrome-devtools-mcp
/plugin install chrome-devtools-mcp@chrome-devtools-plugins

Cursor (Settings → MCP → New MCP Server) and most other clients:

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

Codex / Gemini CLI

codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest
gemini mcp add chrome-devtools npx chrome-devtools-mcp@latest

First prompt to try: Check the performance of https://developer.chrome.com. You'll see a Chrome window open and a trace get recorded.

The network tools

There are two:

• list_network_requests: requests for a page since the last navigation. Filter by resourceTypes, paginate with pageSize/pageIdx, and set includePreservedRequests to reach back 3 navigations.
• get_network_request: one request with headers (including Cookie and Set-Cookie) and bodies. responseFilePath writes a big body to disk instead of into the context window.

The trick I like most: call get_network_request with no reqid and it returns whatever request you have selected in the DevTools Network panel. I click the broken call, then type "why did this 403?".

If headers carry tokens you'd rather not send to a model, start the server with --redactNetworkHeaders.

Attach mode (your signed-in browser)

By default the server launches Chrome with its own profile in ~/.cache/chrome-devtools-mcp/chrome-profile. --isolated uses a throwaway profile instead. To debug something behind your real login:

1. Open chrome://inspect/#remote-debugging in Chrome 144+ and allow incoming connections.
2. Add the flag:

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

1. Approve the permission dialog Chrome shows each time the server connects. A "Chrome is being controlled by automated test software" banner stays up while it's attached.

No --autoConnect (sandboxes, older Chrome)? Start Chrome yourself and point the server at it:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-profile-stable

"args": ["chrome-devtools-mcp@latest", "--browser-url=http://127.0.0.1:9222"]

Heads up: attach mode gives the agent your cookies and signed-in accounts. Google's own docs say to only use it with agents you trust. Also, usage statistics are on by default (--no-usage-statistics), and performance tools can send trace URLs to CrUX (--no-performance-crux).

Chrome DevTools MCP vs Playwright MCP

Playwright MCP (claude mcp add playwright npx @playwright/mcp@latest) overlaps a lot. How I pick:

	Chrome DevTools MCP	Playwright MCP
Browsers	Chrome, Chrome for Testing	Chrome, Firefox, WebKit, Edge
Page model	screenshots + text snapshot	accessibility tree, no vision needed
Perf insights / Lighthouse / heap	yes	Playwright traces via --caps=devtools, no Lighthouse or heap tools listed
Network	list + get (headers, bodies)	list (URL regex) + get, mocking via --caps=network
Existing browser	--autoConnect, --browser-url	--extension, --cdp-endpoint

User flows and cross-browser checks: Playwright. "Why is this page slow or erroring in Chrome": DevTools MCP. Playwright's README also notes that coding agents may get on better with its CLI + skills, since those calls cost fewer tokens than MCP.

Where it stops for API work

Both servers only see what the browser loads while the agent is connected. When I want the agent to understand the whole API of an app, that hurts:

1. The request list resets per navigation (3 back at most), so the agent has to click through every screen.
2. Each screen costs tool calls and context.
3. /orders/1042 and /orders/1043 come back as separate URLs, so the agent has to figure out they're one endpoint.
4. Real logged-in traffic means attach mode and handing over my session.
5. Close the browser and the traffic is gone.

For that job I use Netraptor, a Chrome extension I work on. It records the app's fetch/XHR calls while I browse normally (or crawls same-site pages), groups them into endpoints like /orders/{id}, and its Pro plan has a local, read-only MCP server so the agent can ask "what does GET /orders/{id} return?" from real recorded responses. It has its own gap: it records from inside the page, so browser-added headers like Cookie aren't in its copy. DevTools MCP shows those. So I run both: Netraptor for "what does the API look like", DevTools MCP for "go reproduce this".

The full guide, with links to every doc above, is at netraptor.dev/guides/chrome-devtools-mcp.