TL;DR

Chrome DevTools MCP is an open-source MCP server (39K+ GitHub stars) that gives AI coding agents like Claude Code, Cursor, and Gemini CLI direct access to a live Chrome browser. It exposes 44 tools across 10 categories, from take_screenshot to performance_start_trace, letting your agent see what your code actually does in the browser instead of guessing. Setup takes one JSON block. I’ve been running it with Claude Code for the past two weeks, and it has changed how I debug frontend issues.

Why Your AI Agent Is Coding Blind

Every AI coding agent has the same problem: it writes code but can’t see the result. So you end up copy-pasting error messages, screenshots, and computed styles into the chat, and the agent guesses its way toward a fix that may or may not address what’s actually on screen.

I spent a solid hour last month going back and forth with Claude Code on a layout bug in a React dashboard. The sidebar was overflowing on tablet viewports, and I kept pasting console output, viewport sizes, and computed styles. Claude Code kept proposing fixes that looked reasonable in isolation but missed the actual culprit — a position: sticky element inside a flex container with overflow: hidden. The fix was two lines, but the diagnosis took an hour because the agent couldn’t inspect the DOM.

Chrome DevTools MCP removes that bottleneck. Instead of you being the bridge between the browser and the agent, the agent connects to Chrome directly. It navigates pages, reads console logs, inspects network requests, takes screenshots, records performance traces, and runs JavaScript in the page context. All through the same MCP protocol that powers tool use in Claude Code, Cursor, and Gemini CLI.

The server launched in September 2025 and has shipped 48 releases since. Version 0.26.0 shipped in May 2026. Earlier releases added memory profiling (v0.21.0), slim mode (v0.18.0), and extension management. The project is Apache-2.0 licensed, fully open source, and maintained by the Chrome DevTools team at Google.

Setting Up Chrome DevTools MCP

Prerequisites

You need three things:

  • Node.js v20.19+ (the latest maintenance LTS)
  • Chrome (stable channel or newer)
  • An MCP-capable coding agent (Claude Code, Cursor, Gemini CLI, Copilot, Windsurf, VS Code, or any of the 20+ supported clients). If you’re new to MCP, our FastMCP tutorial covers the protocol basics

With Claude Code

Add the MCP server to your project or user config:

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

Or add it directly to your .claude/settings.json:

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

The server auto-launches Chrome when a tool needs it.

With Cursor

Open Cursor Settings, go to the MCP section, and add this server config:

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

With Gemini CLI

gemini mcp add chrome-devtools npx chrome-devtools-mcp@latest

Headless Mode

If you’re on a remote server or inside a container without a display, add --headless:

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

Slim Mode (3 Tools Only)

The full 44-tool suite can overwhelm models with smaller context windows. Slim mode exposes only the three most-used tools:

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

The 44 Tools: What You Actually Get

The server exposes 44 tools across 10 categories:

CategoryToolsWhat They Do
Input (10)click, click_at, drag, fill, fill_form, handle_dialog, hover, press_key, type_text, upload_fileSimulate user interactions — clicking buttons, filling forms, uploading files, handling browser dialogs
Navigation (6)navigate_page, new_page, close_page, list_pages, select_page, wait_forControl page lifecycle — open URLs, manage tabs, wait for elements or network idle
Debugging (8)evaluate_script, get_console_message, list_console_messages, take_screenshot, take_snapshot, screencast_start, screencast_stop, lighthouse_auditRead console output, execute JavaScript, capture screenshots, run Lighthouse audits
Performance (3)performance_start_trace, performance_stop_trace, performance_analyze_insightRecord Chrome performance traces and extract LCP, TBT, and layout shift data
Network (2)list_network_requests, get_network_requestInspect HTTP requests, responses, headers, and timings
Memory (4)take_memory_snapshot, get_memory_snapshot_details, get_nodes_by_class, load_memory_snapshotCapture heap snapshots and track memory leaks by class
Extensions (5)install_extension, list_extensions, reload_extension, trigger_extension_action, uninstall_extensionLoad, manage, and interact with Chrome extensions during testing
Emulation (2)emulate, resize_pageSimulate devices, throttle CPU/network, resize viewports
Third-party (2)execute_3p_developer_tool, list_3p_developer_toolsRun registered third-party developer tools
WebMCP (2)execute_webmcp_tool, list_webmcp_toolsExecute tools exposed by pages via WebMCP

The tools I reach for most: take_screenshot (confirm visual output), list_console_messages (catch errors without pasting), evaluate_script (run DOM queries in page context), and the three performance_* tools for auditing.

Workflow 1: Debugging a Broken Page

Last week I ran a real debugging session on a Next.js app where images on a product grid were failing to load after a CDN migration. With Chrome DevTools MCP connected to Claude Code, I typed:

A few product images on localhost:3000/products are broken. Diagnose and fix.

Claude Code called navigate_page to open the URL, then list_console_messages to check for errors. It found three net::ERR_CERT_COMMON_NAME_INVALID errors in the console — the new CDN endpoint was serving certificates for the old domain. Next it called list_network_requests and filtered for failed image requests, confirmed the pattern (all images from cdn-old.example.com instead of cdn.example.com), then traced it to an environment variable that still pointed to the old domain.

The fix was one line in .env.production.

Claude Code found the problem on its own. It read the console and network panel the same way I would have in DevTools, except it did it in about 90 seconds instead of the 15 minutes I’d have spent tab-switching.

Workflow 2: Performance Auditing

Performance traces are where Chrome DevTools MCP earns its keep. Instead of asking your agent to “improve performance” based on a Lighthouse score you paste in, the agent can record its own trace, extract its own metrics, and propose fixes grounded in real data.

The workflow looks like this:

Run a performance trace on localhost:3000 and identify the biggest bottleneck.

What happens behind the scenes:

  1. Claude Code calls navigate_page to open the URL
  2. Calls performance_start_trace to begin recording
  3. Waits for the page to finish loading (wait_for with networkIdle)
  4. Calls performance_stop_trace to end the recording
  5. Calls performance_analyze_insight to extract actionable metrics

The insight output includes LCP (Largest Contentful Paint), TBT (Total Blocking Time), CLS (Cumulative Layout Shift), and specific recommendations — like “LCP element is a 2.4 MB hero image; serve it as WebP at 1200px width to cut load time by ~1.8 seconds.”

I ran this on a client’s landing page and the agent found that a third-party analytics script was blocking rendering for 1.2 seconds. The fix was adding async to the script tag. I wouldn’t have found that as fast by staring at a waterfall chart. The agent extracted the blocking time directly from the trace data and pinpointed the resource.

Connecting to Your Own Browser Session

By default, Chrome DevTools MCP launches a fresh Chrome instance with an isolated profile. Your cookies, extensions, and login sessions are not shared. For most development work, that’s the right default.

But sometimes you need the agent to work with your actual browser: testing a page behind authentication, inspecting a session with specific cookies set, or debugging a Chrome extension you have installed.

Chrome 144+ supports autoConnect mode:

Step 1: Open chrome://inspect/#remote-debugging in your browser and enable remote debugging.

Step 2: Launch the MCP server with --autoConnect:

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

Step 3: Chrome shows a permission dialog each time the agent requests access. You approve or deny per-session.

While the session is active, Chrome displays a yellow banner: “Chrome is being controlled by automated test software.” That banner is intentional and prevents silent background access.

For older Chrome versions, connect manually via the remote debugging port:

# Start Chrome with debugging port
google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-debug

# Configure MCP to connect
{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["-y", "chrome-devtools-mcp@latest", "--browser-url=http://localhost:9222"]
    }
  }
}

Privacy and Security: What to Know

The server exposes your browser’s DOM, network traffic, and console output to the MCP client. That means anything visible in the browser (cookies, auth tokens, form data, page content) can be read by the AI model.

Three defaults to be aware of. Usage statistics are sent to Google by default for reliability monitoring — disable with --no-usage-statistics or the CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS environment variable. CrUX API queries are also enabled by default for performance insights (disable with --no-performance-crux). And the server periodically checks the npm registry for updates, which you can turn off with CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS.

For sensitive work, use --isolated to create a temporary profile that gets cleaned up after the session ends. And never use autoConnect on a browser session with active banking or healthcare tabs. The agent can see everything the browser can see. For more on keeping AI agents from doing damage, see our AI agent guardrails guide.

44
Browser tools exposed
39K+
GitHub stars
48
Releases shipped
20+
Supported clients

Configuration Reference

Here’s every flag worth knowing:

FlagDefaultWhat It Does
--headlessfalseRun Chrome without a visible window
--isolatedfalseUse a temporary profile, cleaned up after session
--slimfalseExpose only 3 tools instead of 44
--autoConnectfalseConnect to your existing Chrome session (Chrome 144+)
--channelstableChrome channel: canary, dev, beta, stable
--viewport1280x720Initial browser viewport size
--browserUrlConnect to existing Chrome via debugging URL
--wsEndpointConnect via WebSocket endpoint
--experimentalVisionfalseEnable coordinate-based tools for vision-capable models
--no-usage-statisticsfalseDisable telemetry to Google
--no-performance-cruxfalseDisable CrUX API queries

When Chrome DevTools MCP Falls Short

Not everything works smoothly. A few rough edges I’ve hit:

Large DOM trees slow down take_snapshot. On a page with 10,000+ DOM nodes (think admin dashboards with nested tables), the snapshot can take 5-10 seconds and the resulting payload sometimes exceeds model context limits. Use evaluate_script with a targeted document.querySelector instead.

The performance_analyze_insight tool summarizes traces well, but if you need granular frame-by-frame analysis, you’re better off opening the trace file in Chrome DevTools manually. The MCP abstraction trades detail for convenience.

Browser extensions can also interfere. Ad blockers and privacy extensions modify network requests and DOM in ways that confuse the agent’s diagnosis. Use --isolated or disable extensions when debugging.

And there’s no cross-browser support. It’s Chrome only. Chromium forks like Edge technically work but aren’t officially supported. Firefox and Safari are out entirely. If your bug only reproduces in Safari, Chrome DevTools MCP won’t help.

FAQ

What is Chrome DevTools MCP?

Chrome DevTools MCP is a Model Context Protocol server maintained by the Chrome DevTools team at Google. It connects AI coding agents (Claude Code, Cursor, Gemini CLI, and others) to a live Chrome browser, giving them access to 37 debugging, performance, and automation tools. The agent can navigate pages, read console errors, inspect network requests, take screenshots, and record performance traces, all through natural language prompts.

How do I set up Chrome DevTools MCP with Claude Code?

Run claude mcp add chrome-devtools --scope user -- npx -y chrome-devtools-mcp@latest in your terminal. Alternatively, add the server config to .claude/settings.json under the mcpServers key. The server auto-launches Chrome when needed. No additional configuration is required for basic use.

What tools does Chrome DevTools MCP provide?

44 tools across 10 categories: Input Automation (10 tools for clicks, form fills, keyboard input), Navigation (6 tools for page management), Debugging (8 tools including screenshot capture, console reading, and Lighthouse audits), Performance (3 tools for trace recording and analysis), Network (2 tools for request inspection), Memory (4 tools for heap snapshots), Extensions (2 tools), and Emulation (2 tools for device simulation and viewport resizing).

Can Chrome DevTools MCP debug performance issues?

Yes. The performance tools (performance_start_trace, performance_stop_trace, performance_analyze_insight) record a full Chrome performance trace and extract actionable metrics including LCP, TBT, and CLS. The agent can identify render-blocking resources, slow network requests, and layout shift sources from the trace data, then propose fixes grounded in actual measurements.

Is Chrome DevTools MCP safe to use with sensitive data?

The server exposes browser content (cookies, auth tokens, page data) to the MCP client. For sensitive work, use --isolated mode (temporary profile, cleaned up after session) and avoid --autoConnect on browsers with active banking or healthcare sessions. Disable telemetry with --no-usage-statistics. The server is Apache-2.0 licensed and the code is fully auditable.

Sources

Bottom Line

Chrome DevTools MCP solves the most annoying bottleneck in AI-assisted frontend development: the agent writes code but can’t see the result. With 44 tools spanning debugging, performance, network, and automation, your agent finally gets direct access to what’s happening in the browser instead of relying on your copy-pasted descriptions.

Setup is one JSON block. The performance tracing workflow alone is worth the five minutes of installation — the agent records its own trace, extracts real metrics, and proposes fixes backed by actual data. I’ve stopped pasting Lighthouse screenshots into Claude Code. It just runs its own audits now.