Repository navigation
playwright mcp vs chrome devtools mcp
Short answer: Chrome DevTools MCP is for finding out why a page behaves the way it does; Playwright MCP is for making a page do something. They overlap enough to be confused for competitors and were built for different questions, and picking by star count gets you the wrong one.
| Chrome DevTools MCP | Playwright MCP | |
|---|---|---|
| Maintainer | ChromeDevTools | Microsoft |
| Stars, read 2026-09-10 | 51,500 | 36,900 |
| Licence | Apache-2.0 | Apache-2.0 |
| Browsers | Chrome and Chrome for Testing only | chrome, firefox, webkit, msedge |
| The model sees | DevTools: traces, network, console | the accessibility tree |
| Built for | inspecting and profiling | driving and asserting |
Chrome DevTools MCP gives an assistant the DevTools panel. Performance traces with insights extracted, network request analysis, console messages, screenshots, and source-mapped stack traces. The last one is the giveaway: source maps only matter if you are debugging code you wrote. This is a tool for your own application, and it is very good at the question "why is this slow, and what fired when".
Playwright MCP gives an assistant a browser to operate. It exposes the page as an accessibility tree with stable references and a small action vocabulary, so a model can navigate, click and type its way through a flow. What it is and how it differs from the Playwright CLI covers that side in full.
The practical split, in one line each: if you would have opened DevTools, you want the first. If you would have written a script, you want the second.
"I want the agent to test my site." Both, at different moments. Playwright MCP to walk the flow, Chrome DevTools MCP to find out why the step that failed was slow or threw. Neither replaces knowing which of the two questions you are asking at that moment.
"I want to scrape." Neither is built for it and Chrome DevTools MCP especially is not. See using a browser MCP server for web scraping for the pattern that actually works, which uses a model to work out the shape and plain code to do the repetition.
"The site keeps blocking my agent." Neither addresses that, because both drive a stock automation build. That is a third question about the engine underneath, and why an agent gets blocked sorts the causes by how often they are the real one.
Worth reading before you register it, and stated by the project rather than inferred by us:
- It exposes all browser content to the MCP client without sandboxing. If the Chrome it attaches to is the one you are logged into, the assistant can see what you can see.
- Performance tooling may send trace data to Google's CrUX API, with an opt-out available.
- It collects usage statistics by default, disabled with a flag.
None of these is unusual for a debugging tool, and all three are the kind of thing that matters more once an assistant rather than a person is on the other end of it.
Whichever you register, the tool descriptions ride in the model's context on every turn, and so does each one's argument schema. For calibration, measured on our own server's registry on 2026-10-02: 17 tools, 8,918 characters of description, 3,464 tokens per turn. Register two browser servers side by side and you are paying that twice, on every turn, plus giving the model overlapping verbs to choose between.
That is the argument against "install both and see": pick the one that matches the question you have this week, and keep the other unregistered until it is the question.
Is Chrome DevTools MCP better than Playwright MCP? Different jobs. DevTools MCP inspects a running Chrome; Playwright MCP drives a page across four engines.
Does Chrome DevTools MCP work with Firefox? No. Chrome and Chrome for Testing only; other Chromium browsers may work and are not guaranteed.
Can I use both? Yes, and it costs context twice and makes the model's choice harder. Prefer one per task.
Which one for performance debugging? Chrome DevTools MCP, without competition - traces and insights are the thing it was built for.
Which one for automating a flow? Playwright MCP, and if the flow is stable and repeated, neither: write it as a script.
Do either of them avoid bot detection? No. Both drive a stock automation build, and that is a separate layer from the MCP surface.
See also: Playwright MCP vs the Playwright CLI, choosing an MCP server for browser automation, and the MCP server for this project's own configuration.
- ChromeDevTools/chrome-devtools-mcp, retrieved 2026-09-10: stars, licence, browser support, capabilities, and the three caveats quoted above.
- microsoft/playwright-mcp, retrieved 2026-09-10: stars, licence, browser options and the accessibility-tree design.
- This project's own MCP server source, read 2026-09-13, for the tool-count and description-size figures.
Written while maintaining a third browser MCP server. It is not the recommendation for either job on this page: for debugging your own site DevTools MCP wins outright, and for driving a flow across engines Playwright MCP is the default.