Michael Hablich has spent 20 years building developer tools at Google. Now he’s giving coding agents the same debugging superpowers that Chrome DevTools gave web developers over a decade ago. Meet Chrome DevTools’s MCP Server!

This article is adapted from MCP MVP an interview with Michael Hablich, Product Manager for Chrome DevTools and Puppeteer at Google.

Debugging in web development hits different with the advent of coding agents. Rather than expertly sifting through a litany of console errors and warnings to track down where things went wrong, now it’s often faster and simpler to copy the whole log and paste it into Claude Code or Gemini CLI with a brief “fix this.” But then you do it again. And again. Rather than spending your time finessing a design or building a new feature, you’ve become a human clipboard for your coding agent, shuttling context between two systems that should be talking to each other.

Michael Hablich, Product Manager for Chrome DevTools and Puppeteer at Google, calls this “coding with blindfolds on.” Your agent can write code, but it has no idea what happens when that code actually runs in a browser. It can’t see console errors, failed network requests, layout shifts, or performance bottlenecks. Chrome DevTools MCP takes the blindfold off.

“Now it has an interesting feedback loop,” Michael told RL Nabors in a recent interview for Arcade’s MCP MVP video series. “Tell it, fix this bug, then validate it. And if it’s still not working, keep on fixing it until it actually works.”

How Chrome’s DevTools MCP Server provides debugging and automation under the hood

Chrome DevTools MCP provides your agent with two categories of capabilities, actuation and introspection:

  • Actuation/browser automation Navigating to pages, clicking elements, filling forms, taking screenshots are all provided by Puppeteer, Google’s Node.js library for controlling Chrome. It handles details such as waiting for the network to be idle and the DOM to be ready.
  • Introspection/debugging With these tools, your agent can read console messages (with source-mapped stack traces), inspect network requests, record performance traces, take accessibility snapshots, and, as of recently, capture heap snapshots for memory debugging.

Both layers communicate with Chrome via the Chrome DevTools Protocol (CDP), the same low-level protocol that powers DevTools, Playwright, and every other browser automation framework. If you’ve ever opened a remote debugging port for Playwright, the setup will feel familiar. The difference is that test frameworks typically only use CDP for automation. Chrome DevTools MCP also uses extracted DevTools front-end code libraries for the debugging capabilities like network analysis, performance profiling, and the rest.

The server exposes roughly 25 to 30 tools to any MCP-compatible coding agent like Gemini CLI, Claude Code, Cursor, Copilot, or Codex. Michael’s reasoning behind the decision to create more granular tools is that, “even basic automation requires a tool to list pages, one to select a page, one to navigate, one to take a snapshot, and one to click an element. That’s five tools for the simplest possible workflow. You can theoretically minimize that, but then coding agents start to use them wrong. It’s always a trade-off.”

Iterating on developer feedback made the server better

The origin story starts in summer 2024. Michael’s team at Google saw a future where agents write most of the code, which means agents would also need to debug most of the code. They had Puppeteer for automation, but no high-level APIs for debugging: reading console messages, setting breakpoints, and analyzing network requests.

In parallel, the team was building Gemini in DevTools, the AI assistance panel that lets you chat with Gemini about front-end issues directly inside Chrome’s DevTools UI. (Worth clarifying: this uses Gemini 2.5 Flash on Google’s servers, not the on-device model that powers Chrome’s Prompt API. Different model, different architecture.) Building that internal agent taught them which high-level APIs an agent would actually need for debugging.

When Anthropic launched the Model Context Protocol (MCP) in late 2024, the integration problem clicked into place. Instead of building custom integrations for every coding agent, they could support one protocol, MCP, and work everywhere.

Their first attempt, an early access preview in early 2025, modeled the server as a multi-agent system. The Chrome DevTools MCP server ran its own debugging agent internally, adding another layer of inference on top of whatever coding agent was calling it. However, partner feedback and input from Google Developer Experts was that multiple levels of non-determinism made things worse, not better. The added complexity wasn’t worth the handful of usecases the system handled well.

So over the summer of 2025, they regrouped and rebuilt. The new server shipped in September with ~25 low-level tools and no skills. “The smarts should be coming from the coding agent,” Michael said. Let the model reason. Give it good tools and get out of the way.

For anyone building their own MCP server, this is maybe the single most transferable lesson from the Chrome DevTools team: resist the urge to be clever on the server side. Provide low-level building blocks with clear interfaces. Let the agent handle the reasoning.

In production: CyberAgent’s autonomous QA loop

When the rebuilt server launched, CyberAgent, one of Japan’s largest tech companies, picked it up immediately. They pointed a coding agent equipped with Chrome DevTools MCP at their Spindle design system in Storybook, allowing it to audit and fix runtime bugs autonomously.

The workflow is exactly the feedback loop Michael described: the agent opens a component, inspects the browser state, identifies errors, fixes the code, redeploys, and validates that the fix actually works without introducing regressions. Then it moves on to the next component and continues.

This was work that CyberAgent’s developers “very often didn’t have time to do. And motivation, because it’s also sometimes very tedious.” The full case study is published on the Chrome developers blog.

The human-agent handoff that actually works

During the interview, Michael demoed a workflow that felt genuinely natural. He had a buggy movie browser app running in Chrome Canary, with some movie posters intentionally failing to load. He selected a broken image in DevTools’ Elements panel, switched to Gemini CLI, and typed: “I’ve selected an image in Chrome DevTools. Figure out why the image is not loading.”

The agent connected to his live browser session (Chrome shows a permission dialog, so the human stays in control), read the selected element, listed network requests, took an accessibility snapshot, identified that half the image paths were being mangled by a buggy function, fixed the code, and validated the fix. The images loaded.

Developers are already at home in DevTools, selecting elements, inspecting the DOM. And now they can call in an agent to work alongside them, inspect the same logs and DOM elements they’re already looking at with no need for copy-paste, screenshots, or long-winded descriptions. It’s a seamless developer experience..

This is possible since Chrome 144 added the --autoConnect feature, which lets the MCP server connect to your running browser session instead of spawning a new one. You can use DevTools yourself, then hand it over to your coding agent, then take over again. No more choosing between manual and automated debugging.

Skills: rewriting documentation for agents

Michael is bullish on skills, and Chrome DevTools MCP now ships with them. This is the same insight Paul Asjes from ElevenLabs described in a previous interview: agents are trained on documentation written for humans using human UIs. But Chrome DevTools for agents is a different UI with different interaction patterns. The documentation needs to change, too.

“When you think about performance debugging in documentation, you would say, go to the performance panel and do a performance trace, then look at that particular flame graph,” Michael explained. “For DevTools for agents, it would be: go to this page, start a trace, pick that particular insight, maybe run evaluate_script to understand better what’s happening. It’s a different way of interacting with the tools.”

If you install Chrome DevTools MCP as a Claude Code plugin or Gemini CLI extension, the skills are registered automatically alongside the tools. The team is actively adding more for performance debugging, accessibility auditing, and extension debugging. Michael is watching the proposal to bring skills into the MCP specification closely.

“Right now, those two technologies are distinct,” he said. “The perception is that they are competitors, but I think they’re complementary.” Rachel-Lee compared tools and skills to wings and the knowledge of how to fly. Skills teach the agent how to flutter, soar, and dive.

CLI mode, memory debugging, and extension debugging in Chrome DevTools MCP

Michael shared a few highlights from Chrome DevTools MCP:

CLI wrapper for code execution. The team is building a command-line interface that exposes Chrome DevTools MCP’s tools as CLI commands. Why does this matter? Because coding agents are very good at writing bash scripts and Python code. Instead of passing a massive accessibility snapshot through the context window, an agent could pipe the output through grep and only add the 10% it cares about. Michael referenced Anthropic’s engineering post on code execution with MCP, which makes the same case: let agents write code that calls tools instead of routing everything through inference.

Memory debugging. Heap snapshots are landing now, enabling agents to help investigate memory leaks, a notoriously difficult debugging task that most developers don’t do frequently enough to build deep expertise. “I think with AI agents, we have an opportunity to make that a lot more accessible.”

Chrome extension debugging. Currently clunky with the MCP server, but the team is making it a first-class citizen. If you’re building Chrome extensions with a coding agent today, validating that they work is the hard part. That’s about to get easier.

More skills. Memory debugging, accessibility auditing, and more, with the goal of guiding agents through workflows that are hard to discover from tool descriptions alone.

Get started with Chrome DevTools MCP

Install Chrome DevTools MCP for Claude Code, VS Code, Gemini CLI, Cursor, Codex, Cline, JetBrains, and more with a 1-2 lines of code at github.com/ChromeDevTools/chrome-devtools-mcp

To keep up with new features, follow the Chrome DevTools release notes page (it has an RSS feed) and the GitHub repo for releases. If you want to contribute, the project is open source and actively welcomes feature requests, bug reports, and pull requests.

Find Michael on Bluesky, LinkedIn, and X. His personal site is hablich.dev.

MCP MVP is a video series from Arcade with RL Nabors that spotlights the builders shaping the agentic ecosystem. Watch the full interview with Michael Hablich →

Want to give your agents authenticated access to APIs without managing tokens yourself? See how Arcade handles OAuth for MCP tools.