Chrome DevTools MCP: Let Your Coding Agent Debug a Live Chrome Browser

If you let a coding agent write front-end code, the next question is how it checks that the page actually works. Chrome DevTools for agents, published as the chrome-devtools-mcp repo, is the Chrome team's answer: a Model Context Protocol server and a CLI that let an agent control and inspect a live Chrome browser. The repo was trending on GitHub again in the week of November 9, 2026, and the repository page now shows about 55,200 stars, 4,600 forks and an Apache-2.0 license.

This guide covers what the tool does, how to install it in Claude Code, Codex and other agents, which skills it bundles, what Google collects by default, and where it fits next to the other browser tools we have covered.

TL;DR

What does Chrome DevTools MCP actually do?

A trace thread under a magnifying lens, showing how Chrome DevTools MCP records agent performance traces

The README describes three headline capabilities. First, performance insights: the server uses Chrome DevTools to record traces and extract actionable findings, so an agent can answer "why is this page slow?" with data rather than a guess. Second, advanced browser debugging: the agent can analyze network requests, take screenshots and read console messages, with source-mapped stack traces so an error points at your TypeScript and not at the minified bundle. Third, reliable automation: it uses Puppeteer and waits for the results of each action before moving on.

The official Chrome for Developers page frames the goal this way: help your agent "build, debug, and verify your code correctly" by interacting with a real Chrome instance. It lists three use cases:

• Emulate user experiences. Test responsive layouts, different geolocations and real user flows. The docs' sample prompt asks the agent to simulate a location in Berlin and check whether a store locator shows a specific branch.
• Debug your live browser. Connect to your active Chrome session to inspect, pause and troubleshoot in real time.
• Proactive QA with Lighthouse. Run audits for accessibility, SEO and performance, and get a checklist before you push.

The first prompt the README suggests is deliberately simple: "Check the performance of https://developers.chrome.com". If your client opens a browser and records a trace, the setup works.

How do you install it?

The universal config for any MCP client is a single server entry:

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

Using @latest means your client always starts the newest version. The server launches Chrome on demand, the first time the agent calls a tool that needs a browser. Connecting to the server alone does not open a window.

For specific agents, the Chrome docs and the README give shortcuts:

The plugin routes install the MCP server and all bundled skills in one step. That matters, because the skills are what teach the agent how to use the tools well. If you already use Claude Code plugins and commands, the marketplace route is the shortest path.

What are the bundled skills?

The package includes seven agent skills. Skills are folders of instructions the agent loads when a task matches, which we explain in our agent skills guide.

One detail from the README is easy to miss: skills describe the tools of a specific version. The maintainers warn that outdated skills can tell your agent to use tools or parameters that have changed, so you should update the skills each time you update the server or CLI. Plugin managers handle this for you. If you copied the skill folders by hand into your agent's skills directory, you must copy them again after every update.

Can you use it without MCP?

Yes. The package also installs a chrome-devtools command-line tool, so you or a script can drive the browser from a terminal:

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

That is useful for batch jobs, CI checks, and for agents that handle shell commands better than long MCP tool lists. It connects to a theme we have followed in other posts: MCP tool definitions cost tokens on every turn. The README offers a --slim flag that exposes a reduced tool set for basic browser tasks. If you care about context cost, our post on reducing Claude Code token overhead with an artifact and Chrome MCP shows why trimming the tool surface pays off.

What does Google collect by default?

This is the part to read before you roll the server out to a team. The README lists three behaviors that are on unless you change them:

1. Usage statistics. Google collects data such as tool invocation success rates, latency and environment information to improve reliability. Collection is enabled by default. Pass --no-usage-statistics in the server args to opt out. It is also disabled when the CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS or CI environment variables are set. The README says this is independent from Chrome's own usage statistics, so opting out of one does not opt you out of the other.
2. CrUX lookups. Performance tools may send trace URLs to the Chrome UX Report API to fetch real-user experience data, so the agent sees field data next to lab data. Use --no-performance-crux to stop that.
3. Update checks. The server periodically checks the npm registry for a newer version. Set CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS to disable it.

A privacy-conscious config looks like this:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--no-usage-statistics",
        "--no-performance-crux",
        "--isolated"
      ]
    }
  }
}

The --isolated flag appears in the README's configuration list next to --headless and --slim. Check the configuration guide in the repo for exact semantics before you depend on it.

What are the real risks?

The first disclaimer in the README is the one that matters most: the server "exposes content of the browser instance to the MCP clients, allowing them to inspect, debug, and modify any data in the browser or DevTools." In plain terms, anything the browser can see, the agent can see.

Practical rules we would apply:

• Use a separate profile or an isolated session for agent work. Do not attach the agent to the Chrome window where you are logged into email, banking or your cloud console.
• Treat page content as untrusted input. A web page can contain text that tries to steer an agent. An agent that reads a hostile page and holds your logged-in session is the classic prompt-injection setup. We described the pattern in our look at MCP rug pulls and tool poisoning and the browser agent autonomy incident.
• Pin or review versions in shared setups. @latest is convenient, but a team may prefer a pinned version so the skills and tools stay in sync.
• Stay on supported Chrome. The README says only Google Chrome and Chrome for Testing are officially supported. Other Chromium browsers may work, but you accept the risk.

How does it compare with other browser tools for agents?

Browser tooling for agents has split into several camps. Chrome DevTools MCP sits in the "debug and verify your own web app" camp, with deep access to traces, console and Lighthouse-style audits.

If your job is "does my page render, is it fast, are there console errors, did my change break the layout", DevTools MCP is the most direct fit. If your job is "navigate dozens of third-party sites cheaply", a headless or snapshot-based tool may cost less per step. Many teams will run both.

Building your own browser agent on top of it

The README has a short section for tool builders. If you are developing agentic tooling and want an integrated browser sub-agent in your product, the maintainers recommend building on top of Chrome DevTools for agents, and they point to the Gemini CLI browser agent documentation as a reference implementation. Antigravity 2.0's bundled browser sub-agent is another example, per the Chrome docs page.

This matters for the wider ecosystem. When a browser vendor ships the official agent bridge, other agent products no longer need to maintain their own fragile Chrome automation, and test setups become more portable across Claude Code, Codex, Gemini CLI and Cursor.

Prompts to try today

These prompts follow the patterns in the official docs. Run them against a local dev server first.

• "Check the performance of http://localhost:3000, record a trace, and list the three largest causes of slow Largest Contentful Paint."
• "Open the checkout page at mobile width, click through the flow, and report every console error with its source-mapped stack trace."
• "Run a Lighthouse accessibility audit on the home page and suggest fixes for low-contrast elements."
• "Reload the dashboard five times and tell me whether memory keeps growing; use the memory-leak skill."
• "Inspect the network requests on login and tell me which cookie is missing when authentication fails."

For a teaching angle, notice that each prompt gives the agent a measurable check and not a vague wish. That is the same lesson we see in AI code review process write-ups: agents do better when verification is part of the loop.

What are people asking?

Do I need an API key? No. The server runs locally through npx and drives Chrome on your machine. Your coding agent still uses its own account or API key.

Does it work in CI? The CLI and the headless option suit CI. Note that usage statistics are automatically disabled when the CI environment variable is set.

Can it connect to the Chrome I already have open? The README's advanced usage guide covers connecting to a running Chrome instance, a custom executable path, persistent user data directories, concurrent sessions and debugging on Android. That power is exactly why the risk section above matters.

Why is it trending again? The repo has been active for a long time (1,608 commits on the page we reviewed), and agent platforms keep bundling it. Antigravity 2.0 ships it by default, and Claude Code and Codex have one-line installs. We treat the star count as a signal of adoption, not proof of quality.

What this means for what you build or pay

The tool is free and Apache-2.0, so the cost is your agent's tokens plus time to set up. The gain is a tighter loop: write code, load the page, read real console output and traces, fix, repeat, without you pasting screenshots into chat. For front-end teams using agents daily, that loop is where most wasted time sits.

The cost of ignoring the privacy flags is also real but small: usage statistics and CrUX lookups are default-on. Decide once, as a team, and put the flags in your shared config.

Bottom line

Chrome DevTools MCP is the most complete first-party way to give a coding agent eyes on a real browser. Install it through the plugin route so the skills come with it, switch off the telemetry you do not want, isolate the browser profile, and give the agent measurable checks. Keep the usual rule for any tool with this much reach: the agent can see what the browser sees.

Related reading

• Agent skills: the complete guide
• What is MCP? The Model Context Protocol guide
• Claude Code commands reference
• Reducing Claude Code token overhead with a Chrome MCP artifact
• Vercel agent-browser guide
• Lightpanda 1.0 headless browser for agents
• Top MCP servers, open and closed source

Official sources: the chrome-devtools-mcp repository and the Chrome for Developers docs.

Star counts, flags and install commands are accurate as of November 13, 2026. Check the repo's changelog before you pin a version.