Chrome DevTools MCP

What it is

Chrome DevTools is the panel developers open in Chrome to see what a web page is really doing: errors in the console, network requests, how long things take to load. Chrome DevTools MCP gives your coding agent that same view. MCP (Model Context Protocol) is the standard way to plug extra tools into agents like Claude Code, Cursor and Codex.

Once it's installed, your agent can open Chrome, go to your app, click and type, take screenshots, read console errors, inspect network requests and record a performance trace. It's built and maintained by Google's Chrome DevTools team, on top of Puppeteer, their browser automation library. It's free and Apache-licensed.

It now has about 60 tools, plus a command-line version and a set of skills for jobs like accessibility checks, slow page loads and memory leaks.

What actually happens when you use it

1. You ask for something that needs a browser. For example, "the sign-up button does nothing, find out why" or "check how fast the home page loads".
2. Chrome opens. The first time the agent needs a browser, the tool starts a separate copy of Chrome with its own profile. You can watch it work.
3. The agent looks around. It loads the page, takes a snapshot of what's on screen, clicks and fills forms, and reads console messages and network requests.
4. It measures. For speed problems it records a trace and pulls out the key findings, the same ones DevTools shows a human. It can also run a Lighthouse audit, Google's checker for speed, accessibility and SEO.
5. It fixes and checks again. The agent edits your code, reloads, and confirms the error is gone instead of guessing.

Since Chrome 144 there's also an --autoConnect option. It lets the agent use the Chrome window you already have open, including pages where you're signed in. Chrome asks your permission each time a session starts.

What people like

• It's reliable compared with alternatives. One long-time user on Hacker News found it more reliable and token efficient than other tools of its kind, and said it works well with desktop apps built on web tech.
• It can use your real browser. Another said its big upside is connecting to windows you already have open, which the command-line route struggled with.
• Good for figuring out how a site works. One user has it study a site using their logged-in session, and another said it works great for them for the same job.
• It's the debugging specialist. A comparison with Microsoft's Playwright sums it up: Playwright drives a browser, DevTools MCP debugs one. Reach for it for speed, memory, network and console problems.
• Fast fixes. A macOS bug where Chrome stole focus from your editor on every command was fixed upstream in Puppeteer. Releases ship most weeks.

What people run into

• It eats tokens. Several Hacker News users called it extremely token heavy or a token guzzler if you pay for your own usage. Page snapshots and long lists of tools take up room in the agent's memory. A Chrome team member pointed people to the new command-line version, which avoids most of that.
• It can feel slow. One user said both it and Playwright are super slow and clunky for plain browser automation, partly because the agent thinks between every step.
• Connection trouble. Getting it to connect is the most common complaint in the issue tracker. On Windows with WSL (Linux inside Windows), it can't start Chrome on the Windows side, and Microsoft won't fix the cause. You have to install Chrome inside WSL or change WSL's network settings. Others report it dropping mid-session.
• Lots of tabs can crash Chrome. With --autoConnect on a browser with hundreds or thousands of tabs, the first command can hang or crash Chrome. That issue is still open.
• Some tools report success too early. A batch of October issues found edge cases, such as fill saying it worked on a field it couldn't change. Ask your agent to confirm with a screenshot when it matters.

Before you install

• Usage statistics are on by default. Google collects things like tool success rates, timing and your environment. Add --no-usage-statistics to the command, or set CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS=1, to opt out. Opting out of Chrome's own stats doesn't cover this.
• Performance traces can send URLs to Google. To show real-user speed data, it looks up the pages you test in Google's Chrome UX Report. Add --no-performance-crux to stop that, for example on private staging sites.
• The agent sees whatever's in the browser. The README warns that anything in the browser is exposed to your agent. A page could also contain hidden instructions aimed at your agent. Prefer the default separate browser over --autoConnect to your everyday Chrome with your email and bank logged in.
• Save tokens. Use --slim for basic browsing (three tools instead of about 60), turn the server off when you aren't doing browser work, or use the chrome-devtools command-line tool with its skill instead.
• Chrome only. It officially supports Google Chrome and Chrome for Testing. Other Chromium browsers may work but aren't guaranteed.

The short version

If you build web apps with an agent, this is one of the most useful add-ons you can install. It lets the agent check its own work in a real browser instead of claiming success blind. It comes from the Chrome team and is maintained actively. Its costs are tokens and some setup friction, especially on Windows with WSL. Use the slim mode or the command-line tool to keep costs down, opt out of the statistics if you prefer, and keep it away from the browser where you're signed in to everything.