Chrome DevTools MCP: Let Your AI Agent Debug Your Browser

Your coding agent can write code, run tests, and fix bugs in your codebase. But the moment that code hits the browser — network requests failing, layouts breaking, performance tanking — your AI assistant goes blind.

Chrome DevTools MCP fixes that. It gives your coding agent direct access to Chrome DevTools, turning your AI assistant into a full-stack debugging partner that can see what your code actually does when it runs in the browser.

And with Chrome M144's new --autoConnect feature, your agent can now attach to your *existing* browser session — no fresh profile, no re-login, no setup friction.

Here's how to set it up and what it actually does.

What Is Chrome DevTools MCP?

Chrome DevTools MCP is an official MCP server built by the Chrome DevTools team. It acts as a bridge between your AI coding agent (Claude Code, Cursor, Copilot, Gemini CLI) and a live Chrome browser instance.

Through MCP (Model Context Protocol), your coding agent gets access to the same tools you'd use manually in Chrome DevTools:

• Network panel — inspect requests, responses, headers, timing
• Console — read errors, warnings, and logs (with source-mapped stack traces)
• Performance — record traces and get actionable performance insights
• Elements — inspect DOM elements selected in the Elements panel
• Screenshots — capture the current page state
• Automation — click, type, navigate using Puppeteer under the hood

The key insight: your agent doesn't just see your source code anymore. It sees what the browser is actually *doing* with that code.

The --autoConnect Game Changer

Before Chrome M144, using DevTools MCP required one of:

• Launching Chrome with a special MCP-managed profile (losing your cookies and sessions)
• Manually starting Chrome with --remote-debugging-port (annoying)

The new --autoConnect flag eliminates both friction points. Your agent connects directly to the Chrome instance you're already using — with all your sessions, cookies, and logged-in state intact.

Why this matters:

• Your agent can debug issues behind authentication walls without you re-logging in
• You can be debugging manually in DevTools, spot a problem, and hand it off to your agent mid-session
• The transition between human and AI debugging becomes seamless

When your agent requests a connection, Chrome shows a permission dialog — you have to explicitly allow it. And while the session is active, Chrome displays an "automated test software" banner so you always know your agent is connected.

Setup Guide: 4 Steps to AI-Powered Browser Debugging

Prerequisites

• Node.js v20.19+ (any recent LTS)
• Chrome M144+ (currently in Beta; stable by mid-2026)
• An MCP-capable coding agent

Step 1: Enable Remote Debugging in Chrome

Navigate to chrome://inspect/#remote-debugging and follow the dialog to enable incoming debugging connections.

This is a one-time setup. Chrome won't accept agent connections until you explicitly enable this.

Step 2: Add the MCP Server to Your Agent

The configuration depends on your coding agent. Here are the most common setups:

Claude Code:

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

Cursor / VS Code Copilot:

Add the same config to your MCP settings file (.cursor/mcp.json or VS Code's MCP configuration).

Gemini CLI:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["chrome-devtools-mcp@latest", "--autoConnect", "--channel=beta"]
    }
  }
}

> Tip: Using chrome-devtools-mcp@latest ensures you always get the newest version. Pin a specific version in production if you need stability.

Step 3: Allow the Connection

When your agent first tries to connect, Chrome will show a permission dialog. Click Allow. You'll see a banner at the top of Chrome confirming the agent is connected.

Step 4: Test It

Ask your agent something that requires browser access:

> "Check the performance of https://your-site.com"

or

> "Open my app and check if there are any console errors"

Your agent should open the page, run the analysis, and report back with actionable findings.

What Can You Actually Do With This?

Here are real workflows that Chrome DevTools MCP enables:

Debug Failing API Calls

You notice a broken feature on your site. Instead of manually digging through the Network panel:

> "Open my app at localhost:3000/dashboard, check the network panel for failing requests, and show me the error responses"

Your agent opens the page, monitors network traffic, identifies the 4xx/5xx responses, and shows you the payloads — often suggesting a fix in the same response.

Performance Audits on Demand

> "Run a performance trace on our landing page and tell me what's slow"

The agent records a Chrome DevTools performance trace, analyzes it, and returns specific bottlenecks: long tasks, layout shifts, slow network waterfalls. It can even fetch real-user CrUX data for comparison.

Fix Layout Issues by Pointing

Select a broken element in Chrome's Elements panel, then ask:

> "I've selected an element in DevTools. It's overflowing its container on mobile. Fix it."

The agent reads the selected element's styles, identifies the CSS issue, and patches your code — all without you needing to describe the element in words.

Investigate Console Errors

> "Check my app for console errors and warnings, and fix anything related to our auth flow"

Your agent reads console output with full source-mapped stack traces, traces errors back to your code, and proposes fixes.

Slim Mode: When You Just Need the Basics

If you don't need the full DevTools suite — maybe you just want screenshots and basic automation — use --slim mode:

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

Slim mode reduces the tool surface, which means:

• Faster startup
• Less context for your agent to process
• Sufficient for screenshot-based testing and simple automation

Use full mode when you're debugging. Use slim mode when you're automating.

Privacy and Data Considerations

A few things to know:

• Your browser data is exposed to the MCP client. Chrome DevTools MCP gives your agent access to everything in the browser — cookies, local storage, network data. Don't connect it to a browser with sensitive sessions unless you trust your MCP client.
• Google collects usage statistics (tool invocation rates, latency, environment info) by default. Opt out with --no-usage-statistics.
• Performance tools may query CrUX API. If you use performance analysis, trace URLs may be sent to Google's CrUX API for real-user data. Disable with --no-performance-crux.

How This Fits Into the MCP Ecosystem

Chrome DevTools MCP is one piece of a larger shift. Server-side MCP is redefining how AI agents connect to tools and services — moving from local stdio pipes to HTTP-based, authenticated, observable server connections.

DevTools MCP currently runs as a local stdio server (your agent starts it as a subprocess). But the pattern it establishes — giving agents *real* access to *real* browser state — is exactly the kind of tool integration that server-side MCP will scale across enterprises.

Today, it's one developer connecting one agent to one browser. Tomorrow, it's a CI pipeline where agents automatically debug failed E2E tests by connecting to headless Chrome, analyzing the failure, and proposing fixes in PRs.

Should You Use It?

Yes, if:

• You do frontend development and debug browser issues regularly
• You use an MCP-capable coding agent (Claude Code, Cursor, Copilot, Gemini)
• You want your agent to understand what your code *does*, not just what it *says*

Wait, if:

• You need Chrome stable (M144 is currently in Beta for --autoConnect)
• Your workflow is purely backend with no browser component
• You're not yet using MCP with your coding agent

The setup takes 5 minutes. The productivity gain — not having to be the middleman between your agent and your browser — is immediate and compounding.

*Related: MCP Is Not Dead: Why Server-Side MCP Changes Everything | Claude Code vs Cursor vs GitHub Copilot*

FAQ

What is Chrome DevTools MCP?

Chrome DevTools MCP is a Model Context Protocol server giving AI assistants direct access to Chrome DevTools — allowing them to inspect DOM, monitor network requests, read console logs, and run JavaScript in your browser.

How do I set up Chrome DevTools MCP?

Install via npm, configure in your AI client (Claude Desktop, Cursor) as a tool, then launch Chrome with --remote-debugging-port=9222. The AI can then interact with your browser directly.

Is Chrome DevTools MCP safe?

Use with caution — this MCP gives AI direct browser access including reading page content and executing JavaScript. Use only with trusted clients, on non-sensitive profiles, and only enable when actively debugging.

What can AI do with Chrome DevTools access?

AI can: read console errors, inspect network requests, analyze DOM, run JavaScript, take screenshots, and navigate pages. Enables AI-assisted debugging where the AI sees the same browser state you do.

Which AI clients support Chrome DevTools MCP?

Any MCP-compatible client: Claude Desktop, Cursor, Cody, Zed, and custom clients using the MCP SDK. The protocol is client-agnostic — configure once and use with any compatible AI tool.