Chrome DevTools for agents

Unofficial low-memory fork

This fork targets roughly 200 MiB for all MCP service processes combined during ordinary automation. Chrome and the coding agents themselves are excluded. Clients connect directly to one shared HTTP MCP process, without per-pane stdio processes. This is a measurement target, not an enforced limit or a guarantee for arbitrary pages and traces.

Representative macOS ARM64 measurements with eight clients, two fixture pages, 250 requests and 1,000 console messages per page:

The direct-HTTP process's lifetime peak was 210.9 MiB. These are separate isolated synthetic runs; real sites and allocator timing vary. Raw reports: comparison and final HTTP run.

Build from this repository with npm run sync and npm run build. Start the service once with node build/src/bin/chrome-devtools-mcp-http.js <browser connection flags>. This launcher enables --lowMemory, disables usage statistics, and exits after printing the HTTP URL and private bearer-token file path. Configure each MCP client with that URL and a bearer token read from the printed file. The default endpoint is http://127.0.0.1:9335/mcp. HTTP uses stateful, initialize-based Streamable HTTP sessions. SDK clients using automatic negotiation can fall back to this protocol; clients pinned to a modern discover-only protocol are not supported by this entry point. The service binds only to loopback, requires its private token, rejects browser origins and unexpected Host headers, and limits request bodies to 1 MiB. Token contents never appear in startup output or memory reports. Tokens persist across reboots in $XDG_STATE_HOME/chrome-devtools-mcp/<session>/http-token, defaulting to ~/.local/state/chrome-devtools-mcp/<session>/http-token.

For clients that only support stdio, the alternative entry point is node build/src/bin/chrome-devtools-mcp-shared.js with the same connection flags. Each such client adds its own frontend process, which counts against the combined target. Existing chrome-devtools-mcp and chrome-devtools entry points remain available. Choose HTTP to avoid this per-client cost.

• Page discovery does not initialize the selected page until a tool uses it. Enabling WebMCP or third-party tool discovery requires initialization.

• Each initialized page retains one navigation, 100 network requests and 200 console entries. Entries expire after 60 seconds and idle caches are swept every 30 seconds. Issue aggregation has a separate bounded cache.

• Source maps are disabled in low-memory mode, including after config reload.

• Calls are serialized across clients. Selected pages, filesystem roots and accessibility snapshots are restored per client. At most 16 clients and two snapshots per client are retained; idle client state expires after ten minutes, with a one-minute sweep. After eviction, take a fresh snapshot.

• HTTP sessions are also capped at 16. At capacity, an inactive session idle for over a minute can be replaced; other idle sessions expire after ten minutes. Reinitialize the HTTP connection after session expiry. Clients should send DELETE when ending their HTTP session.

Clients still share the same browser, cookies and live page state. Navigating or closing a shared page affects every client using it. This is not a browser or security isolation boundary. Long recordings, large snapshots, retained debugger state and many initialized pages can exceed the memory target.

Use the same CHROME_DEVTOOLS_MCP_SESSION_ID for clients sharing a backend (default 200-ba5e); IDs may contain only hexadecimal digits and hyphens. Different browser configurations must use different IDs. Concurrent startup is serialized with an exclusive lock; a conflicting configuration is rejected. Both module-loading and readiness waits allow up to 60 seconds. If a new daemon exits early, startup fails promptly; timed-out children are reaped. If a startup process is forcibly killed, inspect the PID in the reported startup.lock file and remove it only after confirming that process exited. Disconnecting a client leaves the backend available to other clients. The shared entry points forward tool requests/results and roots; they do not relay progress, log, configuration-change or cancellation notifications. Stdio requests have a three-minute IPC timeout. A client-side timeout does not cancel an already running browser action. Restart this experimental entry point after configuration changes that affect tool schemas. Stop it explicitly using node build/src/bin/chrome-devtools.js stop --sessionId 200-ba5e.

Run npm run profile:low-memory -- /tmp/low-memory-results.json to compare eight shared-stdio clients with eight direct-HTTP clients on the same synthetic workload in separate isolated headless Chrome instances. Add --http-only to measure just the optimized architecture. The report includes Node heap, current and peak RSS, and macOS physical footprint and its lifetime peak (including compressed memory), plus the frontend footprint and combined total. macOS measurements compile a small probe using Xcode Command Line Tools and call proc_pid_rusage. The benchmark does not use forced GC or a V8 heap limit. No production browser or agent configuration is changed by building this fork.

To run every test on a machine with limited RAM, use CHROME_DEVTOOLS_MCP_TEST_SERIAL=true npm run test -- --test-concurrency=1. This runs independent browser integration cases serially; tests that exercise concurrent requests still issue those requests concurrently.

Chrome DevTools for agents (chrome-devtools-mcp) lets your coding agent (such as Antigravity, Claude, Cursor or Copilot) control and inspect a live Chrome browser. It is available as a Model-Context-Protocol (MCP) server and as a CLI. Both give your AI coding assistant access to the full power of Chrome DevTools for reliable automation, in-depth debugging, and performance analysis.

Tool reference | CLI | Skills | Changelog | Contributing | Troubleshooting | Design Principles

Related MCP server: chrome-devtools-mcp

Key features

• Get performance insights: Uses Chrome DevTools to record traces and extract actionable performance insights.

• Advanced browser debugging: Analyze network requests, take screenshots and check browser console messages (with source-mapped stack traces).

• Reliable automation. Uses puppeteer to automate actions in Chrome and automatically wait for action results.

Disclaimers

chrome-devtools-mcp exposes content of the browser instance to the MCP clients allowing them to inspect, debug, and modify any data in the browser or DevTools. Avoid sharing sensitive or personal information that you don't want to share with MCP clients.

chrome-devtools-mcp officially supports Google Chrome and Chrome for Testing only. Other Chromium-based browsers may work, but this is not guaranteed, and you may encounter unexpected behavior. Use at your own discretion. We are committed to providing fixes and support for the latest version of Extended Stable Chrome.

Performance tools may send trace URLs to the Google CrUX API to fetch real-user experience data. This helps provide a holistic performance picture by presenting field data alongside lab data. This data is collected by the Chrome User Experience Report (CrUX). To disable this, run with the --no-performance-crux flag.

Usage statistics

Google collects usage statistics (such as tool invocation success rates, latency, and environment information) to improve the reliability and performance of Chrome DevTools MCP.

Data collection is enabled by default. You can opt-out by passing the --no-usage-statistics flag when starting the server:

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

Google handles this data in accordance with the Google Privacy Policy.

Google's collection of usage statistics for Chrome DevTools MCP is independent from the Chrome browser's usage statistics. Opting out of Chrome metrics does not automatically opt you out of this tool, and vice-versa.

Collection is disabled if CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS or CI env variables are set.

Update checks

By default, the server periodically checks the npm registry for updates and logs a notification when a newer version is available. You can disable these update checks by setting the CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS environment variable.

Requirements

• Node.js LTS version.

• Chrome current stable version or newer.

• npm

Getting started

Add the following config to your MCP client:

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

MCP Client configuration

For setup instructions specific to your editor or agent (e.g. Antigravity, Claude Code, Cursor, VS Code), please see our Client Configurations Guide.

Your first prompt

Enter the following prompt in your MCP Client to check if everything is working:

Check the performance of https://developers.chrome.com

Your MCP client should open the browser and record a performance trace.

CLI

The package also includes the chrome-devtools CLI. Use it to control the browser from your terminal without MCP:

npm i chrome-devtools-mcp@latest -g
chrome-devtools navigate_page 1 --url "https://developers.chrome.com"
chrome-devtools take_screenshot 1 --filePath screenshot.png
chrome-devtools stop

See the CLI guide for all commands and options.

Skills

The package includes skills that teach your agent how to use Chrome DevTools:

Install skills as a plugin

A plugin installs the MCP server and all skills, including the CLI skill:

• Claude Code: Run /plugin marketplace add ChromeDevTools/chrome-devtools-mcp, then /plugin install chrome-devtools-mcp@chrome-devtools-plugins.

• Copilot / VS Code: Run Chat: Install Plugin From Source and enter ChromeDevTools/chrome-devtools-mcp.

• Gemini CLI: Run gemini extensions install --auto-update https://github.com/ChromeDevTools/chrome-devtools-mcp.

See the Client Configurations Guide for more information.

Install skills manually

If your agent does not support plugins, copy the skill folders into the skills directory of your agent. The npm package contains the skills:

npm i chrome-devtools-mcp@latest -g
# Example for Claude Code. Use the skills directory of your agent.
mkdir -p ~/.claude/skills
cp -R "$(npm root -g)/chrome-devtools-mcp/skills/chrome-devtools-cli" ~/.claude/skills/

Keep skills up to date

Skills describe the tools of a specific version. Update the skills each time you update the MCP server or the CLI. Outdated skills can tell your agent to use tools or parameters that changed.

• Plugins: Use the update command of the plugin manager of your agent. The Gemini CLI command above enables automatic updates with --auto-update.

• Manual installs: Update the package, then copy the skill folders again:

npm i chrome-devtools-mcp@latest -g
mkdir -p ~/.claude/skills
cp -R "$(npm root -g)/chrome-devtools-mcp/skills/chrome-devtools-cli" ~/.claude/skills/

Tools

If you run into any issues, checkout our troubleshooting guide. See the full Tool Reference for a complete list of all supported MCP capabilities.

Configuration

Find the complete list of server parameters (e.g., --headless, --isolated, --slim) and how to configure WebSocket connections in the Configuration Guide.

For basic browser tasks only, the --slim flag exposes a reduced set of tools. See the Slim tool reference.

Advanced Usage

For advanced features such as handling concurrent sessions, persistent user data directories, connecting to a running Chrome instance instead of starting a new one, or debugging on Android, see our Advanced Usage Guide.

Integrating as a browser subagent

If you are developing agentic tooling and want to provide an integrated browser subagent as part of your product, we recommend building on top of Chrome DevTools for agents.

For a reference implementation, see the Gemini CLI browser agent documentation.