Chrome DevTools MCP gives AI coding agents a real Chrome with network and performance tools

The Chrome DevTools team maintains an open-source MCP server that lets AI coding agents such as Claude Code, Cursor, Codex and Gemini CLI drive a real Chrome instance and use DevTools tooling while they work. A hands-on walkthrough published on dev.to covers what the server does, how to wire it up, and where its limits sit.

What the agent gets

According to the dev.to post, the server exposes around 60 tools — some behind opt-in flags — covering network requests, console output, screenshots, performance traces, Lighthouse audits and heap snapshots. The project entered public preview in September 2025. The pitch is a closed feedback loop: instead of writing frontend fixes it cannot check, an agent can open the page, read the console error, inspect the failing request and report what actually broke.

Setup requires Node.js LTS and a current stable Chrome. In Claude Code, one command registers the server:

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

A plugin variant additionally installs skills for accessibility, cookies, LCP and memory leaks. Cursor, Codex and Gemini CLI each have their own registration syntax, which the post documents alongside equivalent JSON configuration.

Network inspection

Two tools handle the network. list_network_requests returns requests since the last navigation, filterable by resource type and paginated, with an option to reach back up to three navigations. get_network_request returns a single request with full headers — including Cookie and Set-Cookie — and bodies; large bodies can be written to disk instead of filling the model's context window. One trick the author highlights: calling get_network_request with no request id returns whatever is currently selected in the DevTools Network panel, so you can click a failing call and ask why it returned a 403. A --redactNetworkHeaders flag keeps token-bearing headers away from the model.

Attach mode and its risks

By default the server launches Chrome with its own profile, and --isolated switches to a throwaway one. On Chrome 144 or newer, --autoConnect attaches to the browser you are already signed in to, after you allow incoming connections via chrome://inspect/#remote-debugging and approve a permission dialog; a banner signalling automated control stays visible while attached. Where that is unavailable — sandboxes, older Chrome — you can start Chrome yourself with a remote debugging port and point the server at it.

The trade-off is blunt: attach mode hands the agent your cookies and signed-in sessions, and the author notes that Google's own documentation advises using it only with agents you trust. Usage statistics are on by default, and performance tooling can send trace URLs to CrUX; flags exist to disable both.

How it compares with Playwright MCP

The overlap with Playwright MCP is significant, and the post lays out a side-by-side. Playwright MCP drives Chrome, Firefox, WebKit and Edge, models pages through the accessibility tree rather than screenshots and text snapshots, and adds network mocking. DevTools MCP is Chrome-only but counters with Lighthouse, performance insights, heap snapshots and its attach options. The author's rule of thumb: Playwright for cross-browser work and scripted user flows, DevTools MCP for questions like why a given page is slow or erroring in Chrome. Playwright's README also observes that coding agents may work better with its CLI and skills, since those cost fewer tokens than MCP calls.

Where it falls short

Both servers only see what the browser loads while the agent is connected, which makes whole-API discovery painful. The request list resets on navigation — three navigations back at most — so mapping an app's endpoints means clicking through every screen, spending tool calls and context each time. URLs such as /orders/1042 and /orders/1043 arrive as separate entries, leaving the agent to infer that they hit a single endpoint. Capturing real logged-in traffic requires attach mode, and closing the browser discards the data.

Why it matters

MCP is rapidly turning established developer tools into surfaces that agents can operate directly, and this one comes from the team that builds the browser's own diagnostics. Performance traces, heap snapshots and network internals were previously expert-only territory; exposing them to any MCP-capable agent closes a genuine gap, because agents can now verify the frontend fixes they ship rather than guess at them. The caveats deserve equal weight: attach mode delegates your authenticated sessions to whatever agent is connected, and telemetry is opt-out rather than opt-in. Teams adopting it should decide up front which sessions an agent is allowed to see.