Chrome DevTools MCP Server Setup for Cursor IDE (2026)

How do you set up the Chrome DevTools MCP server in Cursor? Add a chrome-devtools block to ~/.cursor/mcp.json pointing npx at the chrome-devtools-mcp package, restart Cursor, and the AI can launch or attach to a real Chrome instance — reading console errors, inspecting network requests, and recording performance traces the same way you'd do it manually in the DevTools panel. No API key, no account, no OAuth screen.

This is a different tool from the Puppeteer and Playwright servers already covered on this site, even though all three drive a real browser. Puppeteer and Playwright are built for automation — scripting clicks, filling forms, running test flows. Chrome DevTools MCP, published by the Chrome DevTools team itself, is built for diagnosis — giving the model the same instrumentation a developer reaches for when a page is slow, broken, or throwing errors nobody can explain from the code alone.

What You Can Do With Chrome DevTools MCP in Cursor

Once connected, Cursor can typically:

The distinguishing feature is the diagnostic layer. Asking a general browser-automation server to "figure out why this page is slow" gets you screenshots and maybe a script that clicks around. Asking Chrome DevTools MCP the same question gets you an actual trace with real numbers attached — long tasks, layout shifts, slow network waterfalls — because that's what the underlying protocol exposes.

Prerequisites

Step 1: Configure Cursor

There's no separate global install step for most setups — npx fetches and runs the package on demand. Open Cursor → Settings → MCP and add:

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

Restart Cursor completely for the new server to register. The first run may take a moment longer than usual while npx fetches the package.

Step 2: Test the Connection

In Cursor chat, try:

Navigate to localhost:3000 and tell me if there are any console errors

Or, for a page you already have running:

Open our checkout page and check the Network tab for any failed or slow requests

A response citing specific console messages, status codes, or request timings — not a generic guess — confirms the connection is live and it's genuinely reading DevTools data rather than reasoning from a screenshot alone.

Step 3: Practical Workflows

Chasing down a console error

Navigate to localhost:3000/dashboard and tell me exactly what error is being thrown in the console, including the stack trace

Diagnosing a slow page load

Record a performance trace while loading localhost:3000/products and tell me what's taking the longest — is it JavaScript execution, network requests, or rendering?

Checking a failed API call

Go to the settings page, trigger the save action, and tell me what the network request to the save endpoint actually returns — status code and response body

Verifying a fix actually worked

Before I fix this: record what the console errors look like on the cart page right now. After I make a change, I'll ask you to check again and compare.

Checking real-world performance on a throttled connection

Load our homepage with network throttled to a slow connection and tell me how long it takes for the main content to become visible

Chrome DevTools MCP vs. Puppeteer and Playwright

This site also covers Puppeteer and Playwright, and it's worth being clear about where each one actually fits. Puppeteer and Playwright are automation-first: their core job is reliably scripting interactions — click this, fill that, wait for this element, assert that text appears. They're what you reach for to write or run a test suite.

Chrome DevTools MCP overlaps on basic navigation and interaction, but its reason for existing is the diagnostic surface: console messages, network waterfalls, and performance traces exposed as structured data the model can reason about, instead of a script it has to execute correctly to get the same information indirectly. If the question is "does clicking this button do the right thing," reach for Puppeteer or Playwright. If the question is "why is this page slow" or "what's actually throwing this error," Chrome DevTools MCP gets there faster because it's built around exactly that instrumentation.

Running both isn't unusual — automation server for test flows, DevTools server for the debugging session when something in that flow breaks.

When Not to Use This

Because it drives a real, unauthenticated Chrome instance with no access controls of its own, the same caution that applies to Puppeteer applies here: don't point it at production admin panels, internal tools, or anything where an unintended navigation or click has a real consequence. It's also not the right tool for headless CI performance testing at scale — it's built around an interactive debugging workflow with one browser instance, not a fleet of parallel headless runs, and for that use case a dedicated performance-testing pipeline will serve you better than routing it through a chat interface.

Troubleshooting

"No Chrome installation found" or similar
The server needs an actual Chrome binary on the machine, not just Chromium bundled with another tool. Confirm Chrome is installed and, if it's in a non-standard location, check the package's current documentation for how to point it at a specific executable path.

Console shows no errors even though the page is visibly broken
Not every failure logs to the console — a silently failing API call or a CSS layout issue often won't. Pair a console check with a network inspection or a screenshot request in the same prompt rather than relying on console output alone.

Performance trace comes back but the numbers don't match what you see manually
Trace results can vary run to run depending on what else is running on the machine at the time — background processes, other browser tabs, thermal throttling on a laptop. Treat a single trace as a data point, not a definitive benchmark; ask for a second run if a number looks surprising.

Cursor seems to hang after asking for a trace or a slow-loading page
Performance traces and full-page loads take real time to complete, more than a typical single tool call. Give it longer before assuming it's stuck, especially on a throttled-network request.

Works locally but the AI can't reach a staging or internal URL
The Chrome instance runs on your machine with your machine's network access — if a URL isn't reachable from your own browser (VPN required, internal DNS, etc.), it won't be reachable here either. This isn't an MCP-specific limitation.

Frequently Asked Questions

Q: Do I need an API key to use Chrome DevTools MCP?
A: No. Like the Puppeteer server on this site, it drives a local Chrome instance directly — there's no external service or account behind it to authenticate against.

Q: Is this the same as the Puppeteer or Playwright MCP servers?
A: No. All three drive a real browser, but Puppeteer and Playwright are built for scripted automation and testing. Chrome DevTools MCP is built around diagnostic data — console output, network requests, performance traces — the same instrumentation you'd use manually in Chrome's DevTools panel.

Q: Can it fix performance problems automatically, or just report them?
A: It reports. The server gives the model real trace data to reason from instead of guessing; whatever fix comes next is still a normal code change the model proposes and you review, not an automated remediation step.

Q: Does it work with pages behind authentication?
A: It can navigate and interact with authenticated pages the same way a human using that Chrome instance could, including sessions where you're already logged in. It doesn't have any special ability to bypass auth — if a page requires login, the browser session needs to already be logged in or the AI needs to complete the login flow through the page itself.

Q: Will this slow down my regular Chrome browsing?
A: It typically launches its own Chrome instance rather than hijacking your everyday browsing session, so your regular tabs and windows aren't affected. Check the package's current configuration options if you specifically need it to attach to an already-running Chrome instance instead.

Related Guides

---