Chrome DevTools MCP

Give coding agents direct Chrome automation, debugging, and performance-analysis capabilities.

Stars
★ 54k
Last updated
today
License
Apache-2.0
Primary language
TypeScript

At a glance

How it runs
MCP serverCLI
Works with
Universal · cross-platformCodex · Claude Code
Cost
Free, no paid service needed
Setup effort
Low · running in minutes
You'll need
Node.js LTSnpmGoogle Chrome current stable or newer, or Chrome for TestingShell / CLINetwork accessLocal filesystemMCP Server
Typical use
A frontend developer asks a coding agent to reproduce an interaction and correlate console errors with source-mapped stack traces.
Not a fit if
  • Teams that need fully offline operation: performance traces may send URLs to Google's CrUX API
  • Teams standardized on non-Chrome Chromium browsers: only Google Chrome and Chrome for Testing are officially supported
  • Users with personal accounts or sensitive pages open: the MCP client can read and modify browser data

What does this agent do, and when should you use it?

Chrome DevTools MCP is an MCP server for coding agents, accompanied by a CLI for workflows that do not use MCP. It drives Chrome through Puppeteer and uses Chrome DevTools to collect performance traces, inspect network traffic and console output, examine page state, and analyze heap snapshots. Agents can navigate pages, complete forms, execute scripts, capture screenshots, emulate environments, and return diagnostic evidence to their client. The server can launch a dedicated Chrome profile or connect to an existing browser through automatic discovery, a remote-debugging URL, or a WebSocket endpoint. It suits development and testing workflows that need real-browser evidence, but it exposes browser contents to the MCP client and officially supports only Google Chrome and Chrome for Testing.

An MCP client starts chrome-devtools-mcp, which launches Chrome when a browser-dependent tool is first invoked or connects to an existing instance with --autoConnect, --browser-url, or --wsEndpoint. The agent operates pages with tools such as navigate_page, click, fill_form, press_key, and upload_file, runs page code through evaluate_script, and reads state through take_snapshot, take_screenshot, console, and network-request tools. A performance workflow combines performance_start_trace, performance_stop_trace, and performance_analyze_insight; memory tools capture, compare, and inspect heap snapshots. Configuration can additionally expose Lighthouse, extension, PWA, WebMCP, third-party developer-tool, and screencast functions, although several are experimental or require extra dependencies. Results are returned to the MCP client, while the included CLI provides a non-MCP interface.

  1. A frontend developer asks a coding agent to reproduce an interaction and correlate console errors with source-mapped stack traces.
  2. A performance engineer records a Chrome trace for a target site and extracts actionable insights, optionally supplemented with CrUX field data.
  3. A test engineer automates navigation, clicks, form entry, uploads, and screenshots in a real Chrome session to validate a critical user journey.
  4. A web developer inspects request listings and individual network requests while diagnosing API failures or resource-loading problems.
  5. An engineer investigating memory growth enables the experimental memory tools to compare heap snapshots and inspect dominators, retainers, and duplicate strings.
  6. A team running its coding agent in a sandbox connects the MCP server to Chrome on the host through a debugging port or WebSocket endpoint.

How do you install or deploy this agent?

Install an LTS release of Node.js, npm, and the current stable or newer Google Chrome; Chrome for Testing is also officially supported. Add this configuration to an MCP client:

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

Codex can register the server directly:

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

For Claude Code, install it at user scope:

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

For basic navigation, script execution, and screenshots only, enable slim headless mode:

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

The basic setup does not document any required API credentials. Authenticated sites still require suitable browser login state, and an authenticated WebSocket connection can receive custom headers through --wsHeaders.

How do you use this agent?

Start the configured MCP client and submit the documented first test prompt:

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

The server starts Chrome only after the client invokes a tool that needs it, then records the performance trace. To connect to an already running browser, configure the debugging URL:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest",
        "--browser-url=http://127.0.0.1:9222"
      ]
    }
  }
}

Then launch Chrome with remote debugging and a non-default profile; for Linux:

/usr/bin/google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-profile-stable

When multiple agents share one server, add --experimentalPageIdRouting so page-scoped calls can target a pageId. For separate sessions that should not share the default Chrome profile directory, also use --isolated.

What are this agent's strengths and limitations?

Pros
  • Its catalog spans automation, network traffic, console diagnostics, performance traces, Lighthouse, and memory analysis, supporting deeper debugging than a click-and-screenshot interface.
  • It can launch a dedicated Chrome instance or attach through automatic connection, a debugging URL, or WebSocket, covering both local and sandboxed deployments.
  • The MCP interface is documented for Codex, Claude Code, Cursor, VS Code, Gemini CLI, and numerous other clients, while a separate CLI supports non-MCP use.
  • --slim, category switches, and screenshot compression and sizing controls can reduce tool exposure and conversation-context consumption.
Limitations
  • Only Google Chrome and Chrome for Testing are officially supported; other Chromium-based browsers may behave unexpectedly.
  • The MCP client can inspect, debug, and modify browser data, creating a material exposure risk when personal accounts or sensitive pages are open.
  • Usage statistics and update checks are enabled by default, and performance analysis may send trace URLs to the Google CrUX API unless separately disabled.
  • Memory analysis, page-ID routing, coordinate-based actions, screencasting, and WebMCP include optional or experimental features; screencasting additionally requires ffmpeg.
  • A remote-debugging port lets local applications control the browser, and Chrome requires a non-default user-data directory for that mode.

How does this agent compare with similar options?

Full mode exposes automation, debugging, network, performance, memory, and optional tool categories; --slim exposes only three tools for navigation, script execution, and screenshots, making it better suited to basic tasks and smaller contexts. The default deployment launches Chrome with a dedicated profile, while --autoConnect is intended for sharing manual browsing state on Chrome 144 or later and --browser-url or --wsEndpoint suits connections from a sandbox to an external browser. The MCP server targets coding-agent integration, whereas the accompanying CLI supports operation without MCP.

Key facts side by side with the most closely related agents.

Agent Source review Form / cost Stars Updated Language Full support on
Chrome DevTools MCP This agent 79 · Some gaps MCP serverFree ★ 54k today TypeScript Codex · Claude Code
bdg Browser Debugger 68 · Some gaps CLIFree ★ 177 today TypeScript Codex · Claude Code
OpenTabs 49 · Major gaps CLIFree + model costs ★ 988 2mo ago TypeScript Claude Code
Steel Browser 29 · Major gaps Self-hosted serviceFreemium ★ 7.8k 5d ago TypeScript —

How does FollowAgents rate this agent?

FollowAgents source review · FARS-2.1
Some gaps
Why not a higher tier: Trust & safety is 17/29, below the 18/29 needed for “Good”; the tier is lowered because risk is not averaged away.
79/ 100 5-point scale 4.0 / 5
This review covers the source as of Aug 14, 2026. The project has shipped 5 stable release(s) since, which have not been re-reviewed. The score and verdict describe the reviewed version only. Recent releases ↓
Trust 17/29
Reliability 11/14
Adaptability 16/18
Convention 16/18
Effectiveness 12/13
Verifiability 7/8
Why each dimension lost points
Trust17 / 29 · 2.9/5

The evidence shows MCP roots, path validation, symlink-write defenses, and optional URL allow/block rules, with tests covering several boundaries. Least privilege is not complete because the OS temporary directory remains accessible, the network controls are explicitly not a full sandbox, and browser-control authority is broad. The server assigns validation of tool calls and parameters to the client and shows no built-in per-action user confirmation, so confirmation scores zero. The README thoroughly discloses browser-content exposure, default-on usage statistics, CrUX requests, update checks, and opt-outs, justifying full data-flow transparency. Sensitive-data handling includes warnings and opt-outs, but telemetry is enabled by default, browser data is exposed to clients, WebSocket headers may contain credentials, and no secret-redaction mechanism is shown. Dependency pins, script restrictions, commit-pinned Actions, and prerelease verification provide meaningful supply-chain controls; deductions remain because several dependencies use ranges and no vulnerability scanning or known-vulnerability response evidence is supplied. File writes, extension installation, navigation, and browser modifications are documented external effects, but there is no uniform confirmation gate. Isolation and selected close/uninstall operations offer limited recovery, not general rollback for page or filesystem changes. Repository, author, and licensing attribution are explicit, but registry verification is absent and the supplied files cannot independently establish publisher identity.

Reliability11 / 14 · 3.9/5

The README, configuration, package metadata, and tests are strongly consistent about page identifiers, reconnection, snapshots, structured output, timeout adjustment, and resource access, supporting full self-consistency. Node, Chrome, and npm requirements are clear and important runtime dependencies are pinned, but recommended @latest installation can drift, official browser support is narrow, and no offline or downgrade path is documented. Tests demonstrate explicit errors plus reconnect and fallback notices, and the README links troubleshooting material; however, the supplied excerpts do not show systematic error categories, remedies, and diagnostic context for every tool, so failure messaging is not full-score.

Adaptability16 / 18 · 4.4/5

Documentation covers coding agents, a non-MCP CLI, slim basic-browser operation, debugging, performance, network, memory, extensions, and many client configurations, thoroughly addressing audiences and scenarios. Supported browsers, filesystem roots, temporary-directory access, incomplete network guardrails, prompt-injection exposure, and caller responsibilities are stated clearly, earning full capability-boundary credit. Tools are triggered through explicit MCP calls with structured parameters, but the server does not validate agent intent or require confirmation, leaving safety precision dependent on the client. Node and Chrome requirements, a Windows-specific configuration, numerous IDE and CLI integrations, headless operation, browser connection modes, profile paths, and isolation provide strong environment fit.

Convention16 / 18 · 4.4/5

The README organizes tool reference, CLI, changelog, contribution, troubleshooting, design principles, and generated tool/option indexes well. Installation notes are unusually extensive, covering prerequisites, platforms, clients, and a first verification prompt. Package and MCP names are explicit and option aliases are maintained, but widespread @latest use and inconsistent omission of @latest in some examples reduce naming/version stability. Examples are plentiful, although a complete FAQ is not present in the supplied material. Browser support, telemetry, content exposure, prompt injection, roots, and network-sandbox limitations are documented thoroughly. Apache-2.0 metadata matches the full license text. Package versioning, a changelog link, conventional-commit enforcement, and prerelease checks show a clear update path. SECURITY reporting, an issue tracker, and the Google LLC author field provide maintenance channels, but registry provenance is unverified and no named maintainers or support commitment are supplied.

Effectiveness12 / 13 · 4.6/5

The product supplies text, images, and optional structured results, while tests cover stable element identifiers, page state, network details, file paths, and snapshot formatting; this strongly supports output usability. Combining DevTools, Puppeteer, performance insights, network, memory, extension, and PWA operations behind MCP and CLI offers clear marginal value beyond basic web automation. Slim and headless modes plus telemetry and CrUX opt-outs mitigate cost, but full operation has a large tool surface, requires launching or attaching to Chrome, and may impose performance, privacy, token, and maintenance costs. No quantitative benchmark is supplied, so cost-benefit is not full-score.

Verifiability7 / 8 · 4.4/5

Core capability, risk, and configuration claims trace to concrete README, SECURITY, package, workflow, and test evidence, supporting full claim traceability. Version, license, tool behavior, path restrictions, structured output, and release checks are corroborated across multiple supplied sources. The documentation generally distinguishes official support, possible compatibility, incomplete sandboxing, and client responsibility; however, promotional claims such as reliable automation and full DevTools power lack benchmarks or comprehensive support in the supplied evidence, so fact/inference separation is not complete.

Risks and how to mitigate them
  • Not found in source: confirmation before actingTurn on (or add) a confirmation step before it acts, and try it in a sandbox or test environment before real data.
  • Usage statistics are enabled by default and are independent of Chrome telemetry settings; use --no-usage-statistics or the documented environment variable when tool-success, latency, or environment data must not be sent.
  • MCP clients can inspect, debug, and modify browser data. Do not retain personal information, sessions, or credentials in connected profiles or pages unless disclosure to the agent client is acceptable.
  • MCP roots and URL allow/block patterns are not complete system sandboxes, and the temporary directory remains accessible. High-risk use should add OS- or VM-level filesystem and network isolation.
  • Web content is returned as-is and may contain prompt injection. Clients should treat page text as untrusted and require confirmation before file writes, extension installation, downloads, or other consequential effects.
  • Recommended configurations use chrome-devtools-mcp@latest, which does not preserve the reviewed revision or behavior across upgrades. Controlled deployments should pin an exact reviewed version.
  • This assessment is based only on the supplied static files. Code, tests, dependency vulnerabilities, and network behavior were not executed or independently verified, and publisher identity remains unknown to the specified enterprise registry.
Evidence confidence: Low Reviewed Aug 14, 2026 Reviewed revision f9767805f911 New commits since this review; the score may not cover them
See the full review method →

Recent releases

Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.

  1. chrome-devtools-mcp-v1.11.0 chrome-devtools-mcp: v1.11.0
    Release notes excerpt
    [1.11.0](https://github.com/ChromeDevTools/chrome-devtools-mcp/compare/chrome-devtools-mcp-v1.10.1...chrome-devtools-mcp-v1.11.0) (2026-10-15) 🎉 Features * add --file-navigations flag to reject file: URL navigations ([#2853](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2853)) ([54cae57](https://github.com/ChromeDevTools/chrome-devtools-mcp/commit/54cae57bcfae752f80cab2f02fd802c3bcb740ec)) …
    View on GitHub ↗
  2. chrome-devtools-mcp-v1.10.1 chrome-devtools-mcp: v1.10.1
    Release notes excerpt
    [1.10.1](https://github.com/ChromeDevTools/chrome-devtools-mcp/compare/chrome-devtools-mcp-v1.10.0...chrome-devtools-mcp-v1.10.1) (2026-09-23) 🛠️ Fixes * build: resolve node export conditions in rollup bundle ([#2814](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2814)) ([d7c9b55](https://github.com/ChromeDevTools/chrome-devtools-mcp/commit/d7c9b55490d0be66f1d8c77711aaf6854af8ceb7))
    View on GitHub ↗
  3. chrome-devtools-mcp-v1.10.0 chrome-devtools-mcp: v1.10.0
    Release notes excerpt
    [1.10.0](https://github.com/ChromeDevTools/chrome-devtools-mcp/compare/chrome-devtools-mcp-v1.9.0...chrome-devtools-mcp-v1.10.0) (2026-09-23) 🎉 Features * add css formatter class ([#2707](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2707)) ([f0b5fa4](https://github.com/ChromeDevTools/chrome-devtools-mcp/commit/f0b5fa4bde0afa30c53996ec0f987af6b6ab28ac)) * add get_css_style tool ([#2612](https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/2612)) ([4454ae0](https://github.com/ChromeDevTools/chrome-devtools-mcp/commit/4454ae0a8a3d6072ea52d8931a9562907e8dbaae)) …
    View on GitHub ↗

FAQ

Does it require a paid API or access token?
No API key is documented for the basic launch command. Target sites may still require their own authenticated browser session, and protected WebSocket endpoints can receive authentication headers through --wsHeaders.
Can it see sensitive information in my browser?
Yes. MCP clients can inspect, debug, and modify data in the connected browser and DevTools, so the controlled instance should not contain personal or sensitive material you do not intend to expose.
How do I disable telemetry and CrUX requests?
Start the server with --no-usage-statistics and --no-performance-crux. Setting CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS or CI also disables usage-statistics collection.
Can it reuse my everyday Chrome profile?
--autoConnect can attach to a Chrome 144+ instance with remote debugging enabled, but the server gains access to all open windows in the selected profile. The debugging-port method requires a non-default user-data directory rather than the regular profile.
How are concurrent agents kept on the correct tab?
For agents sharing one server instance, the experimental --experimentalPageIdRouting option adds pageId routing to page-scoped tools. Independent sessions can also use --isolated to receive separate temporary Chrome profiles.
View on GitHub ↗ Install ↓

Compare agents like this one

The same FARS review applied across the shortlist this agent qualifies for.

Related agents