Chrome DevTools MCP Server: What It Is, Setup, Tools and Flags (2026)

The project lives at github.com/ChromeDevTools/chrome-devtools-mcp under the Apache-2.0 license, and its README now calls it "Chrome DevTools for agents". It ships two front ends from one npm package: an MCP server that any MCP client can start, and a chrome-devtools command-line tool for driving the same browser from a shell without MCP. Both use Puppeteer to automate Chrome and wait for the result of each action, and both use the DevTools front end to record traces and turn them into performance insights.

Three things set it apart from a generic browser-automation server. First, it is DevTools, not just a remote control: console messages arrive with source-mapped stack traces, network requests can be listed and opened one by one, and performance_start_trace / performance_analyze_insight produce the same insights you see in the Performance panel. Second, the default way an agent reads a page is take_snapshot, a text dump of the accessibility tree where every element has a uid the agent can pass to click, fill or hover; the docs tell agents to prefer a snapshot over a screenshot. Third, it is maintained by the Chrome DevTools team, which officially supports Google Chrome and Chrome for Testing only; other Chromium browsers may work but are not guaranteed.

How a session starts. Connecting the MCP client does not open a browser. The server launches Chrome the first time the agent calls a tool that needs one. By default it uses the stable channel and a persistent profile at $HOME/.cache/chrome-devtools-mcp/chrome-profile (Linux and macOS), which is reused between runs; --isolated swaps that for a temporary profile deleted when the browser closes.

Release cadence. The GitHub releases page shows v1.11.0, v1.12.0 and v1.13.0 within about four weeks, and the npm registry reported 2,405,354 downloads in the most recent week we checked. Because most configs use chrome-devtools-mcp@latest, your agent picks up new tools on its next start; pin a version in args if you need a stable tool list for CI.

Every client uses the same standard entry: command npx, args -y and chrome-devtools-mcp@latest. The project's client configuration guide lists 27 clients. The commands below are copied from that guide; the --scope user and -s user variants make the server available in every project instead of only the current one.

Plugin or plain MCP? The plugin route installs the server plus seven skills (chrome-devtools, chrome-devtools-cli, a11y-debugging, cookie-debugging, debug-optimize-lcp, memory-leak-debugging, troubleshooting) that teach the agent how to use the tools. The README warns that skills describe the tools of one version, so update them whenever you update the server. If you previously added the server by hand in Claude Code, the guide says to remove that entry before installing the plugin.

Requirements. A current Node.js LTS with npm, and Chrome stable or newer. On Windows 11 the guide's Codex example sets SystemRoot and PROGRAMFILES in env and raises startup_timeout_ms to 20,000 in .codex/config.toml, because the first npx download can be slow.

Check it works. The README's first prompt is: check the performance of https://developers.chrome.com. The client should open Chrome and record a performance trace. If nothing happens, run npx chrome-devtools-mcp@latest --help in a terminal to confirm Node can fetch and start the package, then see the project's troubleshooting guide.

The auto-generated Tool Reference for v1.13.0 lists 63 tools in 13 categories. Seven categories are on by default. We read the package source for v1.13.0 to see which tools carry an extra condition: click_at needs --experimentalVision, and 13 of the 14 memory tools (everything except take_heapsnapshot) need --memoryDebugging. That leaves 33 tools on a default start.

The debugging tools do most of the work. lighthouse_audit returns Lighthouse scores and the DOM nodes behind failing audits for accessibility, SEO, best practices and agentic browsing (not performance; the docs point to the trace tools for that). set_logpoints adds DevTools-style logpoints that log an expression each time a line runs without pausing the page, resolved through source maps. get_css_styles returns the matched CSS rules for an element, ordered by cascade precedence, with overridden declarations marked. screencast_start and screencast_stop record the page to an .mp4.

Turning categories on and off. Each category has a boolean flag, for example --categoryNetworkMocks=true or --categoryEmulation=false. Fewer tools means a shorter tool list in the model's context, which is the reasoning behind --slim: it replaces everything with three tools (navigate, evaluate, screenshot) for basic browsing tasks.

All flags go in the args array after the package name, or in a JSON config file (--config, or ~/.config/cd4a/config.json on macOS and Linux) using camelCase keys. Flags on the command line override the file. These are the ones that change behavior most, with wording taken from the configuration guide:

Attaching to your own Chrome. --browser-url=http://127.0.0.1:9222 connects to a Chrome you launched with --remote-debugging-port=9222 and a non-default --user-data-dir, which Chrome itself requires for the debugging port. The advanced-usage guide warns that any application on your machine can connect to that port and control the browser, so do not browse sensitive sites while it is open. --autoConnect is the gentler route on Chrome 144 and later: Chrome shows a permission dialog, and the server gets all open windows of the default profile.

Several agents at once. Most clients start one server per conversation. If you run several independent sessions, pass --isolated so they do not fight over the shared default profile, which only one browser can use at a time. When one server is shared across sessions, page-ID routing (on by default) adds a pageId to page-scoped tools so each session works in its own tab.

Everything in the browser is visible to the agent. The README's first disclaimer says the server exposes the browser's content to MCP clients and lets them inspect, debug and modify any data in the browser or DevTools. If the agent's profile is logged in to your email or a production admin panel, the model can read those pages too. The simplest guard is --isolated for routine QA, plus --allowed-url-pattern so the browser can only load your staging host.

Two kinds of data go to Google by default. Usage statistics (tool success rates, latency, environment information) are collected unless you pass --no-usage-statistics or set CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS or CI in the environment. Separately, the performance tools may send trace URLs to the Chrome UX Report (CrUX) API to fetch field data; --no-performance-crux turns that off. Staging URLs you trace are worth keeping out of that lookup. The server also checks npm for updates periodically; CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS disables it.

JavaScript evaluation is on. evaluate_script runs whatever function the model writes inside the page. --javascriptEvaluation=false disables that tool, set_logpoints and the initScript parameter, but the docs are explicit that this is not a sandbox: clicks and typing still run page scripts. File access is limited by default: when the client does not negotiate MCP roots, tools that read or write local files are confined to the OS temp directory unless you pass --allowUnrestrictedPaths.

Lock the config file. The configuration guide warns that a config file can set executablePath, chromeArg and the URL allow and block lists, so an agent that can write to the config location can loosen those restrictions. Keep the file and its directory read-only for the agent.

This is the sequence of tool calls a QA prompt produces, using the tool names and parameters from the Tool Reference. The target is the README's own test page, https://developers.chrome.com, so you can repeat it without touching a site you own. The prompt: open the page on a mobile viewport, check the console for errors, list failed network requests, run a Lighthouse accessibility audit and record a performance trace, then report.

Step 1, open and emulate. The agent calls new_page with the URL, then emulate with a mobile viewport (or uses lighthouse_audit with device: "mobile" later). new_page returns a page ID that every later call passes as pageId.

Step 2, read the page. take_snapshot returns the accessibility tree as text with a uid per element. This is what the agent reasons over; it is much smaller than a screenshot and gives the agent stable handles for click and fill.

Step 3, console and network. list_console_messages (optionally with types to keep only errors and includeStackTraces: true) and list_network_requests show what broke. get_network_request opens a single request with headers and body, which is where CORS and 4xx problems become obvious.

Step 4, audits. lighthouse_audit with mode: "navigation" reloads and audits accessibility, SEO and best practices, saving the full report to disk. For speed, performance_start_trace with a reload, then performance_stop_trace and performance_analyze_insight on the insight it names, such as an LCP breakdown.

Step 5, prove the fix. After the agent edits code on your local build, it reloads with navigate_page, repeats the snapshot and the console check, and takes a take_screenshot with fullPage: true as evidence for the pull request. This verify step is the use case the Chrome team led with in its launch post: the agent can confirm in the browser that its change works.

We searched X with our own API for posts about the server, collected in 2026: the Latest stream for "chrome devtools mcp" OR "chrome-devtools-mcp" OR "devtools mcp" (with four 10-day date windows to reach further back), the Top results for the same query, and posts linking the package (url:chrome-devtools-mcp). After removing duplicates that gave 651 posts from 517 distinct accounts. 57.5% link the repository or npm package, so most of this is people sharing the tool, not just name-dropping it.

Claude leads by a wide margin. 24.4% of posts name Claude or Claude Code, more than Codex, Cursor and Copilot combined. 31.2% name at least one client and 9.8% name two or more, often in "works in Claude Code and Cursor" setup posts. Playwright, the other browser tool agents commonly use, comes up in 13.1% of posts.

Debugging is the most common topic, visual work draws the most likes. Console and error talk appears in 21.7% of posts and forms, clicks and testing in 20.1%, but posts about DOM, CSS and layout have a median of 21 likes and screenshot posts 18, against 6 for the whole sample.

People save these posts more than they like them. Across the sample, bookmarks outnumber likes by 1.28 to 1 (85,211 bookmarks vs 66,572 likes), and 23.2% of posts have more bookmarks than likes. That pattern fits reference material: setup threads and prompt recipes people plan to come back to.

Attention is concentrated. The 10 most-liked posts hold 38.4% of all likes, and the official @ChromiumDev account (Chrome for Developers) is the most-liked author in the sample with 15 posts and 11.9% of all likes. English is 59.0% of posts, Japanese 16.0% and Chinese 13.2%.

Weekly volume. The Latest searches returned 142 posts in the most recent week, 62 the week before, and between 22 and 33 a week for the five weeks before that. The newest week includes the v1.13.0 release. Treat the slope with care: older date windows returned fewer posts, and part of that drop can be search coverage of older posts rather than falling interest.

Launch interest still dominates the Top results. Of the 158 posts X ranks as Top for the query, 42 (26.6%) were posted in the first four weeks after the September 23, 2025 public preview, and 58 (36.7%) in the last seven weeks of our window. The tool is past its launch moment and into steady everyday use.

Chrome DevTools MCP gives an agent a browser; it is not a data source. Agents that need posts from X (Twitter), for a social-proof widget you are testing, a dashboard that shows mentions, or research before a launch, should not scrape x.com through the browser: the logged-in session in your profile would be doing the reading. A data API returns structured JSON with no X account needed.

Two routes. Add our hosted MCP server next to Chrome DevTools MCP, so the agent has both: in Claude Code that is claude mcp add --transport http --scope user twitterapi-io https://mcp.twitterapi.io/mcp --header "Authorization: Bearer your_key_here", which exposes 12 tools for X data such as search_tweets, get_user_last_tweets and get_tweet_replies. Or call the REST API directly from code, as the script in this page does with /twitter/tweet/advanced_search.

What it costs, compared with X's own API. On TwitterAPI.io tweet endpoints cost $0.15 per 1,000 tweets returned; a call that finds nothing is billed the 15-credit minimum, $0.00015. X's official pay-per-usage rate card at docs.x.com/x-api/getting-started/pricing charges $0.005 per post read, which is $5 per 1,000 posts, about 33x more per 1,000 tweets. The study on this page used 64 requests and returned 970 tweets, roughly $0.15. New accounts that pass the automatic bot check get up to $1 of free credits (at most 100,000 credits, no card, one per person or network, expiring after 31 days); purchased credits never expire. Rate limits start at 0.2 requests per second before the first payment and rise to 20 once paid.

Question. What do developers on X do with Chrome DevTools MCP, and which coding agents do they pair it with?

Query and window. /twitter/tweet/advanced_search with "chrome devtools mcp" OR "chrome-devtools-mcp" OR "devtools mcp" (Latest, plus four 10-day windows reaching back about seven weeks, and Top) and url:chrome-devtools-mcp (Latest). Collected in 2026. 64 requests, 970 tweets returned, 651 distinct posts from 517 accounts. We planned about 1,000 posts; this is everything the searches returned.

Method. Client and theme shares are case-insensitive keyword matches on post text (the regular expressions are in the study script), so a post can count under several labels and a post that says only "Claude" counts toward Claude / Claude Code. Weekly volume uses the Latest results only.

What the sample cannot show. Search returns fewer posts for older windows, so the weekly trend mixes real interest with coverage. Mentions are not usage: most users never post about their tools, and posts in Japanese or Chinese can name a client in a form our patterns miss. Likes and bookmarks measure attention, not quality.

Privacy. Aggregates only. Raw search pages were not kept in the repository because most authors are private individuals; the published sample has no IDs, URLs, text or handles. The only account named is the official @ChromiumDev organization account.