Chrome DevTools for agents

What it is

Chrome DevTools for agents is a free, open source tool from the Chrome DevTools team. Its npm package, chrome-devtools-mcp, lets your coding agent control and inspect a live Chrome browser. It runs as a Model Context Protocol (MCP) server and as a command line tool. The README says both give your coding assistant the full power of Chrome DevTools for reliable automation, in-depth debugging and performance analysis. The agent can record a performance trace, read network requests and console messages, take screenshots and click through a page.

1. You ask your agent to check a page
2. The agent calls a tool on the MCP server
3. The server starts Chrome, or connects to one you run
4. DevTools and Puppeteer do the work in the browser
5. Results come back, and big outputs can go to files

Who it suits

Developers who want their coding agent to see what a page does, not only read its code. It fits front-end and web performance developers, test engineers and anyone building agent tools. Its tools are built around a Chrome browser, so it adds nothing to work that never touches a browser.

Where to use it

The maker’s docs list these clients, each with its own route. A client that is not listed can take the standard config from the README.

• Claude Code: one command for the MCP server, or a plugin that adds the skills too
• Codex: a codex mcp add command, and a config for Windows 11
• Gemini CLI: a command for the MCP server, or an extension that adds the skills
• Cursor: an install link, or the standard config in its settings
• GitHub Copilot and VS Code: a plugin installed from source, or the MCP server by button, file or command line
• Copilot CLI and Visual Studio: a dialog in Copilot CLI, and an install button in Visual Studio
• Antigravity: a config that connects to the browser Antigravity already uses
• Editors and agents in the guide: Amp, Bob, Cline, Command Code, Devin CLI, Factory CLI, Gemini Code Assist, Grok Build CLI and JetBrains
• More in the guide: Kiro, Mistral Vibe, OpenCode, Pi, Qoder, Qoder CLI, Warp, Windsurf, Katalon Studio and FLUJO
• A terminal with no MCP client: the chrome-devtools command line tool

How to set it up

Get it saves a zip of Mindket’s setup notes in your downloads folder, with a page for each main client and one for the others, from the maker’s README and docs. The server itself comes from the npm package, which your client starts with npx.

1. Install a current Node.js LTS, Chrome and your client.
2. Add the standard config to your client’s MCP settings, or run your client’s own command from the setup notes.
3. Send the README’s first prompt. The browser starts when the first tool needs it.

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

Claude Code has its own command in the Client configurations guide, which adds the same server. The guide’s plugin route, which adds the skills too, is on the Claude Code page of the setup notes.

claude mcp add chrome-devtools --scope user npx chrome-devtools-mcp@latest

How to use it

Ask in plain words, and the agent picks the tools. The README’s first prompt checks that everything works.

Check the performance of https://developers.chrome.com

Your client should open the browser and record a performance trace. For page work, the maker’s chrome-devtools skill tells the agent to take a text snapshot first and click elements by the uid in it. A screenshot is for when you need to see the page. With no client, the command line tool does the same from a shell.

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

Example

A site will not let you sign in to the Chrome the server launches, because some accounts refuse sign-in when WebDriver controls the browser. So you connect the server to the Chrome you already use. In Chrome 144 or newer, open chrome://inspect/#remote-debugging and follow the dialog to allow incoming debugging connections. Then add the --autoConnect argument to the server.

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

With Chrome running, send the README’s prompt. Chrome asks for your permission in a dialog. After you click Allow, the server opens developers.chrome.com and takes a performance trace. The guide says the server can reach all open windows of the profile it connects to.

For newcomers and experts

If you are new. A coding agent can write a page but cannot see it run. This server gives it a real Chrome, so it can load your page, click through it and read the console and network records, much as you would in DevTools. You do not need to know DevTools first. Start with the standard config and the first prompt, then ask for one thing at a time: a screenshot, the console errors or a performance trace.

For experts. The server starts Chrome with a dedicated profile that is kept between runs. Only one browser can use it at a time. The --isolated option gives each server its own temporary profile. If one server handles several sessions, page ID routing is on by default and page tools take a pageId.

It keeps network requests and console messages for the last three navigations of each page, and --maxNavigationSaved sets any number from 1 to 25. The command line tool talks to a background daemon that is headless by default and keeps its browser between commands.

Two options shrink what reaches the model. The --slim option leaves three tools, navigate, evaluate and screenshot. The --screenshotMaxWidth option downsizes screenshots, and the docs say image tokens scale with dimensions, not file size.

Good to know

It runs on your machine, and a few paths reach out.

• What it can reach: the README says the server exposes the content of the browser to your client, which can inspect, debug and modify any data in the browser or in DevTools. Keep out of that browser anything you do not want your client to see
• Usage statistics: Google collects them by default, such as tool success rates, latency and environment information. Pass --no-usage-statistics to opt out, or set CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS or CI
• Outbound calls: the performance tools may send trace URLs to the Google CrUX API, and --no-performance-crux stops that. The server also checks the npm registry for updates unless CHROME_DEVTOOLS_MCP_NO_UPDATE_CHECKS is set
• Other browsers: the README says it officially supports Google Chrome and Chrome for Testing only. Other Chromium browsers may work, without a guarantee
• A debugging port: starting Chrome with a remote debugging port for the server opens a port that any application on your computer can use to control the browser. Do not browse sensitive sites while it is open. The --autoConnect route asks your permission in a dialog in Chrome
• Files: the command line tool has unrestricted filesystem access by default, and --workspace limits it. The server’s file tools stay in the OS temp folder when your client sets no roots
• Limits are settings, not sandboxes: setting --javascriptEvaluation or --fileNavigations to false narrows what the agent can do, and the docs say neither one is a sandbox. Make sure the agent cannot write to the config file or its folder
• Skills: they describe one version’s tools, and outdated ones can name tools or parameters that changed. Update them whenever you update the server
• Removal: the README gives no uninstall steps. Mindket’s notes list what to remove by hand, and the default profile folder stays until you delete it
• License: Apache-2.0. The LICENSE file is the standard Apache License 2.0 text, and the package.json names Google LLC as the author