chrome-devtools-mcp

Coding agents have become good at writing browser code, but they remain largely blind to how that code actually behaves in a real browser. They cannot see a layout shift, read a console error, watch a network request stall, or notice that a page is slow because of an unoptimized image. chrome-devtools-mcp, an official project from the Chrome DevTools team, closes that gap. It is a Model Context Protocol server that hands a coding agent control of a real, running Chrome instance along with the same inspection powers a developer gets from DevTools. Instead of guessing why a page misbehaves, an agent can navigate to it, reproduce the issue, capture a performance trace, and read the actual evidence before proposing a fix.

Under the hood the server drives Chrome through Puppeteer and the Chrome DevTools Protocol, then exposes that functionality as MCP tools any compatible client can call. The tool surface is unusually broad: input automation such as click, fill_form, and type_text, navigation across multiple pages, plus the inspection tools that set it apart. Agents can run performance_start_trace and performance_analyze_insight, list and read individual network requests, pull source-mapped console messages, take screenshots and snapshots, evaluate scripts, and capture heap snapshots for memory analysis. It can launch a fresh isolated profile, run headless, or connect to an already-running Chrome over a debugging port. A slim mode trims the surface to a few basic tools when the full set is more than a task needs.

The natural audience is developers who already work with an agent in tools like Claude Code, Cursor, Copilot, Codex, or Cline and want that agent to debug in the browser rather than only in the editor. Concrete uses include reproducing a bug an agent introduced, then reading the console and network log to find the cause; profiling a slow page and acting on the trace insights; running end-to-end style flows where the agent waits reliably for actions to settle; verifying a visual change through screenshots; and hunting memory leaks via heap snapshots. Because the project is from the Chrome team and reports very high adoption, around 43k stars and roughly 2.76M weekly npm downloads, it is also a low-risk default for teams standardizing on one browser MCP server.

The honest caveats are real and mostly about exposure. By design the server hands the MCP client access to everything in the browser instance, so any page you have open, including logged-in sessions and sensitive data, becomes visible to the agent and whatever it is connected to. That is fine in a throwaway profile but dangerous against your everyday browser, and the isolated flag exists for good reason. Telemetry is on by default: usage statistics go to Google, and the performance tools can send trace URLs to the CrUX API, both of which you should disable deliberately with the documented flags if that matters. Support is officially limited to Google Chrome and Chrome for Testing; other Chromium browsers may work but carry no guarantee, and the claim of reliable automation is the project's own, not an independent benchmark.

Compared with general-purpose browser automation MCP servers and with Puppeteer or Playwright used directly, chrome-devtools-mcp trades broad cross-browser reach for depth on Chrome and first-party DevTools insight that competitors do not match. The Apache-2.0 license carries no usage strings, and the breadth of client support lowers the cost of trying it. Adopt it when you want an agent to do genuine browser debugging and performance work, not just click through a page, and when you can run it against an isolated or disposable profile. Hold off, or harden it carefully first, in sensitive environments where exposing browser content to an external client is unacceptable, or where you need guaranteed support for a non-Chrome engine. For most Chrome-centric agent workflows, it is a sensible default.