Chrome DevTools MCP Server

About

Google's own MCP server for driving and inspecting a live Chrome instance — the one case where "browser automation" undersells what a server does, because automation is only one of eleven tool categories. It is built on Puppeteer for the clicking and typing (with automatic waiting for action results), and on the Chrome DevTools frontend for the part nothing else offers: `performance_start_trace` / `performance_stop_trace` record a real trace and `performance_analyze_insight` returns the same actionable insights the Performance panel shows, optionally alongside CrUX field data for the same URL. There is also `lighthouse_audit`. Roughly 56 tools ship across Input automation (10), Navigation (6), Emulation (2), Performance (3), Network (2), Debugging (8, including `take_snapshot` of the accessibility tree and source-mapped console messages), Memory heap-snapshot analysis (12), Extensions (5), third-party developer tools, WebMCP and Progressive Web Apps — but several of those categories are off by default and gated behind flags: `--categoryExtensions`, `--categoryPwa`, `--memoryDebugging`, `--experimentalScreencast` (needs ffmpeg), `--experimentalVision` for coordinate-based `click_at`. Run `--slim` for a smaller set if you only want basic browsing. By default the server launches its own Chrome against a dedicated profile at `$HOME/.cache/chrome-devtools-mcp/chrome-profile`, so it starts logged in to nothing; `--autoConnect` (Chrome 144+, with remote debugging enabled at `chrome://inspect/#remote-debugging`) or `--browserUrl=http://127.0.0.1:9222` instead attach it to a browser you are already using, which is how you test signed-in flows and also how an agent inherits your real session. Network access can be fenced with `--blockedUrlPattern` / `--allowedUrlPattern` (URLPattern syntax; the allow form needs Chrome 149+). Only Google Chrome and Chrome for Testing are officially supported. Note that usage statistics are collected by default and CrUX lookups are on by default — opt out with `--no-usage-statistics` and `--no-performance-crux`.

Installation

npx -y chrome-devtools-mcp@latest

Setting up Chrome DevTools MCP

1. 1.Add the server with its own Chrome

   Node LTS and a current stable Chrome are the only requirements, and there is nothing to install ahead of time. Pinning to @latest is the README recommendation rather than an accident — the tool surface moves, and 1.7.0 was published five days before this guide was verified. Note that the browser does not start when the client connects; it starts the first time a tool needs it, so an empty tab list right after connecting is expected.

   shell

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

2. 2.Or paste the client config directly

   The same entry works in Cursor, VS Code, Cline, Codex, Copilot CLI, Gemini CLI and Antigravity, which all take a command-plus-args block. On Windows 10, an MCP error -32000 "Connection closed" during discovery usually means npx is not resolving from inside the host process; the documented fix is to run it through cmd /c, or to give the absolute path to the npx shim.

   mcp.json

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

3. 3.Decide whether it drives your browser or its own

   This is the real configuration decision. The default profile lives at $HOME/.cache/chrome-devtools-mcp/chrome-profile (per channel, and reused between runs — only one browser can hold it at a time, so pass --isolated for a temporary one). That profile has none of your logins, which is why testing a signed-in flow pushes people to attach to a running Chrome instead. Chrome 144+ supports --autoConnect: enable remote debugging at chrome://inspect/#remote-debugging, and the server connects to your default profile after you approve a permission dialog — with access to every open window in it.

   mcp.json

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

4. 4.Or attach over the remote debugging port

   The older, sandbox-friendly path. Start Chrome yourself with a debugging port and point the server at it with --browserUrl. Chrome requires a non-default user data directory when the port is open, which is a security measure and not an inconvenience to work around: the port is unauthenticated, so any process on the machine can drive that browser for as long as it is open. Close it when you are done, and do not browse anything sensitive in that window.

   shell

   # macOS — start Chrome with the port open
   /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
     --remote-debugging-port=9222 \
     --user-data-dir=/tmp/chrome-profile-stable
   
   # then run the server against it
   npx chrome-devtools-mcp@latest --browser-url=http://127.0.0.1:9222

5. 5.Turn on the tool categories you actually want

   Several categories are off by default, so "the extension tools are missing" is a flag, not a bug. --categoryExtensions and --categoryPwa both require a pipe connection and do not work with --autoConnect, --browserUrl or --wsEndpoint. --memoryDebugging adds the twelve heap-snapshot tools, --experimentalScreencast needs ffmpeg on the server PATH, and --experimentalVision adds coordinate-based click_at, which is only useful with a model that can produce accurate coordinates from a screenshot. Going the other way, --slim trims to a basic browsing set and --categoryEmulation=false, --categoryPerformance=false or --categoryNetwork=false drop what you are not using.

   shell

   npx chrome-devtools-mcp@latest --memoryDebugging --categoryExtensions

6. 6.Fence the network and shrink the screenshots

   Two settings worth changing before an agent runs unattended. --blockedUrlPattern and --allowedUrlPattern restrict what the browser can reach using URLPattern syntax, blocking navigations and subresources and silently detaching from targets that violate them (the allow form needs Chrome 149+). And screenshots are the fastest way to burn a context window: --screenshotFormat webp with --screenshotQuality and --screenshotMaxWidth produces images three to five times smaller than the PNG default.

   shell

   npx chrome-devtools-mcp@latest \
     --allowedUrlPattern "https://staging.example.com/*" \
     --screenshotFormat webp --screenshotMaxWidth 1200

7. 7.Opt out of the telemetry if you need to

   Both defaults here are on. Google collects usage statistics — tool invocation success rates, latency, environment information — unless you pass --no-usage-statistics or set CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS; it is disabled automatically when CI is set. Separately, the performance tools send trace URLs to the CrUX API to fetch real-user field data, which --no-performance-crux turns off. Opting out of Chrome browser metrics does not cover either of these.

   mcp.json

   {
     "args": ["-y", "chrome-devtools-mcp@latest", "--no-usage-statistics", "--no-performance-crux"]
   }

What it can do

Roughly fifty-six tools across eleven categories, and the split is the argument for using this server rather than a general browser one. Input automation, navigation and emulation are table stakes; performance, network, debugging and memory are the DevTools panels, and nothing else exposes them over MCP.

What people use it for

Which one should you use?

Three servers drive a browser and they are not interchangeable — the question is what you want out of the page.

Categories

Works With

Frequently Asked Questions

Related Guides