guide12 min read1d ago

Chrome DevTools MCP: The 2026 Setup and Usage Guide for Claude

The complete 2026 guide to the Chrome DevTools MCP server: install in Claude Desktop, Claude Code, Cursor, and Windsurf. Performance traces, accessibility audits, network throttling, real workflows, plus a comparison to Puppeteer MCP and Playwright MCP.

Chrome DevTools MCP: The 2026 Setup and Usage Guide for Claude
chrome devtools mcpbrowser automationmcp serversclaude desktopclaude codecursorwindsurfmodel context protocol

TL;DR — Chrome DevTools MCP: Full Browser Control From Claude

The Chrome DevTools MCP server hands Claude the same low-level browser control surface that Chrome DevTools uses internally. Capture performance traces, run accessibility audits, throttle the network, evaluate JavaScript, inspect the DOM, take screenshots, intercept requests. It is the deepest browser-automation MCP available because it speaks the Chrome DevTools Protocol (CDP) directly. This guide walks through installation in Claude Desktop, Claude Code, Cursor, and Windsurf; compares it head-to-head with Puppeteer MCP and Playwright MCP; and shows the workflows engineers are actually running with it in 2026.

Tested daily in production by the Skiln editorial team

Table of Contents

  1. What Is the Chrome DevTools MCP?
  2. Why Not Just Puppeteer or Playwright MCP?
  3. Prerequisites
  4. Step-by-Step Installation
  5. What Claude Can Actually Do With It
  6. Real Workflows
  7. DevTools MCP vs Puppeteer MCP vs Playwright MCP
  8. Common Errors and How to Fix Them
  9. Security
  10. Frequently Asked Questions

What Is the Chrome DevTools MCP?

The Chrome DevTools MCP server is a Model Context Protocol server that wraps the Chrome DevTools Protocol (CDP) and exposes its commands as MCP tools. Once installed, your AI client can do anything you can do from the DevTools console: navigate to a URL, evaluate JavaScript in the page, capture a performance trace, inspect the accessibility tree, throttle network speed, click an element, take a screenshot, intercept HTTP requests, or pull computed CSS for an element.

CDP is the same protocol Chrome DevTools itself uses to talk to the browser. Every CDP method you have seen in the Protocol Monitor panel of DevTools is, in principle, callable from Claude through this MCP.

This makes it categorically different from the higher-level automation MCPs. Puppeteer MCP and Playwright MCP are great for scraping, form-filling, and end-to-end testing because they wrap CDP with a more ergonomic API. Chrome DevTools MCP is great for debugging because it does not wrap CDP — it just exposes it. We compare all three in detail in Playwright MCP vs Puppeteer MCP.

Why Not Just Puppeteer or Playwright MCP?

The honest answer: in 80% of cases you do not need both. Pick the right one for the job.

  • Pick Playwright MCP when you want to script a multi-step user journey, fill forms, click buttons, or do cross-browser testing. Friendly API, fast feedback.
  • Pick Puppeteer MCP when you want headless scraping in a Chromium-only environment and prefer Puppeteer's smaller dependency footprint over Playwright's broader feature surface.
  • Pick Chrome DevTools MCP when you want to debug, profile, or inspect a page. Trace performance. Audit accessibility. Watch the network panel. Capture heap snapshots. Run arbitrary CDP commands that no high-level library wraps.

In practice, engineering teams install Playwright MCP and Chrome DevTools MCP together — one for automation, one for inspection. Read the best Puppeteer MCPs of 2026 roundup for the other half of the matrix.

Prerequisites

Before installing, confirm you have:

  • Node.js 20 or later. Most Chrome DevTools MCP server distributions ship as an npm package. node --version should report 20+.
  • An MCP client installed. Claude Desktop, Claude Code, Cursor, Windsurf, Cline, or Zed all work. If you have not picked one yet, read our best MCP clients of 2026.
  • Chrome or Chromium available on the system. The MCP will download a managed Chromium build if one is not found, but pointing it at your existing Chrome installation is faster and uses less disk.
  • One free port in the 9222-9322 range. CDP listens on this port range by default and the MCP needs an open one.

Step-by-Step Installation

The most-installed Chrome DevTools MCP server in the Skiln directory is the official Chrome team's release. Install it with one command:

npx -y chrome-devtools-mcp@latest

That runs it once to verify it boots. Then wire it into your client of choice.

Configuring Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json on macOS or %APPDATA%\Claude\claude_desktop_config.json on Windows:

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

Restart Claude Desktop. A chrome-devtools entry appears in the tools sidebar within a few seconds.

Configuring Claude Code

Use the claude mcp add command instead of hand-editing JSON:

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

Restart your Claude Code session and the MCP shows up in /mcp.

Configuring Cursor and Windsurf

In Cursor: Settings → Cursor Settings → MCP → Add MCP Server. Paste the same npx command. Cursor will spawn the server on the next chat. Windsurf follows the same path through its Cascade settings.

The Skiln Config Generator outputs ready-to-paste configs for every major client format in one shot.

What Claude Can Actually Do With It

Once installed, Claude gets access to roughly 30 tools (the exact count varies by release). The categories that matter:

  • Navigation: navigate_to_url, reload, go_back, wait_for_load.
  • DOM inspection: query_selector, get_element_text, get_computed_style, screenshot_element.
  • JavaScript evaluation: evaluate runs arbitrary JS in the page context. This is the swiss-army knife — anything you cannot do with the dedicated tools, you can do here.
  • Performance: start_trace, stop_trace, get_trace_summary. Equivalent to the Performance panel in DevTools.
  • Network: set_throttling, intercept_request, get_network_log. Equivalent to the Network panel.
  • Accessibility: get_a11y_tree, run_axe_audit. Equivalent to the Accessibility panel plus axe-core.
  • Console: get_console_messages, clear_console. Equivalent to the Console panel.
  • Screenshots: screenshot_page, screenshot_full_page, screenshot_element. Same as the DevTools screenshot dropdown.

What Claude does with this surface depends on how you prompt. The richer you describe the goal ("audit example.com for accessibility issues at WCAG AA, throttle to Slow 3G, and tell me what would fail first") the more tools it chains together.

Real Workflows: Performance, A11y, Layout, Network

Patterns that have earned their keep in our daily usage:

1. Performance trace on a flagged route. Ask Claude to navigate to the slow URL, capture a 5-second trace with CPU throttled 4x, then summarize the longest tasks and the largest contentful paint candidate. Output is a prioritized fix list in plain English instead of a 50MB JSON blob.

2. WCAG audit before a release. Point the MCP at your staging URL, ask for an axe-core audit plus a manual accessibility-tree review of the navigation and main content regions. Claude returns a triaged list grouped by severity. Read our best MCPs for frontend developers for adjacent tools that round out the audit.

3. Layout-shift hunter. "Navigate to /pricing, scroll to the bottom, and report every Cumulative Layout Shift event." Claude orchestrates the trace, parses the layout-shift entries, and tells you which DOM nodes moved unexpectedly.

4. Network waterfall comparison. "Open /home, capture the network log, then open the same URL with cache disabled and compare." Identifies render-blocking requests, oversized images, and missing preload hints in one chat turn.

5. Console-error triage in CI-style runs. Have Claude visit your top 20 pages in sequence, collect console errors and warnings per page, and produce a CSV-style summary of which pages need attention. Cheaper than a Lighthouse CI run and the output is conversational.

DevTools MCP vs Puppeteer MCP vs Playwright MCP

MCPBest ForAPI SurfaceBrowser SupportTool Count
Chrome DevTools MCPDebugging & profilingCDP directChromium only30+ tools
Playwright MCPCross-browser automationPlaywright APIChromium, Firefox, WebKit20+ tools
Puppeteer MCPChromium scrapingPuppeteer APIChromium only15+ tools

If you only install one: Playwright MCP for the broadest coverage. If you install two: add Chrome DevTools MCP for debugging depth. The combo covers nearly every browser-automation need a developer has.

Common Errors and How to Fix Them

  • "Failed to launch the browser process." The MCP could not find or download a Chromium build. Install Chrome system-wide, or run npx -y puppeteer browsers install chrome once to seed the managed cache.
  • "Could not connect to CDP on port 9222." Another Chrome instance has the port locked. Pick a different port by passing --cdp-port 9233 in the MCP args, or close the running Chrome.
  • "Navigation timeout of 30000ms exceeded." The page took too long to settle. Increase the wait by prompting Claude to use wait_for_load with a longer timeout, or switch to wait_for_selector against an element that signals page-ready.
  • "Element not interactable." Common when the target is hidden behind a cookie banner. Ask Claude to dismiss the banner first, or pass a JS evaluation that auto-clicks the consent button.
  • MCP not showing in Claude after install. 95% of the time this is a Node version mismatch. Confirm node --version is 20+ and restart the client.

Security: Headless, Profiles, and the Auth Trap

Three rules to live by:

  1. Default to headless. Headless mode is faster, leaves no UI surface, and prevents accidental drag-and-drop or copy-paste from the visible window. Switch to headful only for live debugging and turn it back off when done.
  2. Never point at your real Chrome profile. Spin up a dedicated MCP-only profile with --user-data-dir=/path/to/ai-profile. Log into only the sites Claude actually needs. This single rule prevents 90% of the "the AI did something I did not expect" stories.
  3. Treat write actions as production-grade. A click or form-submit through Chrome DevTools MCP is indistinguishable from a real user action. If Claude is debugging a staging URL, do not give it credentials that can hit production endpoints.

The Claude Code security best practices guide covers the broader patterns for safe MCP usage.

Want the rest of the browser-automation landscape? Skiln indexes every Chromium-based MCP plus the Playwright and Puppeteer ecosystems with install commands, trust scores, and active-maintenance signals.

Browse Now →

Frequently Asked Questions

What is the Chrome DevTools MCP server?

The Chrome DevTools MCP server exposes the Chrome DevTools Protocol (CDP) over MCP. That gives a desktop AI client like Claude direct control of a real Chromium instance: navigate URLs, evaluate JavaScript, inspect the DOM, capture screenshots, throttle the network, run accessibility audits, and pull performance traces. It is the deepest browser-control MCP available because CDP is what Chrome DevTools itself uses.

How is it different from Puppeteer MCP and Playwright MCP?

All three drive a Chromium browser. Puppeteer MCP and Playwright MCP wrap higher-level browser-automation libraries with friendly tool surfaces (great for scraping and form filling). Chrome DevTools MCP gives you raw CDP access, so it shines for performance traces, accessibility tree inspection, network throttling, and any debugging task you would do inside Chrome DevTools itself. Most teams install Chrome DevTools MCP alongside Playwright MCP rather than instead of it.

Does it need a graphical browser to run?

No. The MCP server boots Chromium in headless mode by default. You can flip a flag to run it headful if you want to watch what Claude is doing in real time, which is incredibly useful while debugging your prompt patterns. On a server with no display, leave it headless.

Can it open my real Chrome profile?

Yes, but think carefully before doing it. Pointing the MCP at your real Chrome profile gives Claude access to every site you are currently logged into, plus your saved passwords if Chrome auto-fills them. The safer pattern is a dedicated AI-only profile with the cookies you explicitly need (typically just your dev site) and nothing else.

Will the Chrome DevTools MCP run Lighthouse?

Yes, indirectly. The MCP exposes CDP performance-trace and network-conditions endpoints, which is the same data Lighthouse uses. Some forks expose a higher-level lighthouse tool, but even the base server lets Claude orchestrate a full Lighthouse-style audit by combining trace capture, network throttling, and accessibility-tree inspection in sequence.

How safe is it to give an AI live access to a real browser?

Reasonably safe if you treat it the way you would treat a fresh Chromium VM, which is essentially what it is. Two precautions: run it in a dedicated profile so it cannot reach your authenticated sessions, and never start it pointed at production credentials. For production debugging, prefer the read-only inspection tools (screenshot, evaluate, trace) over the write-capable ones (click, type, navigate to mutation endpoints).

Does it work with Firefox or Safari?

No. Chrome DevTools MCP speaks CDP, which is Chromium-only. Firefox supports a partial CDP shim but the MCP server has not been tested against it. For cross-browser automation, the Playwright MCP is the right choice because Playwright drives Chromium, Firefox, and WebKit natively.

Where can I see other browser-automation MCP servers?

Browse the full browser-automation category on Skiln at /mcps. As of 2026 we index Chrome DevTools MCP, Playwright MCP, Puppeteer MCP, Browser MCP, BrowserUse MCP, and a dozen specialized variants like the Steel browser MCP and Hyperbrowser MCP.


Last updated: May 29, 2026 · Skiln re-tests every browser-automation MCP weekly against the latest Chromium release.

Frequently Asked Questions

What is the Chrome DevTools MCP server?
The Chrome DevTools MCP server exposes the Chrome DevTools Protocol (CDP) over MCP. That gives a desktop AI client like Claude direct control of a real Chromium instance: navigate URLs, evaluate JavaScript, inspect the DOM, capture screenshots, throttle the network, run accessibility audits, and pull performance traces. It is the deepest browser-control MCP available because CDP is what Chrome DevTools itself uses.
How is it different from Puppeteer MCP and Playwright MCP?
All three drive a Chromium browser. Puppeteer MCP and Playwright MCP wrap higher-level browser-automation libraries with friendly tool surfaces (great for scraping and form filling). Chrome DevTools MCP gives you raw CDP access, so it shines for performance traces, accessibility tree inspection, network throttling, and any debugging task you would do inside Chrome DevTools itself. Most teams install Chrome DevTools MCP alongside Playwright MCP rather than instead of it.
Does it need a graphical browser to run?
No. The MCP server boots Chromium in headless mode by default. You can flip a flag to run it headful if you want to watch what Claude is doing in real time, which is incredibly useful while debugging your prompt patterns. On a server with no display, leave it headless.
Can it open my real Chrome profile?
Yes, but think carefully before doing it. Pointing the MCP at your real Chrome profile gives Claude access to every site you are currently logged into, plus your saved passwords if Chrome auto-fills them. The safer pattern is a dedicated AI-only profile with the cookies you explicitly need (typically just your dev site) and nothing else.
Will the Chrome DevTools MCP run Lighthouse?
Yes, indirectly. The MCP exposes CDP performance-trace and network-conditions endpoints, which is the same data Lighthouse uses. Some forks expose a higher-level lighthouse tool, but even the base server lets Claude orchestrate a full Lighthouse-style audit by combining trace capture, network throttling, and accessibility-tree inspection in sequence.
How safe is it to give an AI live access to a real browser?
Reasonably safe if you treat it the way you would treat a fresh Chromium VM, which is essentially what it is. Two precautions: run it in a dedicated profile so it cannot reach your authenticated sessions, and never start it pointed at production credentials. For production debugging, prefer the read-only inspection tools (screenshot, evaluate, trace) over the write-capable ones (click, type, navigate to mutation endpoints).
Does it work with Firefox or Safari?
No. Chrome DevTools MCP speaks CDP, which is Chromium-only. Firefox supports a partial CDP shim but the MCP server has not been tested against it. For cross-browser automation, the Playwright MCP is the right choice because Playwright drives Chromium, Firefox, and WebKit natively.
Where can I see other browser-automation MCP servers?
Browse the full browser-automation category on Skiln at /mcps. As of 2026 we index Chrome DevTools MCP, Playwright MCP, Puppeteer MCP, Browser MCP, BrowserUse MCP, and a dozen specialized variants like the Steel browser MCP and Hyperbrowser MCP.

Stay in the Loop

Join 1,000+ developers. Get the best new Skills & MCPs weekly.

No spam. Unsubscribe anytime.

Chrome DevTools MCP: Complete 2026 Setup Guide for Claude & Cursor