Chrome DevTools MCP: the official bridge that hands your coding agent a live DevTools session

The Model Context Protocol has spent the last couple of years giving coding agents more hands: files, databases, terminal access. One obvious piece was missing, though, and it's the thing every web developer already has open anyway. Chrome DevTools. The Chrome team has now made that official with Chrome DevTools for agents (chrome-devtools-mcp), and it just shipped v1.9.0 on September 8, 2026, with around 51,000 stars on GitHub.¹²

The pitch is short: it's an MCP server your agent runs that controls and inspects a real Chrome browser, the same one you'd debug by hand. So an assistant like Claude, Cursor, Copilot, or Antigravity can load a page, click around, read console output with source-mapped stack traces, watch network requests, record performance traces, and run Lighthouse audits before you ship anything.¹

What stands out here is the reach. This isn't a "open a browser and screenshot it" tool. Let's look at what it actually exposes.

A browser agent that can do real work

Installation is the usual one-block MCP config. Point an npx command at the latest package and your client picks it up.³

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

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

Drop that in your MCP client and the server starts Chrome the first time the agent reaches for a browser tool. If you only need basic navigation and don't want the full surface, a --slim mode trims it down.³

The tool set is where the comparison to "it's just Puppeteer with extra steps" breaks down. Beyond the input and navigation primitives you'd expect, like click, fill_form, press_key, navigate_page, and new_page, there are groups for emulation, performance, network, debugging, memory, extensions, and even PWAs.⁴

Emulation (emulate, resize_page): set viewport, user agent, geolocation, network conditions, CPU throttling, color scheme, and extra HTTP headers on a page.
Performance (performance_start_trace, performance_stop_trace, performance_analyze_insight): record a real trace and get the same Core Web Vitals insight breakdown (LCP, INP, CLS) DevTools shows, as tool output.
Network (list_network_requests, get_network_request): see what loaded, inspect headers including cookies, and dump request and response bodies to files.
Debugging (take_snapshot, list_console_messages, lighthouse_audit): a full accessibility-tree snapshot of the page with stable element IDs, console messages with stack traces, and Lighthouse reports for accessibility, SEO, and best practices.
Memory (13 heapsnapshot tools): capture heap snapshots, compare two of them, traverse retaining paths and objects. That's full DevTools memory tooling exposed as a tool.

The memory group is the tell. Those heapsnapshot tools (take_heapsnapshot, compare_heapsnapshots, get_heapsnapshot_retaining_paths, query_heapsnapshot_objects, and friends) are real DevTools machinery moved behind MCP calls, so the agent can chase down a memory leak instead of just describing how one might find it.⁴

Everything hangs together through a snapshot model: the agent takes a text snapshot of the page's accessibility tree, each element gets a uid, and input tools target those uids rather than blind CSS selectors. It's the "hand the agent a stable handle and let it act" idea built from DevTools' own a11y tree, which is usually more reliable for agents than guessing at selectors.⁴

What shipped in 1.9.0

The release is steady polish plus some new capability, not a rewrite.² The notable bits:

An Agent Plugins 1.0 package, formalizing the plugin distribution story for Claude, Cursor, and Gemini instead of manual MCP config.
A new cookie-debugging skill, plus better descriptions on the network and page tools.
An option to disable source maps, and one to turn off JavaScript execution tools entirely, if you want the agent to inspect but not run arbitrary script.
A configurable filesystem roots option, with --allow-unrestricted-paths enabled for the CLI by default.
A default trace buffer size that now matches DevTools at 1.2 GB, so performance traces don't ring-fence themselves.

A lot of the movement here is about control. Chrome DevTools for agents opens the browser up to your MCP client, which is powerful and a little scary, so the team keeps adding ways to pull back: switch off JS evaluation, restrict filesystem roots, gate tool groups behind feature flags.⁴

The honest caveats

The README is upfront about the cost of that power: Chrome DevTools for agents exposes content of the browser instance to the MCP clients, letting them inspect, debug, and modify any data in the browser. In other words, don't plug an agent into a browser full of personal data you're not willing to show the assistant.¹

Two practical notes worth knowing before you wire it up:

It officially supports Google Chrome and Chrome for Testing, not every Chromium browser. Others may work but aren't guaranteed.¹
Google collects usage statistics by default (tool success rates, latency). You can opt out with --no-usage-statistics on the server, and collection is also disabled automatically when CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS or CI is set.¹

Why this matters right now

The "give agents a browser" wave has focused mostly on automation and scraping. Chrome DevTools for agents does something different: it hands the agent the debugging surface, not just the browsing surface. Traces with insight breakdowns, heap snapshots, source-mapped console errors, Lighthouse audits. That closes a real loop on agent-written front-end code in a way that walking a headless browser through a page can't. The README even recommends that anyone building agentic browser tooling stand on top of it.¹⁵

For most people the pitch is more concrete than that. When you want your coding agent to stop guessing about a page and actually put DevTools on it, this is the most direct route. It's free, it's Apache-2.0, it's official, and the tool list got longer this week.²

Chrome DevTools MCP README: https://github.com/ChromeDevTools/chrome-devtools-mcp
Chrome DevTools MCP changelog (v1.9.0, 2026-09-08): https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/CHANGELOG.md
Chrome DevTools MCP README, "Getting started": https://github.com/ChromeDevTools/chrome-devtools-mcp
Chrome DevTools MCP tool reference: https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/tool-reference.md
Chrome DevTools for agents (Chrome for Developers): https://developer.chrome.com/docs/devtools/agents