Chrome DevTools MCP Guide 2026: Give Your AI Agent Real Browser Eyes

Table of Contents

1. What Is the Chrome DevTools MCP?
2. Why It Matters: Agents That Can See
3. What the Tools Actually Do
4. Installation and Setup
5. Workflow 1: Performance Debugging
6. Workflow 2: Network and Console Debugging
7. Workflow 3: UI Verification Loops
8. Chrome DevTools MCP vs Playwright MCP
9. Comparison Table
10. Security Notes
11. Frequently Asked Questions

What Is the Chrome DevTools MCP?

The Chrome DevTools MCP is an official Model Context Protocol server from the Chrome DevTools team at Google, first shipped as a public preview in September 2025 and hardened steadily since. It exposes the capabilities of Chrome DevTools, the same panel you open with F12, as MCP tools an AI agent can call: record a performance trace, list network requests, read console messages, evaluate JavaScript, click, type, navigate, screenshot.

Under the hood it drives Chrome through Puppeteer and the Chrome DevTools Protocol (CDP), which is what DevTools itself uses. That pedigree matters: the performance insights it returns are the actual DevTools trace analysis, not a reimplementation. The project is open source at ChromeDevTools/chrome-devtools-mcp, and the registry mirrors (official MCP registry listing, community variants) all trace back to it.

Why It Matters: Agents That Can See

Before browser-debugging MCPs, the loop for front-end work with an AI agent looked like this: the agent edits code, you reload the page, you describe what broke, the agent guesses. The agent was a developer who had never once seen a browser.

Chrome DevTools MCP closes that loop. The agent can now open the page itself, observe the actual rendered result, read the actual error, measure the actual LCP, and verify its own fix before claiming success. In practice this converts whole categories of "trust me, that should work" into "I loaded the page, the console is clean, and LCP dropped from 3.1s to 1.4s." If you are assembling a broader agent toolkit, our roundup of the best desktop MCP servers shows where a debugging MCP fits alongside file, database, and git access.

What the Tools Actually Do

The server ships roughly two dozen tools across six groups:

• Performance: performance_start_trace, performance_stop_trace, and trace-insight analysis. Records real DevTools traces and returns structured findings: LCP breakdown, render-blocking requests, layout shift sources, long main-thread tasks.
• Network: list requests with status, timing, and size; inspect individual request and response bodies and headers. Your agent can spot the 404, the slow third-party script, or the uncompressed image by itself.
• Debugging: read console messages and errors, evaluate JavaScript in page context. The classic "open the console and tell me what is red" step, automated.
• Input automation: click, hover, drag, fill forms, upload files, handle dialogs.
• Navigation: open and close pages, switch tabs, go back and forward, wait for conditions.
• Emulation: CPU throttling, network throttling, viewport resizing, so the agent can test your page as a mid-range phone on slow 4G instead of your workstation on fiber.

Installation and Setup

Prerequisites: Node.js 22+, a current Chrome install. Then it is one command per client.

Claude Code:

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

Claude Desktop, Cursor, Windsurf (JSON config):

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

Useful flags: --headless for CI environments, --channel canary to test against Chrome Canary, and --isolated to guarantee a throwaway profile. First run downloads nothing extra; it finds your installed Chrome and starts it when the first tool call arrives.

Smoke test: ask your agent "Check the performance of https://developer.chrome.com". You should see Chrome open, a trace record, and a structured performance summary come back. The Skiln Config Generator can bundle this server with the rest of your MCP stack in one paste-ready config.

Workflow 1: Performance Debugging

The flagship use case. A real session looks like this:

1. Prompt: "Localhost:3000 feels slow. Trace it and fix the biggest issue."
2. The agent starts a performance trace, reloads the page, stops the trace.
3. The insights come back structured: LCP 3.4s, dominated by a render-blocking font stylesheet and an unoptimized hero image; a 1.2s long task from a synchronously-loaded analytics bundle.
4. The agent edits your code: preloads the font, swaps the hero to a responsive next-gen format, defers the analytics script.
5. It re-traces and reports the delta: LCP 3.4s to 1.6s, CLS unchanged, long task gone.

The agent measures, changes, and re-measures without you opening DevTools once. Tools like CPU and network throttling make the loop honest: a page that is fast on your machine gets re-tested as a throttled mobile device before the agent declares victory.

Workflow 2: Network and Console Debugging

Equally valuable for correctness bugs:

• "The dashboard renders empty. Find out why." The agent loads the page, reads the console (a CORS error), inspects the failing request, sees the API call hitting the wrong origin, and fixes the env config.
• "Why is checkout slow only in production?" The network list exposes a third-party tag firing 14 sequential requests; the agent flags it with timings as evidence.
• "Form submit does nothing." Console shows an uncaught TypeError from a null selector; the agent reproduces it by actually clicking the button, then patches the handler and re-clicks to verify.

This is the workflow where the MCP pays for itself daily: console errors and network waterfalls are exactly the context agents always lacked.

Workflow 3: UI Verification Loops

Pair it with a design-side skill and you get a closed loop: the skill decides what the UI should look like, the browser confirms what it actually looks like. After any front-end change, the agent navigates to the page, screenshots it, checks the rendered state against the intent, and iterates. Combined with something like the UI/UX Pro Max skill for design decisions, this is the closest thing yet to an agent that designs, builds, and visually verifies in one pass.

Chrome DevTools MCP vs Playwright MCP

The question everyone asks. The honest answer is that they overlap heavily (both can navigate, click, fill, and screenshot) but optimize for different jobs:

• Playwright MCP is automation-first. Cross-browser (Chromium, Firefox, WebKit), accessibility-tree driven, built for acting on pages and end-to-end flows. See our browser automation MCP roundup for that side of the ecosystem, including the leading Playwright MCP servers.
• Chrome DevTools MCP is debugging-first. Chrome-only, CDP-native, and the only MCP with first-party performance trace analysis. Network and console inspection are deeper because they are the point, not a bonus.

Many teams run both: Playwright MCP for test automation, DevTools MCP for performance and debugging. They do not conflict, and agents pick sensibly when both are described well.

Comparison Table

Security Notes

Three rules keep it safe:

1. Default to the isolated profile. Do not attach the server to your daily Chrome profile; the agent would inherit your logged-in sessions. The fresh-instance default exists for a reason.
2. Watch what it browses. Page content is untrusted input to the model. A malicious page can try to inject instructions, so point the agent at sites you chose, and treat unexpected navigation as a red flag.
3. Be careful with evaluate_script on authenticated apps. Executing agent-written JavaScript inside a page that holds real user data deserves the same review you would give a code change.

Sensible defaults plus the visible browser window (you can literally watch what the agent does) make this one of the easier MCPs to supervise.

Frequently Asked Questions

What is the Chrome DevTools MCP?

Chrome DevTools MCP is the official MCP server from the Google Chrome team (ChromeDevTools/chrome-devtools-mcp on GitHub). It connects AI coding agents to a live Chrome browser through the Chrome DevTools Protocol, so the agent can record performance traces, inspect network requests, read console errors, take screenshots, and interact with pages exactly as DevTools does.

How do I install the Chrome DevTools MCP?

One command in most clients. For Claude Code: claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest. For Claude Desktop, Cursor, or Windsurf, add an mcpServers entry with command npx and args ['chrome-devtools-mcp@latest']. Node.js 22+ and a current Chrome install are the only prerequisites.

Is the Chrome DevTools MCP free?

Yes, completely. It is open source under an Apache-2.0 license, built and maintained by the Chrome DevTools team. It runs locally and drives your own Chrome, so there is no hosted service, no API key, and no usage billing beyond your normal AI client costs.

What is the difference between Chrome DevTools MCP and Playwright MCP?

Playwright MCP is automation-first: navigate, click, fill, assert, ideal for acting on pages. Chrome DevTools MCP is debugging-first: performance traces, Core Web Vitals analysis, network waterfalls, console inspection. There is real overlap (both can navigate, click, and screenshot since DevTools MCP uses Puppeteer under the hood), but if your question is 'why is this page slow or broken' DevTools MCP is the right tool, and if it is 'automate this flow' Playwright remains the default.

Can it analyze Core Web Vitals like LCP and CLS?

Yes, this is its signature feature. The performance_start_trace and performance_stop_trace tools record a real Chrome performance trace, and the server surfaces structured insights from it, including Largest Contentful Paint breakdowns, layout shift culprits, render-blocking resources, and main-thread bottlenecks the agent can then fix in your code.

Does it work with Claude Code, Cursor, and Gemini CLI?

Yes. It is client-agnostic MCP, and the README documents configs for Claude Code, Claude Desktop, Cursor, VS Code Copilot, Windsurf, Cline, Gemini CLI, and Codex. Any client that speaks MCP over stdio can use it.

Can it attach to my existing Chrome window?

By default it launches a fresh, isolated Chrome instance. You can pass flags like --channel to pick Chrome versions, --headless for CI use, and a browser URL option to attach to an already-running Chrome started with remote debugging enabled. Isolated mode is the safer default because the agent cannot see your logged-in profile.

Is it safe to let an AI agent control a browser?

Treat it like giving the agent a logged-out browser on your machine. The agent can navigate anywhere and execute JavaScript in the pages it opens, so avoid attaching it to your personal profile, keep it away from authenticated sessions you care about, and review what it did via the visible browser window. Content from web pages can also attempt prompt injection, so be deliberate about which sites you point it at.

Last updated: June 12, 2026 · Skiln tracks MCP server releases daily across 13 source registries.