Chrome DevTools MCP: What Agents Can Do in Chrome (2026)
Vorec Team · 2026-10-07 · About 7 min read
Your coding agent wrote the fix. Did it work in the browser? Reading the code can't tell it whether the console threw an error, a request failed, or the page got slower. Chrome DevTools MCP gives the agent a way to check: it can open a page in Chrome, click through it, read the console and network log, take screenshots and record a performance trace, then report back.
This guide covers what Google's own documentation says the server does, how to set it up, the defaults worth changing before you point it at anything sensitive, and where it fits if what you want at the end is a narrated product demo rather than a passing test.
Checked 7 October 2026 against Google's launch post (23 September 2025), the What's new in DevTools (Chrome 149) post (2 June 2026), and the project's README, tool reference and security policy at commit `ec372b0`. That commit is on the main branch, which can include changes not yet in a published npm release, so treat the tool list as what the documentation describes on that date. The header image is a screenshot of Google's launch post (23 September 2025), captured 7 October 2026; the server was later announced stable in June 2026.
What It Is, in One Paragraph
The README now calls the project Chrome DevTools for agents (`chrome-devtools-mcp`). It is a Model Context Protocol server that "lets your coding agent (such as Antigravity, Claude, Cursor or Copilot) control and inspect a live Chrome browser." Automation runs on Puppeteer; the debugging and performance features come from Chrome DevTools itself. A CLI is also provided for use without MCP. Google launched it as a public preview on 23 September 2025 and said in June 2026 that the MCP server and CLI are now officially stable, while some features remain experimental.
If MCP itself is new to you, start with our Model Context Protocol explainer.
What the Documented Tools Cover
| Area | Tools named in the reference | What that lets an agent do |
|---|---|---|
| Input | `click`, `drag`, `fill`, `fill_form`, `hover`, `press_key`, `type_text`, `handle_dialog`, `upload_file` | Operate a page the way a user would |
| Navigation | `list_pages`, `new_page`, `select_page`, `navigate_page`, `close_page`, `wait_for` | Open, switch and wait on tabs |
| Inspection | `take_snapshot`, `take_screenshot`, `evaluate_script`, `get_css_styles`, console-message tools | See the page and its errors |
| Network | `list_network_requests`, `get_network_request` | Check what the page actually requested |
| Performance | `performance_start_trace`, `performance_stop_trace`, `performance_analyze_insight` | Record a trace and pull out insights |
| Emulation | `emulate`, `resize_page` | Test other viewports and conditions |
| Recording (experimental) | `screencast_start`, `screencast_stop` | Record a video of the target page |
Three of these come with conditions:
- Screencast recording is opt-in. It needs the `--experimentalScreencast=true` flag and FFmpeg installed on the server's PATH.
- Clicking at screen coordinates is opt-in via `--experimentalVision=true`. The normal `click` works on elements from a page snapshot.
- It is not read-only. The README's disclaimer says the server lets clients "inspect, debug, and modify any data in the browser". Clicks, uploads and script execution change real state.
Setting It Up
The README lists the prerequisites: a current Node.js LTS release, Chrome stable or newer, npm, and an MCP client. The baseline client configuration is:
A few details that change how it behaves:
- `@latest` floats. Every start can pull a newer release. Pin a version if you need repeatable runs.
- Chrome launches on demand. Connecting the client does not open a browser; the first tool that needs one does.
- The default profile is persistent. By default the server uses its own profile under `$HOME/.cache/chrome-devtools-mcp/`. Add `--isolated` for a temporary profile that is cleaned up when the browser closes.
- Smaller and headless modes exist. `--slim` exposes a reduced tool set for basic browser tasks, and `--headless` runs without a window.
- Attaching to your own browser is possible, and riskier. With Chrome 144 or later, `--autoConnect` connects to a Chrome you started with remote debugging enabled. Google's advanced-usage doc says the server then "has access to all open windows for the selected profile". Use a separate profile rather than the one you are signed in to everywhere.
Google officially supports Chrome and Chrome for Testing only; other Chromium browsers "may work, but this is not guaranteed."
Defaults Worth Changing
These come straight from the project's README and security policy:
| Default | What it means | How to change it |
|---|---|---|
| Usage statistics on | Google collects tool success rates, latency and environment information, separately from Chrome's own metrics | `--no-usage-statistics` |
| CrUX lookups during performance work | Trace URLs may be sent to Google's Chrome UX Report API | `--no-performance-crux` |
| Persistent profile | Cookies and logins persist between sessions | `--isolated` |
| URL patterns are not a sandbox | `--allowed-url-pattern` / `--blocked-url-pattern` restrict the browser, but the policy says this "is not a complete network sandbox" | Use an OS or VM sandbox |
The security policy also puts the burden of judgment on the agent: it is "the responsibility of the calling agent" to validate tool calls, and page content is returned as-is, so your client should take "precautions against prompt injections." In practice, that means a test profile, test accounts and test data, not your production admin session.
Chrome DevTools MCP vs Playwright MCP
Both let an agent drive a browser over MCP, and both document similar input and navigation tools. Their documentation emphasises different things. Chrome DevTools MCP leans on DevTools: performance traces and insights, network and console inspection, and source-mapped stack traces. Microsoft's Playwright MCP is built on Playwright, works from structured accessibility snapshots, and its README lists Chrome, Firefox, WebKit and Edge as browser options (checked 5 October 2026). If your question is "why is this page slow?", the DevTools tools are the more direct fit; if it is "does this flow work across browsers?", read our Playwright MCP guide. Nothing stops you from installing both.
Where This Fits If You Need a Demo Video
Here is the line between this trend and tutorial production. Chrome DevTools MCP is documented as a tool for verifying and debugging web pages. Its experimental screencast can capture a video of the page. The sources we checked do not describe a workflow for scripting narration, generating a voiceover timed to the actions, or producing a written guide, and that is not what the project says it is for.
So the agent that just tested your checkout flow has done half the work of a product demo: it knows the steps. Turning those steps into something a customer or new hire can watch is a separate job.
That job is what Vorec handles. Vorec records your screen with its own macOS app, and an AI agent can drive that recorder for you through the Claude Code plugin, capturing locally so you review the take before anything is uploaded. It then drafts narration matched to the captured workflow and generates the voiceover, so nothing is spoken into a microphone. Freeze-sync can hold a frame when an explanation needs more time, and you can also generate a written step-by-step guide from the same capture. Paid plans start at $9/month; the 7-day trial needs no credit card and includes 100 credits and up to 3 projects, with watermarked exports.
For more on agents that operate software, see computer-use agents explained, Claude in Chrome and AI agent screen recording.
FAQ
Is Chrome DevTools MCP still in preview? Google launched it as a public preview in September 2025. Its Chrome 149 post (2 June 2026) says the MCP server and CLI are officially stable; individual features, such as screencast and coordinate clicking, are still behind experimental flags.
Which AI tools can use it? Compatible MCP clients. The README names Antigravity, Claude, Cursor and Copilot as examples; check your own client's MCP support.
Can it record video? The pinned documentation includes experimental `screencast_start` and `screencast_stop` tools that record the target page. They require a flag and FFmpeg.
Does it send data to Google? Usage statistics are on by default and can be turned off with `--no-usage-statistics`. Performance tools may send trace URLs to the CrUX API unless you pass `--no-performance-crux`.
Is it safe to use with my logged-in browser? The README warns that it exposes browser content to MCP clients and recommends avoiding sensitive or personal information you don't want to share. A separate or `--isolated` profile is the safer default.
Want the recording to narrate itself? Record with Vorec, or upload one you already have, and get a narrated tutorial plus a written guide. Start free. Trial includes up to 3 projects; exports carry a watermark.