Installing Chrome DevTools MCP

Chrome DevTools MCP gives a coding agent access to a real Chrome browser along with DevTools capabilities such as performance traces, network analysis, and console access. Setup needs no prior installation: the server is launched via npx, which downloads it on the fly.

Requirements for Chrome DevTools MCP

An LTS version of Node.js and a current stable version of Chrome. Check your Node version with:

node --version

Registering Chrome DevTools MCP with your client

MCP clients read their servers from a JSON configuration. The entry for Chrome DevTools MCP looks like this:

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

Where this file lives differs by client. The official client configuration guide documents setup for, among others, Claude Code, Cursor, Codex, VS Code/Copilot, Gemini CLI, Windsurf, and Cline.

Slim mode for simpler tasks

If you only need basic browser tasks, reduce the tool set with --slim, optionally combined with --headless:

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

Disabling usage statistics and CrUX lookups

By default, Google collects anonymous usage statistics, and performance tools can send trace URLs to the Chrome User Experience Report (CrUX) API. Both can be turned off via flags:

npx -y chrome-devtools-mcp@latest --no-usage-statistics --no-performance-crux

Verifying the connection

After restarting the client, test with a simple task such as "Open example.com and take a screenshot" to confirm the browser launches and the agent receives a response. If nothing happens, check whether Chrome (or Chrome for Testing) is actually installed and reachable from the runtime environment — the server doesn't bundle its own browser binary.

Combining flags for CI environments

In continuous integration environments without a display server, --headless is required in addition to --slim if only basic automation is needed; without it, the server may fail to launch a visible browser window and error out. For debugging failed CI runs, temporarily removing --headless locally (on a machine with a display) can help reproduce the issue visually before diagnosing it purely from logs.

Attaching to an existing Chrome process

Instead of launching a new browser every time, the server can connect to an already-running Chrome process via the --browserUrl option, provided it was started with the remote debugging port enabled. This saves startup time on repeated test runs and lets you keep the same browser state across multiple agent sessions.

Troubleshooting missing tools

If the client shows no Chrome DevTools tools after configuration, it's usually malformed JSON syntax in the configuration file or an outdated Node.js version. A second common case is Chrome being installed but not discoverable on the system path — the path to the Chrome binary can then be specified explicitly via --executablePath.

Source: github.com/ChromeDevTools/chrome-devtools-mcp, checked on 2026-09-05.