Chrome DevTools MCP

Chrome DevTools MCP is Google's MCP server for letting a coding agent debug and measure web pages in a real Chrome browser. It can navigate and click, record performance traces, read console and network logs, run Lighthouse audits, take screenshots and capture heap snapshots. It is Apache-2.0 and runs with npx -y chrome-devtools-mcp@latest. We checked the README and docs on 31 October 2026.

Quick facts

The server starts Chrome only when the client first uses a tool that needs a browser. Connecting alone does not open one.

What it lets an agent do

Where a browser-automation server clicks through flows, this one gives the agent the same instruments a front-end developer opens DevTools for. The tool reference groups them like this:

Memory tools are behind a flag (--memory-debugging), and coordinate-based tools such as click_at need --experimental-vision.

The README's suggested first prompt shows the intent:

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

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

Skills that ship with it

The package includes agent skills that teach the model how to use the tools:

The README warns that skills describe the tools of a specific version, so update them whenever you update the server or CLI. Outdated skills can tell the agent to use tools or parameters that changed. See our skills guide for where to put them.

Install it in each agent

The standard config:

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

Claude Code

From the project's client guide:

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

Or install the plugin, which brings the server and all the skills:

/plugin marketplace add ChromeDevTools/chrome-devtools-mcp
/plugin install chrome-devtools-mcp@chrome-devtools-plugins

Cursor

Use the install button in the guide, or Cursor Settings, MCP, New MCP Server, with the standard config above.

Codex

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

On Windows the guide suggests wrapping with cmd /c and raising the startup timeout in .codex/config.toml, since npx can be slow to start.

Gemini CLI

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

Or install the extension with automatic updates:

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

To add it at user scope: gemini mcp add -s user chrome-devtools npx chrome-devtools-mcp@latest. The project's README points to Gemini CLI's browser agent as a reference implementation for building a browser subagent.

VS Code and Copilot

code --add-mcp '{"name":"io.github.ChromeDevTools/chrome-devtools-mcp","command":"npx","args":["-y","chrome-devtools-mcp"],"env":{}}'

Or run Chat: Install Plugin From Source and enter ChromeDevTools/chrome-devtools-mcp.

Compatibility at a glance

Configuration worth knowing

The configuration guide lists many parameters. Useful ones:

Advanced usage covers concurrent sessions, persistent user data directories, connecting to an already running Chrome and debugging on Android.

Privacy, data and safety

Read these before you point it at anything private. They come from the project's own README.

• The agent can see and change everything in that browser. The README says the server exposes the content of the browser instance to MCP clients, allowing them to inspect, debug and modify any data in the browser or DevTools. Avoid sharing sensitive or personal information you don't want the client to have.
• Usage statistics are on by default. Google collects tool invocation success rates, latency and environment information. Opt out with --no-usage-statistics. The statistics are independent of Chrome's own, so opting out of one does not opt you out of the other. Collection is off if CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS or CI is set.
• CrUX lookups. Performance tools may send trace URLs to the Chrome User Experience Report API to pull field data. Disable with --no-performance-crux.
• Update checks. The server checks the npm registry for updates and logs a notice. Set CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS to stop it.
• Script evaluation. evaluate_script runs JavaScript in the page. The configuration guide notes that experimental DevTools automation exposes the DevTools UI, including a console that can evaluate JavaScript in the inspected page, and that a "no JavaScript evaluation" flag does not restrict that. Leave experimental flags off.
• Locking down the config. The guide has a section on keeping the configuration file out of an agent's reach.
• Pin a version. @latest runs the newest published package each time.

The same cautions that apply to any browser agent apply here: logged-in sessions are reachable, and web pages can carry instructions aimed at the model. Use a fresh profile (--isolated) for public sites.

Connect to a Chrome you already have open

By default the server launches its own Chrome. The configuration guide also lets it attach to a running one, with --browser-url (for example the remote-debugging address of a Chrome you started) or a WebSocket endpoint. That is useful when you need your logged-in state or a specific profile, and it is the riskiest mode: the agent is now inside a browser that holds your real sessions. Use a separate Chrome profile for it, and keep the debugging port bound to localhost.

The config file, and why the agent should not be able to write it

The server can read a configuration file. The guide lists security-sensitive options that can live in it, such as the Chrome executable path, extra Chrome arguments and the allowed and blocked URL patterns. It then warns that if an agent can create or modify that file, it can change those settings and bypass restrictions, so the file and its parent directory must not be writable by the agent. Some changes apply live (future requests and navigations are restricted), but targets already open on a newly blocked URL stay attached, and options that launch or connect to the browser need a restart.

In practice: put the config somewhere your agent's file tools cannot write, and deny edits to it in your permission rules.

A first session, step by step

1. Check node --version and that Chrome is current.
2. Add the server with the command for your agent.
3. Restart the session and list tools (/mcp in Claude Code and Codex).
4. Run the README's check: ask for the performance of a public page and watch for a trace.
5. Add --no-usage-statistics if you do not want to share statistics.
6. Add --headless --isolated for repeatable runs.
7. Try --slim if the full tool list is too heavy for your context.

A repeatable performance check

A single trace is a snapshot, and one noisy run can send you chasing a problem that is not there. A short protocol makes the agent's findings trustworthy. Use it whenever you ask for a performance review.

1. Fix the conditions. Use --isolated and --headless, the same viewport and the same URL each time, so the browser starts from the same state. Note whether the cache was warm or cold.
2. Take a baseline first. Ask the agent to record the page before you change anything, and to report the numbers it saw for the main loading and layout measures. Save the result in a file next to the code.
3. Ask for causes, not only numbers. A trace shows what blocked rendering, which resources were large and which scripts held the main thread. Ask the agent to name the three biggest contributors and quote the evidence from the trace.
4. Change one thing. Apply a single fix, such as deferring a script or sizing an image.
5. Measure again, under the same conditions, and compare with the baseline.
6. Repeat the measurement three times before you believe a small difference. Page timing varies from run to run.

A prompt that follows this protocol:

Record a performance trace of http://localhost:3000/ with a cold cache and
report the main loading and layout metrics. Name the three biggest causes of
delay with evidence from the trace. Do not change any code yet. Save the
numbers to perf-baseline.md.

Then, after your fix:

Record the same trace again under the same conditions, compare with
perf-baseline.md, and say whether the change helped. If the difference is
small, run it twice more before you conclude anything.

The last sentence matters. Without it, models tend to report a small change as an improvement. Lab measurements also differ from what real users see, so treat the trace as a way to find causes and use field data, which the server can pull from the CrUX service unless you disable it, to judge the result.

Debugging a broken page, in order

When the problem is a bug, not speed, a fixed order saves tokens.

Do not let the agent edit before step 4. A model that sees an error will often guess a fix from the message alone, and a guess that happens to silence the error can leave the real fault in place.

Keeping screenshots and traces from filling your context

Traces and screenshots are the biggest items an agent can pull into a session. The configuration options above help: --screenshot-format and --screenshot-max-width shrink images, and --slim trims the tool list. Beyond those:

• Ask for a summary of a trace, not the raw data, and say how many items you want.
• Ask for one element's screenshot instead of the full page where you can.
• Start a fresh session after a long investigation, with the findings pasted in from your notes file.
• Use --log-file only while debugging the server itself, since logs can contain page content.

When the agent and the browser disagree

Some failures are not the page's fault. A site may behave differently in a headless, isolated browser than in your daily one, because of missing extensions, no login, a different locale or a blocked cookie. If the agent reports something you cannot reproduce, check three things before assuming it is wrong: the profile (isolated or yours), the viewport and the Chrome channel. A page that serves a consent banner to new visitors will look different to a clean profile every time, which is correct behaviour and worth knowing before you file a bug.

Real tasks with copy-ready prompts

Performance check

Open https://localhost:3000, record a performance trace of the page
load, and summarise the three biggest issues with the Largest
Contentful Paint. Use the insight tools for details.

Console and network triage

Load /checkout, then list console errors and any failed network
requests. For the first failed request show the status and headers.

Accessibility pass

Run a Lighthouse audit on /pricing, report the accessibility score and
list each failing audit with the element it applies to.

Responsive check

Emulate a phone viewport and a slow network, reload the homepage and
take a screenshot. Tell me what overflows.

Memory leak

Take a heap snapshot, open and close the modal 20 times, take another,
and compare them. Report object classes that grew the most.

For a flow-level QA pass, add Playwright MCP. Our browser QA recipe combines them.

Limits and known issues

• Chrome only, officially. Other Chromium browsers may work; Firefox and Safari are out.
• Node and Chrome versions. You need a current LTS Node and a current stable Chrome. The README says Google commits to fixes for the latest Extended Stable Chrome.
• Startup time. npx can be slow on first run, especially on Windows. The guide shows a longer startup timeout.
• Context cost. The full tool set is large, and screenshots add up. Use --slim and the screenshot-size options.
• Skills drift. Skills are version-specific.
• Fast release cadence. v1.12.0 was published on 22 October 2026. Expect changes.
• Telemetry by default. Opt-out, not opt-in.

Alternatives

Which agents it works best with

All five covered here have a documented route. Claude Code and Gemini CLI add a plugin or extension that carries the skills, which makes the tools easier for the model to use well. The project also points to Gemini CLI's browser agent as the reference for embedding a browser subagent in a product.

Our take

We did not run this server for this page; the notes are from the README and docs.

Pick it when the question is "why is this page slow or broken in Chrome". Traces, Lighthouse, heap snapshots and network detail are what a developer would open DevTools for, and giving an agent those tools closes the loop on performance work in a way that screenshots cannot.

Pick Playwright MCP when the question is "does this flow work". They overlap on clicking and screenshots. Many front-end setups run both.

The privacy defaults are the thing to read twice. Usage statistics on by default and CrUX lookups are documented, easy to switch off, and still worth deciding on purpose before you point it at an internal tool.

Frequently asked questions

What does Chrome DevTools MCP do? It lets an agent control and inspect a live Chrome.

How do I install it? npx -y chrome-devtools-mcp@latest as a stdio server.

Does it collect data? Yes by default; opt out with the flags above.

Which browsers does it support? Chrome and Chrome for Testing officially.

How is it different from Playwright MCP? DevTools-level debugging and performance vs cross-browser flows.

*Product names are used descriptively. We are not affiliated with Google.*