Chrome DevTools MCP: What It Does, and When to Use Something Else

Google launched Chrome DevTools MCP on 23 September 2025 as a public preview. The launch post started from a fundamental problem: coding agents couldn't see what their code did once it ran in a browser. In Google's words, "They're effectively programming with a blindfold on." At the time it was a breakthrough, because it handed Claude a real Chrome with the console, the network requests and a performance trace to read.

A year on, it's at version 1.10.1 and has 52,700 stars on GitHub. I haven't used it for ages, though. Claude's own browser, the one built into the Claude desktop app, is more effective at debugging and design, which is what I use a browser for. Chrome DevTools MCP is now one of a handful of tools you could use.

So, in today's post we're taking a look at what it does now, how to install it in Claude Code, and when I'd reach for one of the others instead.

What Chrome DevTools MCP does now

Chrome DevTools MCP is an MCP server (a small program that gives Claude a set of extra tools it can call) built by Google's Chrome DevTools team. The README now calls the project "Chrome DevTools for agents", and says it lets your coding agent "control and inspect a live Chrome browser". The tool reference lists 59 tools in 11 categories. A lot of those sit behind flags, so a default install gives you about 30.

Several of them report Core Web Vitals, which are Google's page experience metrics: LCP for how quickly the main content paints, INP for how quickly the page responds to input, and CLS for how much the layout shifts about while it loads. For debugging, these are the main tools:

• The performance tools record a trace and pull Core Web Vitals out of it.
• lighthouse_audit runs Lighthouse (Google's automated page audit) for accessibility, SEO and best practices. Performance is left out of that audit and goes through the trace tools instead.
• The network tools return requests with their bodies.
• The console tools show uncaught errors with source-mapped stack traces, which means the error points back to your original source files rather than the bundled code.
• get_css_styles, new in 1.10.0, returns the matched CSS rules, inherited styles and custom properties, and marks any declaration that lost out as "[overloaded]".
• emulate covers the viewport, dark mode, CPU and network throttling, and geolocation.

Since launch the project has reached 1.0.0, which shipped on 18 May 2026 after eight months of 0.x releases. And --autoConnect now lets the server attach to a Chrome you already have running (Chrome 144 or newer) instead of launching a fresh one with its own profile. You start the remote debugging server yourself at chrome://inspect/#remote-debugging, and from then on the MCP server has access to every open window in your Chrome profile (the default one, if you have several). Attaching to your own Chrome is also the way round a sign-in problem. Google's docs say some accounts won't let you sign in when Chrome is being driven over WebDriver, which is how the server launches it by default.

Installing it in Claude Code

There are two ways to add it to Claude Code. The first is as a plain MCP server with claude mcp add. The second is as a plugin, which installs the same server along with the project's skills. A skill is a set of instructions Claude loads for a particular job, and this project ships them for things like accessibility debugging and chasing a slow LCP. Either way, you need Node.js LTS and a current stable Chrome.

# Claude Code, as an MCP server (all your projects)
claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest

# or as a Claude Code plugin (the MCP server plus its skills)
/plugin marketplace add ChromeDevTools/chrome-devtools-mcp
/plugin install chrome-devtools-mcp@chrome-devtools-plugins

After the plugin install, restart Claude Code and check the skills are there with /skills.

There are a few things to know before you run it, all from Google's own README. Usage statistics are collected by default, and adding --no-usage-statistics to the args turns that off. The performance tools may also send trace URLs to Google's CrUX API (the Chrome UX Report, Google's field data from real Chrome users), which --no-performance-crux stops. It officially supports Google Chrome and Chrome for Testing only. Other Chromium-based browsers may work, but Google doesn't guarantee it. And don't expect a browser window to open the moment Claude connects. Chrome starts on the first tool call that needs a browser.

The other ways to give Claude a browser

The other three come from Anthropic and Microsoft, and each one suits a different kind of job.

Claude's browser pane

Claude's browser pane started out as the Claude desktop app's preview for your own dev server, and in July 2026 Anthropic opened it up to any site, in the Week 28 release headed "In-app browser on Desktop". There's nothing to install. According to the Claude Code desktop docs, Claude can start your dev server, open it in the pane and verify its own changes, taking screenshots, inspecting the DOM, clicking elements and filling forms. It does that after every edit by default. Each external site needs your approval the first time. The pane uses a clean browser profile, so none of your saved logins or history come with it. You can still sign in to a site inside the pane, though, and that includes Google's pop-up sign-in.

Claude in Chrome

Claude in Chrome is Anthropic's extension for your own Chrome. It opens its tabs in a visible Chrome window and shares your browser's login state, which means it can work on any site you're already signed into. The Claude in Chrome docs say it needs a direct Anthropic plan (Pro, Max, Team or Enterprise), and it isn't available if you sign in with an API key. When it reaches a login page or a CAPTCHA, it pauses and asks you to deal with it.

Playwright MCP

Playwright MCP comes from Microsoft and is on version 0.0.83. It drives Chrome, Firefox, WebKit or Edge, and it works from the accessibility tree (the structured outline of a page that screen readers use) rather than from screenshots. The snapshots it takes of that tree are verbose, which costs tokens. Microsoft's README suggests coding agents use its Playwright CLI and skills instead, because they keep the trees out of the model's context.

If you're still running the old Puppeteer MCP reference server, it has been archived and its npm package is marked deprecated.

Debugging a live page with Claude's own browser

Here's the pane at work on one of my own pages. On 28 September, Claude checked a houtini.com article I'd published earlier that day.

Claude loaded the article in the pane at desktop width. It read the browser's Navigation and Resource Timing records (the timings Chrome logs for the page and for every file it loads), and added observers to catch LCP and layout shift. Then it checked the console for errors, resized the pane to a 375 x 812 mobile viewport, reloaded and checked the layout.

Most of it came back clean: no console errors, nothing shifting as the page loaded, and at phone width the four wide tables in the article scroll inside their own boxes instead of dragging the whole page sideways.

It did find a slow start, though: TTFB (time to first byte, how long the server takes to start sending the page) came in at 1,087 ms. A check from outside the browser with curl (a command-line tool that fetches a URL) came back between 0.90 and 1.33 seconds over four requests, with no cache status header on any of them. So every article request was being rendered fresh on the server with nothing cached. I fixed the caching the same evening, and the same curl check now comes back in around 0.1 seconds once a page is cached. A page that isn't cached yet still takes about a second. The whole run happened in the Claude desktop app, with nothing extra installed. If you haven't tried Claude yet, that link gets you a free week of Claude Code.

One more thing to watch out for: LCP didn't record at all, because the pane was hidden at the time and a background tab records no paint timings. Keep the pane visible when you need paint metrics. Chrome DevTools MCP would have gone further here, with a full performance trace and the Performance panel's insights, plus a Lighthouse audit for accessibility and SEO.

Which one to use

For debugging and design, I start in Claude's own browser. On the design side, I use it to see how a page holds up at phone width and in dark mode, which is just a case of resizing the viewport and switching the colour scheme. I'll pick an element on the page with Ctrl+Shift+S (Cmd+Shift+S on a Mac) and ask Claude to change it. And when Claude is working on a dev server, I watch its edits land in the pane as it goes. The others come in when the job needs something the pane can't do.

• Deep performance work goes to Chrome DevTools MCP. Performance traces with Core Web Vitals insights, Lighthouse, the CSS cascade and heap snapshots are all there, although the tools that analyse a heap snapshot sit behind the --memoryDebugging flag. Of the others, only Playwright MCP lists a trace tool, and only as an opt-in.
• For anything behind a login, Claude in Chrome is the easy one, because it uses the sessions you're already signed into.
• Playwright MCP suits test assertions and repeatable steps across different browsers, although for a coding agent like Claude Code, Microsoft points you at its Playwright CLI first.

Where to go from here

If you want Chrome DevTools MCP's traces and Lighthouse audits, the install commands are above. Otherwise, open the browser pane with Ctrl+Shift+B (Cmd+Shift+B on a Mac) and ask Claude to check a page you own. The console, the timings and a mobile-width check are a good first pass. If MCP servers are new to you, MCP servers explained covers what they are, and the Claude Code beginners guide gets you set up.