ChromeDevTools/chrome-devtools-mcp

There is a concrete before-and-after here: an agent that can't see the browser can only guess why a page is slow or a console error appears. After connecting this MCP server or CLI, the same agent can drive Chrome, record a performance trace, read console output with source-mapped stack traces, and inspect network requests itself. That turns browser debugging from a back-and-forth where you paste logs into a task the agent can partly complete on its own.

The problem

You want an agent to diagnose a real page: it needs to navigate, cause the slow interaction, and then look at evidence rather than markup. Without browser access, the agent reasons from files and screenshots you feed it, and debugging loops back to you for every observation. With this project, the agent calls tools that act on a live Chrome session and returns the resulting trace, console or network data. The result is an agent that can connect a user-visible symptom to a concrete network or performance finding in the same session.

What's different

Two things carry the design. First, the server is built on Puppeteer for the actual browser actions and includes automatic waiting for action results, so the agent doesn't need to construct clever sleep-and-check loops for routine interactions project README. Second, performance insight comes from Chrome DevTools itself: it records traces and extracts actionable insights rather than handing the agent raw JSON to interpret project README. The output is closer to the Performance panel's conclusions.

The project ships as an MCP server and as a CLI, plus installable skills for agents that support plugins or skill folders project README. That breadth matters: an agent with plugin support gets the whole setup in one command, while an agent without it needs a manual copy of the skill folder, and the CLI skill additionally requires the package installed globally. The trade-off is exposure. The README states plainly that the server exposes the browser instance's content to MCP clients, which can inspect and modify browser data. This is a tool for a dedicated, disposable debugging session, not for pointing at a logged-in profile full of personal data.

Who should try it

A good fit is a web developer whose agent already writes and edits code but stalls on "the page feels slow" or "this request fails only in the browser." The trace and console tools give the agent the missing evidence. A second good fit is someone doing reproducible automation: Puppeteer handles the clicks, and the agent gets structured results instead of brittle scripts. A poor fit is anyone who wants Chrome in the agent's path for everyday browsing or who needs Firefox or Safari parity, since only Google Chrome and Chrome for Testing are officially supported project README. Teams with strict data-handling rules should also pause: usage statistics such as invocation success rates, latency and environment information are collected by default and require opting out project README.

Requirements and limitations

You need a Node.js LTS release, a current stable Chrome or newer, and npm project README. MCP clients configure it with a single npx command, and the browser starts only when a tool needs it, so a configured but idle server doesn't hold a browser open. For editor-specific setup there is a separate client configurations guide project README.

Two boundaries deserve attention before setup. Browser compatibility is Chrome-only in practice: other Chromium browsers may run but are unsupported, so don't plan a cross-browser debugging workflow around it. And the disclosure requirements cut both ways: pointing it at a real profile means its cookies, sessions and page content are visible to the MCP client, while usage statistics and update checks are both on by default with separate environment variables to disable them. Budget time for deciding which profile and settings your workflow should use, not just for the initial config.

HotRepo's take

The project has been on HotRepo's daily board on 16 recorded days between 2026-05-22 and 2026-10-27, when it stood at 54,246 stars, with recorded daily gains falling from +437 on 2026-05-23 to +70 on 2026-10-27 HotRepo board history. That is a long, visible presence rather than a one-day appearance, but the recorded sample is sparse and cannot establish a stable growth trend. The practical question before adopting it is which browser profile you connect it to; check the advanced usage guidance on persistent profiles and connecting to an existing Chrome instance before deciding. For the Chrome-only limitation, the Chrome for Testing downloads are the documented supported path Chrome for Testing.