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, Lig...
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:
Open chrome://inspect/#remote-debugging in Chrome 144+ and allow incoming connections.
Add the flag:
"args": ["-y", "chrome-devtools-mcp@latest", "--autoConnect"]
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:
The request list resets per navigation (3 back at most), so the agent has to click through every screen.
Each screen costs tool calls and context.
/orders/1042 and /orders/1043 come back as separate URLs, so the agent has to figure out they're one endpoint.
Real logged-in traffic means attach mode and handing over my session.
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.