Chrome DevTools MCP server: setup in Claude Code, attach mode and Playwright MCP compared

The Chrome team announced the Chrome DevTools MCP server as a public preview on 23 September 2025 (Chrome for Developers blog). It gives an AI agent the debugging tools a developer gets in Chrome DevTools, so the agent can check its own code changes in a real browser instead of guessing what the page does. The code lives at ChromeDevTools/chrome-devtools-mcp and ships on npm as chrome-devtools-mcp.

It speaks the Model Context Protocol, so any MCP client can use it. If MCP itself is new to you, our MCP server guide explains tools, clients and transports. The tool reference lists 60 tools at the time of writing, some behind opt-in flags. The main groups are these.

• Input automation, such as click, fill_form, type_text, press_key and upload_file.
• Navigation, such as new_page, navigate_page, list_pages and wait_for.
• Network, with list_network_requests and get_network_request.
• Debugging, such as evaluate_script, list_console_messages, take_screenshot, take_snapshot and lighthouse_audit.
• Performance, with performance_start_trace, performance_stop_trace and performance_analyze_insight.
• Memory, a set of heap snapshot tools for tracking down leaks.
• Emulation, with emulate and resize_page.

If you only need basic browsing, --slim cuts the server down to three tools for navigation, script execution and screenshots, which keeps the tool list in the agent's context small.

Two, and they map closely to the Network panel.

• list_network_requests lists the requests for a page since the last navigation. You can filter by resource type and page through long lists with pageSize and pageIdx. Set includePreservedRequests to get requests from the last 3 navigations.
• get_network_request returns one request with its headers, including Cookie and Set-Cookie, and its bodies. Pass requestFilePath or responseFilePath to write a large body to a file instead of the agent's context.

Call get_network_request without a request ID and it returns the request currently selected in the DevTools Network panel. That makes a useful handoff in attach mode. You select the failing call yourself, then ask the agent to explain it.

Headers can hold session tokens. Start the server with --redactNetworkHeaders if you want sensitive headers redacted before the agent sees them.

The project's client configuration guide covers each client. For Claude Code, add the server on its own for every project with --scope user.

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

Or install the plugin, which bundles the server with skills for accessibility, cookie, LCP and memory leak debugging. Restart Claude Code afterwards and check with /skills. Remove any older manual install first so you do not run the server twice.

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

In Cursor, open Cursor Settings, then MCP, then New MCP Server, or use the Install in Cursor button in the README. The standard config works in Cursor and in most other clients.

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

Codex and Gemini CLI have one-line equivalents: codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest and gemini mcp add chrome-devtools npx chrome-devtools-mcp@latest. Extra flags such as --autoConnect, --slim or --headless go at the end of the args list.

By default the server launches its own Chrome with a dedicated profile in $HOME/.cache/chrome-devtools-mcp/chrome-profile. Logins you make in that window persist between runs, but it is a separate profile from the one you browse with. --isolated goes the other way and uses a temporary profile that is deleted when the browser closes.

Attach mode connects the agent to a Chrome you already have open, which matters when the bug sits behind a login. There are two ways to do it (configuration docs).

• --autoConnect attaches to your running Chrome. It needs Chrome 144 or later, with remote debugging turned on at chrome://inspect/#remote-debugging. Remote debugging is off by default.
• --browser-url=http://127.0.0.1:9222 connects to a Chrome you started yourself with --remote-debugging-port=9222 and its own --user-data-dir. Use this where --autoConnect is not available, such as a sandbox. --wsEndpoint takes a WebSocket URL instead.

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

With --autoConnect, Chrome shows a permission dialog every time the server asks for a debugging session, and a "Chrome is being controlled by automated test software" banner while it is connected (announcement).

Playwright MCP is Microsoft's MCP server built on Playwright. You add it with claude mcp add playwright npx @playwright/mcp@latest. Both servers let an agent drive a browser, and they overlap a lot. The differences show up at the edges.

• Browsers. Playwright MCP runs Chrome, Firefox, WebKit or Edge. Chrome DevTools MCP supports Google Chrome and Chrome for Testing.
• How the agent sees the page. Playwright MCP works from the accessibility tree, so the model reads structured data and needs no vision. Chrome DevTools MCP offers take_snapshot for a text snapshot of the page, plus screenshots.
• Debugging depth. Chrome DevTools MCP adds performance traces with insights, Lighthouse audits, heap snapshots and the selected-request handoff from the Network panel. Playwright MCP can record Playwright traces with --caps=devtools, and its README lists no Lighthouse or heap snapshot tools.
• Network. Playwright MCP has browser_network_requests with a URL regex filter and browser_network_request for headers and body. With --caps=network it can also mock responses with browser_route. Chrome DevTools MCP has no request mocking tool.
• Existing browser. Playwright MCP attaches through its browser extension (--extension) or a CDP endpoint (--cdp-endpoint). Chrome DevTools MCP uses --autoConnect or --browser-url.

A rough rule: reach for Playwright MCP when the job is a user flow or a cross-browser test, and Chrome DevTools MCP when the job is "why is this page slow, broken or erroring in Chrome". Playwright's README also suggests that coding agents may do better with its CLI and skills than with the MCP server, because CLI calls use fewer tokens.

Both browser servers see the requests the browser makes while the agent is connected, for the pages the agent visits. That suits a single bug. It gets awkward when the question is about the API as a whole.

• The request list is per page and resets on navigation. includePreservedRequests reaches back 3 navigations, so a full map of the app means the agent walking every screen in the same session.
• Every page the agent clicks through costs tool calls and context. Listing all endpoints of a large dashboard this way is slow and expensive.
• Requests come back as a flat list of URLs. /orders/1042 and /orders/1043 are two rows, and the agent has to work out on its own that they are one endpoint.
• Logged-in traffic needs attach mode, which hands the agent control of your real session to click and type in.
• When the browser closes, the traffic is gone. Yesterday's session is not available to ask about.

None of this is a flaw in the tool. It is built to debug the page in front of it. For questions like "what does GET /api/orders/{id} return" or "which endpoints does the billing page call", the agent does better with traffic that was recorded earlier and grouped by endpoint.

Netraptor is a Chrome extension that records the fetch and XHR calls your app makes while you use it in your own signed-in browser. Turn on "Keep history for this site" in the popup and it saves those calls with DevTools closed, or run "Crawl this site" to visit same-site pages you would not click by hand. Its API Map groups calls into endpoints like /orders/{id}.

Netraptor Pro includes a local, read-only MCP server, @branch42-labs/netraptor-mcp, that answers from those saved sessions. The agent lists endpoints as path templates and asks for one endpoint's inferred schema with real example requests and responses. It cannot click, navigate or send anything. Setup, the five tools and the security model are in the MCP server guide.

Each tool has blind spots. Netraptor records from inside the page, so a recorded request only has the headers the site's code set. Browser-added headers such as Cookie are not there, while get_network_request in Chrome DevTools MCP shows them. Netraptor's server also covers what you recorded, so a screen you never opened is missing until you visit it or crawl it.

In practice the two fit together. Let the Netraptor server tell the agent which endpoints exist and what their payloads look like, then let Chrome DevTools MCP open the page and reproduce the bug when something looks wrong. To pull the endpoint list yourself, see how to find every API endpoint a web app calls.