Chrome DevTools MCP vs Playwright MCP: which to use

There are now two well-maintained ways to let a coding agent drive a browser, and they look similar enough from the outside that most teams pick one by accident. Chrome DevTools MCP comes from the Chrome team. Playwright MCP comes from the Playwright team and now ships bundled with Playwright itself.

They're built for different jobs. Picking the wrong one doesn't break anything, it just means you spend a week working around a gap that the other tool doesn't have.

What each one actually is

Chrome DevTools MCP exposes DevTools to an agent. Console output, network requests, performance traces, Lighthouse audits, the accessibility tree, DOM inspection, plus Puppeteer-based automation underneath. It's DevTools with an API that a model can call, and on recent Chrome versions it can attach to an existing authenticated session rather than starting from a cold profile.

Playwright MCP exposes Playwright. Navigation, locators, assertions, traces, and the rest of the API your test suite already uses, wrapped so an agent can call it. It runs across Chromium, Firefox, and WebKit, because Playwright does.

The one-line version: DevTools MCP is built for looking at a page. Playwright MCP is built for acting on one and keeping a record you can replay.

Where DevTools MCP is the better answer

Performance work is the clearest case. If you want an agent to tell you why a page takes four seconds to become interactive, it needs the actual trace: the long tasks, the render-blocking requests, the layout shifts. Playwright can measure timings, but it isn't a profiler, and asking it to be one is fighting the tool.

Debugging an already-broken page is the second case. Console errors and failed network calls are right there without any instrumentation. An agent that can read them will diagnose a bug faster than one working from a screenshot and a guess.

Third: accessibility inspection. Walking the accessibility tree and running Lighthouse from inside the agent loop pays off quickly, and it lines up with the kind of work accessibility compliance now demands from teams selling into the EU. Worth knowing the limits though, automated scans catch a minority of real WCAG issues no matter which tool runs them.

Where Playwright MCP wins

Anything where the output needs to become a test. This is the big one. If an agent explores a checkout flow and you want a spec file at the end that runs in CI next Tuesday, you want the agent operating in Playwright vocabulary the whole time. Locators, waits, assertions, all of it in the same shape your repo already uses.

Translating a Puppeteer-flavored exploration into a Playwright test afterward is possible, and it's also a step where things get quietly lost. Fewer translation layers, fewer surprises.

Cross-browser is the other clear win. DevTools MCP is Chrome. If Safari matters to your users, and for consumer products it usually does, Playwright MCP is the only one of the two that can go there.

Side by side

So which one

Run both. They're MCP servers, your agent can hold more than one, and they don't conflict.

If you only want one: pick Playwright MCP if the goal is test coverage, pick DevTools MCP if the goal is diagnosis. Most QA teams are in the first group and most frontend performance work is in the second, which is roughly how the two projects seem to see themselves.

One caution on attaching to an authenticated session. It's a real convenience and it's also a real session, with real permissions. An agent reading a page that contains instructions is an agent that can be steered, which is the whole subject of testing for prompt injection. Worth using a scoped account rather than your own admin login.

The part neither of them does

Both tools answer "can an agent drive this browser" with a clear yes. Neither answers what happens next: which explorations became tests, which of those tests still run, which journey nobody has checked since March. An MCP server is a capability, not a system of record.

Teams that adopt one of these and stop there tend to end up with a lot of impressive agent sessions and no accumulated coverage. The sessions were useful. They just didn't add up to anything, because nothing was keeping score.

qtrl sits at that layer. Agent runs happen in real browsers, and what each run covered is recorded as structured coverage you can look at later, rather than a transcript that scrolls away. Explorations turn into repeatable cases instead of one-off sessions.

You can keep using whichever MCP server fits the job in your editor. The difference is that the results land somewhere your team can see them, with the boundaries and logging that make agent runs safe to put in a pipeline. See how it works.