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:
| Category | Tools | What They Do |
|---|---|---|
| Input (10) | click, click_at, drag, fill, fill_form, handle_dialog, hover, press_key, type_text, upload_file | Simulate user interactions — clicking buttons, filling forms, uploading files, handling browser dialogs |
| Navigation (6) | navigate_page, new_page, close_page, list_pages, select_page, wait_for | Control 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_audit | Read console output, execute JavaScript, capture screenshots, run Lighthouse audits |
| Performance (3) | performance_start_trace, performance_stop_trace, performance_analyze_insight | Record Chrome performance traces and extract LCP, TBT, and layout shift data |
| Network (2) | list_network_requests, get_network_request | Inspect HTTP requests, responses, headers, and timings |
| Memory (4) | take_memory_snapshot, get_memory_snapshot_details, get_nodes_by_class, load_memory_snapshot | Capture heap snapshots and track memory leaks by class |
| Extensions (5) | install_extension, list_extensions, reload_extension, trigger_extension_action, uninstall_extension | Load, manage, and interact with Chrome extensions during testing |
| Emulation (2) | emulate, resize_page | Simulate devices, throttle CPU/network, resize viewports |
| Third-party (2) | execute_3p_developer_tool, list_3p_developer_tools | Run registered third-party developer tools |
| WebMCP (2) | execute_webmcp_tool, list_webmcp_tools | Execute 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:
- Claude Code calls
navigate_pageto open the URL - Calls
performance_start_traceto begin recording - Waits for the page to finish loading (
wait_forwithnetworkIdle) - Calls
performance_stop_traceto end the recording - Calls
performance_analyze_insightto 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.
Configuration Reference
Here’s every flag worth knowing:
| Flag | Default | What It Does |
|---|---|---|
--headless | false | Run Chrome without a visible window |
--isolated | false | Use a temporary profile, cleaned up after session |
--slim | false | Expose only 3 tools instead of 44 |
--autoConnect | false | Connect to your existing Chrome session (Chrome 144+) |
--channel | stable | Chrome channel: canary, dev, beta, stable |
--viewport | 1280x720 | Initial browser viewport size |
--browserUrl | — | Connect to existing Chrome via debugging URL |
--wsEndpoint | — | Connect via WebSocket endpoint |
--experimentalVision | false | Enable coordinate-based tools for vision-capable models |
--no-usage-statistics | false | Disable telemetry to Google |
--no-performance-crux | false | Disable 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
- Chrome DevTools MCP — official Chrome blog post — launch announcement and architecture overview
- ChromeDevTools/chrome-devtools-mcp on GitHub — source code, full tool reference, and setup docs (39K+ stars, Apache-2.0)
- Let your Coding Agent debug your browser session — Chrome Developers — autoConnect feature guide for Chrome 144+
- Give your AI eyes — Addy Osmani — practical use cases and workflow examples from a Chrome DevTools team member
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.