Choose Chrome DevTools MCP when...
The reviewer needs DevTools-native performance traces, Chrome console and network evidence, screenshots, or inspection of one live Chrome session.
Source checked · September 26, 2026
Chrome DevTools MCP vs Playwright MCP: choose by evidence and browser scope
This is no longer a simple “debugger versus automation” split. Both servers can automate pages, take screenshots, inspect console output, and work with network activity. Chrome DevTools MCP is the stronger fit when the job depends on Chrome DevTools traces and Chrome-specific diagnostics; Playwright MCP is the stronger fit when the workflow depends on structured page snapshots, repeatable actions, browser choice, or explicit session-state control.
Direct answer
Use the output you need to choose the tool
Choose Playwright MCP when...
The workflow needs structured accessibility snapshots, repeatable browser actions, selectable browser engines, route mocking, or controlled persistent and isolated states.
Do not treat the split as absolute
Playwright MCP also exposes console and network tools. Chrome DevTools MCP also automates pages. Choose by the evidence and operating model that matters most.
Chrome DevTools MCP
chrome-devtools-mcp
- Package version checked
- 1.10.1 on September 26, 2026
- Documented browser scope
- Google Chrome / Chrome for Testing
Playwright MCP
@playwright/mcp
- Package version checked
- 0.0.82 on September 26, 2026
- Documented browser scope
- Chrome, Firefox, WebKit, or Edge
Side-by-side decision matrix
| Decision point | Chrome DevTools MCP | Playwright MCP |
|---|---|---|
| Best fit | Deep inspection of one Chrome session: DevTools traces, console, network, screenshots, and page state. | Repeatable browser work with structured snapshots, actions, state control, and selectable browser engines. |
| Interaction model | Chrome DevTools data plus Puppeteer-backed browser automation. | Structured accessibility snapshots plus deterministic element references and Playwright actions. |
| Browser scope | Official support is Google Chrome and Chrome for Testing. | Current docs list chrome, firefox, webkit, and msedge as selectable browser values. |
| Diagnostics | Performance traces and DevTools-native console/network debugging are first-class capabilities. | Network requests, route mocking, console output, screenshots, tabs, dialogs, and storage state are available. |
| Session control | Can launch Chrome or connect to an intentionally running Chrome instance; isolate sensitive profiles. | Persistent, isolated, and extension-connected profile modes are documented. |
| Current MCP caveat | Browser contents are exposed to the MCP client; usage statistics and optional CrUX lookups have documented opt-outs. | Unsafe Playwright-code execution is RCE-equivalent; WebMCP page-provided tools must be treated as untrusted input. |
The overlap is real — the evidence model is different
Chrome DevTools MCP describes three core lanes: DevTools performance insights, advanced browser debugging, and reliable automation. Its official support boundary is Chrome and Chrome for Testing. That makes it a natural fit when the investigation is fundamentally about a Chrome session and the evidence should look like DevTools evidence.
Playwright MCP operates from structured accessibility snapshots and element references, but its current surface is not limited to clicking and typing. The documentation also includes screenshots, console messages, network inspection and mocking, storage state, tabs, dialogs, and direct Playwright code execution. It can select Chrome, Firefox, WebKit, or Edge.
A current Playwright-specific note
The Playwright MCP project now explicitly says coding agents may benefit from Playwright CLI plus Skills because that route can be more token-efficient. MCP remains positioned for persistent state, rich introspection, and iterative agentic browser loops.
Three concrete routing examples
A checkout preview throws a client error
Chrome DevTools MCP
Start with Chrome DevTools MCP when the useful evidence is a console stack trace, failed requests, or a performance trace from the failing Chrome session.
Playwright MCP
Use Playwright MCP when the same checkout path must become a repeatable smoke flow across deployments or browser choices.
A mobile navigation flow must be rechecked every release
Chrome DevTools MCP
Useful when a failure needs Chrome-specific console, network, or performance diagnosis.
Playwright MCP
Useful for repeating navigation, clicking, text checks, screenshots, and browser or profile variations.
An authenticated admin page needs inspection
Chrome DevTools MCP
Use a deliberately isolated Chrome profile if the task depends on DevTools evidence from one real session.
Playwright MCP
Use an isolated profile or controlled storage state if the task is a repeatable test-account workflow.
Browser state is a permission surface
Chrome DevTools MCP boundary
The official project warns that browser contents are exposed to connected MCP clients and can be inspected, debugged, or modified. It also documents opt-outs for usage statistics and CrUX field-data lookups used by performance tooling.
Playwright MCP boundary
Current docs call direct Playwright-code execution RCE-equivalent and say it should only be enabled for trusted clients. Pages can also expose experimental WebMCP tools, which must be treated as untrusted page-provided input.
For either server, start with a public page or test account, isolate browser state, and avoid personal banking, billing, customer-data, or production-admin sessions during first-run validation.
Minimal documented setup
Chrome DevTools MCP
npx -y chrome-devtools-mcp@latestThe official README uses this package in an MCP client config. Chrome launches when a browser tool is first invoked, not merely when the server is registered.
Playwright MCP
npx @playwright/mcp@latestThe current Playwright documentation uses this standard MCP config and documents --headless, --browser, isolated state, storage state, and other advanced options.
These commands were source-checked, not executed as part of this editorial comparison.
Primary sources · September 26, 2026
Check current behavior at the source
- ChromeDevTools/chrome-devtools-mcp — capabilities, support boundary, privacy notes, usage-statistics controls, and standard setup.
- Chrome DevTools MCP package metadata — package identity and version checked for this refresh.
- Microsoft Playwright MCP documentation — structured snapshots, interaction tools, browser selection, state modes, network tools, and unsafe-code boundary.
- microsoft/playwright-mcp — MCP positioning and the current CLI + Skills guidance for coding agents.
- Playwright MCP package metadata — package identity and version checked for this refresh.
Frequently asked questions
Is Chrome DevTools MCP only for debugging?
No. Its official project also describes reliable browser automation through Puppeteer. Its distinguishing strength is the DevTools-native evidence layer: performance traces, network inspection, console messages, screenshots, and Chrome debugging.
Is Playwright MCP only for testing?
No. Current Playwright MCP documentation includes normal page interaction, screenshots, network inspection and mocking, console messages, tabs, dialogs, and storage-state management. It is broader than a test runner interface.
Which one supports more browser engines?
Playwright MCP. Its current documentation lists chrome, firefox, webkit, and msedge. Chrome DevTools MCP officially supports Google Chrome and Chrome for Testing.
Should I install both?
Only when you have both operating lanes. A practical default is one primary browser MCP plus a documented handoff rule for failures that need the other tool, rather than exposing two overlapping tool sets without routing.
Are these commands hands-on tested by AgentSkillsHub?
No. This comparison was source-checked against current first-party documentation and package metadata. The setup commands shown here are documentation examples, not a claim that this editorial refresh installed or exercised both MCP servers.