Chrome DevTools MCP vs Playwright MCP vs Puppeteer (Tested 2026)

TL;DR + decision tree

• Need DOM interaction at scale with deterministic clicks and form fills across multiple browsers? Playwright MCP. Microsoft’s accessibility-snapshot model is the right default for agentic workflows because it’s text-only, fast, and cross-browser.
• Need full Chromium control with profiling — Core Web Vitals traces, console messages, network inspection, performance insights? Chrome DevTools MCP. The Chrome team built it on the DevTools Protocol; nothing else exposes CDP this directly.
• Need a minimal, battle-tested reference server that just navigates, clicks, screenshots and evaluates JS? Puppeteer MCP. Chromium-only, seven tools, in the official modelcontextprotocol/servers repo. The “hello world” of browser MCP.
• Need headless cross-browser at scale? Playwright MCP again — same answer. The other two are Chromium-only.

We’ll cover each in detail below — feature matrix first, then per-tool install (the same canonical install card from each server’s detail page), pricing reality, and a benchmark methodology you can run in fifteen minutes on your own laptop.

What browser-automation MCP servers do

These three servers solve the same underlying problem in different ways: an LLM that wants to test a webapp, scrape a page, debug a regression, or measure performance needs a way to drive a browser without writing Playwright or Puppeteer code from scratch every time. Browser-automation MCP servers expose a fixed tool surface — navigate, click, fill, evaluate — that the model invokes through the JSON-RPC wire format MCP defines.

The differences come down to four axes:

1. How the agent perceives the page. Chrome DevTools MCP returns an accessibility-tree snapshot (take_snapshot) plus optional screenshots. Playwright MCP’s default browser_snapshot returns the a11y tree (the README explicitly notes “this is better than screenshot”). Puppeteer MCP returns screenshots only — the model has to reason visually.
2. Browser scope. Chrome DevTools MCP and Puppeteer MCP are Chromium-only. Playwright MCP supports Chromium, Firefox, and WebKit through Playwright’s cross-engine layer.
3. Profiling depth. Chrome DevTools MCP exposes performance_start_trace, performance_stop_trace, and performance_analyze_insight — full Chrome performance traces with Core Web Vitals scoring. Neither Playwright MCP nor Puppeteer MCP exposes profiling primitives directly; you have to evaluate JS to get metrics.
4. Maintainer cadence. Microsoft ships @playwright/mcp alongside Playwright proper. Google’s Chrome team owns chrome-devtools-mcp. Puppeteer MCP lives in the broader modelcontextprotocol/servers reference repo and moves at the protocol cadence, not the Puppeteer cadence.

If you’re new to the protocol underneath, our What is MCP primer covers the JSON-RPC wire format these servers run on. The rest of this post assumes you know that already.

Side-by-side matrix

Every cell in this matrix is sourced from each tool’s repo, README, or package metadata (citations in the per-tool sections below). Live values checked 2026-05-08 against MCP.Directory’s indexed catalog at /servers.

Three things jump out of the matrix. Microsoft’s Playwright MCP has the largest star count (7,331) and the broadest browser support — that’s the dominant ecosystem signal for cross-browser work. Chrome DevTools MCP is the only one with built-in performance tracing, which is the single most important capability if your agent needs to measure Web Vitals or diagnose a slow render. Puppeteer MCP is the smallest tool surface (7 tools), which is a feature, not a bug, if you want a minimal dependency for a small set of automation tasks.

Chrome DevTools MCP — install + recipe

Chrome DevToolschromedevtools

Official1-Click Ready

Use Chrome DevTools for web site test speed, debugging, and performance analysis. The essential chrome developer tools f

browser automationdeveloper tools3.8k170

What it does best

This is the only one of the three that turns the Chrome DevTools Protocol into agent tools. The headline trio —performance_start_trace, performance_stop_trace, performance_analyze_insight — gives an LLM the same Core Web Vitals breakdown a human gets from the Performance panel, plus structured insights it can act on. Pair that with list_console_messages andlist_network_requests and the agent can diagnose a slow render end-to-end, then patch the offending source in the same conversation.

Pick this if you...

• Need real Core Web Vitals numbers (LCP, INP, CLS) from inside an agent loop, not a separate Lighthouse run.
• Want the agent to inspect console errors and network waterfalls while it’s debugging a page.
• Are already standardized on Chrome and don’t need Firefox or WebKit coverage.
• Plan to chain “measure, then fix” in one conversation — perf data into a code edit.

Recipe: profile a checkout flow and report the worst Web Vitals

Drop this into Cursor or Claude Code with Chrome DevTools MCP installed:

Use chrome-devtools. Open a new page and navigate to
https://shop.example.com/checkout. Start a performance trace,
click "Add to cart", wait for the cart drawer to render, then
stop the trace. Run performance_analyze_insight on every
highlighted insight. Then call list_console_messages and
list_network_requests. Return JSON with: LCP, INP, CLS, the
three slowest network requests with status + duration, and the
top three performance insights with file paths or URLs where
applicable.

The agent invokes new_page, navigate_page, performance_start_trace, the click, thenperformance_stop_trace, and walks each insight via performance_analyze_insight. The console + network calls fold in alongside the Web Vitals, so a follow-up “now patch the worst offender” message can edit the source file in the same thread.

Skip it if...

You need cross-browser coverage. Chrome DevTools MCP only attaches to Chrome / Chromium via CDP — Firefox- or WebKit-specific bugs need Playwright MCP instead. It also launches a debug Chrome that doesn’t share your normal profile, so logged-in flows need an explicit--user-data-dir or in-agent sign-in.

Playwright MCP — install + recipe

Playwright Browser Automationmicrosoft

Official1-Click Ready

Enhance software testing with Playwright MCP: Fast, reliable browser automation, an innovative alternative to Selenium s

browser automation7.5k539

What it does best

Built around the accessibility-snapshot model: browser_snapshot hands the model a structured a11y tree with stable element refs instead of a screenshot. Clicks and form fills target those nodes, so action chains survive layout reflows that would break pixel-driven automation. It’s text-only, deterministic, dramatically cheaper in tokens, and the only one of the three that drives Chromium, Firefox, and WebKit from a single tool surface — meaning one prompt can reproduce a regression across all three engines.

Pick this if you...

• Need cross-browser coverage — Chromium, Firefox, and WebKit all from one server.
• Want deterministic action chains (click, fill, drag, keypress) instead of screenshot-and-guess.
• Care about token cost — a11y snapshots are far cheaper than describing images.
• Are reproducing a regression a customer reported in a specific browser.

Recipe: reproduce a Firefox-only checkout regression

Drop this into your agent with @playwright/mcp installed:

Use playwright. Launch with --browser firefox. Navigate to
https://my-app.example.com/checkout. Take a snapshot, find the
"Email" field, fill with [email protected], find "Continue"
and click. Take another snapshot, find the "Card number" field,
fill 4242 4242 4242 4242, fill expiry 12/30, fill CVC 123,
click "Pay $24.99". Wait for "Order confirmed" text. If it
doesn't appear within 5s, switch --browser to chromium and run
the same flow. Return a diff describing where Firefox diverged.

Each browser_snapshot returns stable refs the model passes to browser_click and browser_fill_form, so clicks land on the correct nodes even when the layout reflows mid-flow. Switching --browser mid-conversation keeps the same tool calls but swaps engines, which is the whole point of the cross-browser surface.

Skip it if...

You need DevTools-Protocol-grade profiling — there’s no equivalent of performance_start_trace here, so Core Web Vitals work belongs to Chrome DevTools MCP. First-run cost is also real: browser_install pulls Chromium + Firefox + WebKit, which can run 30–90s on a cold CI machine that doesn’t cache the binaries.

Puppeteer MCP — install + recipe

Puppeteeranthropic

Official1-Click Ready

Puppeteer is a browser automation studio server for LLMs, enabling web page interaction, screenshots, and testing with S

browser automation5.7k261

What it does best

This is the “just the basics” option: puppeteer_navigate, puppeteer_screenshot, puppeteer_click, puppeteer_fill,puppeteer_select, puppeteer_hover, puppeteer_evaluate. Seven tools, no accessibility-snapshot abstraction — the agent either screenshots and reasons visually or runs JS against the DOM. As the reference server in the canonical modelcontextprotocol/servers repo, it’s the smallest dependency you can get for “open a page, look at it, click something, read the result.”

Pick this if you...

• Want the smallest possible tool surface — seven tools, nothing fancy.
• Already have Chromium installed and don’t want a second browser bundle.
• Need quick screenshot-driven smoke tests rather than deterministic E2E flows.
• Trust an agent that can drop into puppeteer_evaluate to read the DOM directly when needed.

Recipe: 60-second staging smoke test

Drop this into your agent with @modelcontextprotocol/server-puppeteer installed:

Use puppeteer. Navigate to https://staging.example.com.
Take a screenshot. Use puppeteer_evaluate to return JSON with:
document.title, the count of <img> tags with naturalWidth === 0,
and the URLs from window.performance.getEntriesByType('resource')
that have transferSize === 0 (likely failed). Then puppeteer_click
the primary nav link "Pricing" and screenshot again. Report both
screenshots' general layout plus the JSON of broken assets.

Two screenshots, one navigation, one evaluate call. The agent uses the first screenshot to confirm the page rendered, the JS evaluate to surface broken images and failed network requests, and the second screenshot to prove the click landed on the right page. No browser binaries to provision, no a11y snapshot to parse.

Skip it if...

You need Firefox or WebKit (Puppeteer is Chromium-only), or you want the agent to do real form-heavy E2E work — Playwright MCP’s a11y-snapshot model is more reliable than asking a model to interpret a screenshot. In Docker / locked-down envs you’ll also hit the “could not find Chrome” error unless you setPUPPETEER_EXECUTABLE_PATH or pre-install Chromium.

Pricing + hosting cost

All three servers are free and open source. There is no paid tier for any of them and no hosted version to pay for — they all run as local stdio processes spawned via npx. The actual cost is infrastructure:

Disk and memory numbers are approximate orders-of-magnitude from each project’s published install footprints, not a single benchmark run. Your numbers will vary by OS, Node version, and which browsers you actually exercise.

Free and open-source alternatives — Firecrawl, Browserbase, and friends

The three servers in this post all live in the same niche: drive a real browser locally. There’s a parallel category of MCP servers that solve adjacent problems and are worth knowing about — sometimes you don’t need browser automation at all, you just need clean Markdown from a URL, or you can’t run Chrome locally and need a managed cloud session.

Benchmark them yourself

We don’t publish a one-shot latency benchmark in this post. CPU, OS, Node version, network conditions, and target page all affect the result enough that a single run from one machine isn’t representative. Spend fifteen minutes:

# 1. Cold-start time — how long from the first tool call to a
#    rendered page?
time npx chrome-devtools-mcp@latest --version
time npx @playwright/mcp@latest --version
time npx -y @modelcontextprotocol/server-puppeteer --version

# 2. Single-page scrape latency. Pick a stable page (e.g.
#    https://example.com) and measure navigate + snapshot time
#    averaged over 10 calls per server.

# 3. Memory footprint while attached. After connection,
#    /usr/bin/time -l (macOS) or /usr/bin/time -v (Linux) on
#    the spawned node process plus the Chrome PID it controls.

# 4. Error rate on a 100-page sample. Pick 100 URLs from your
#    real workload (sitemap, top traffic, whatever). Run each
#    through navigate + snapshot. Record HTTP errors, JS
#    timeouts, snapshot failures.

# 5. Tool-surface noise. Count tokens used by each server's
#    tool descriptions in the initial system prompt. Bigger
#    surface = more standing context cost per turn.

# Compare:
#   - Chrome DevTools MCP (26 tools, perf traces native)
#   - Playwright MCP (22 tools, a11y default, 3 browsers)
#   - Puppeteer MCP (7 tools, screenshot-only)

The result is workload-specific. Performance-oriented workloads — “why is this page slow” agents — lean toward Chrome DevTools MCP because the trace tools are native. Cross-browser regression checks lean toward Playwright MCP. Quick scrape-and-screenshot scripts lean toward Puppeteer MCP because the surface is small enough that the model rarely picks a wrong tool. Run the methodology, don’t trust ours.

Common pitfalls (regardless of which one you pick)

Community signal

The three servers occupy distinct niches in community discussion. Microsoft’s Playwright MCP gets the most ecosystem amplification on each new Playwright release — the team blogs about it on the official Playwright dev site, and tutorial authors gravitate toward it because Playwright already has the most tested cross-browser story. Chrome DevTools MCP arrived later, and most of the discussion centers on the performance-tracing capability — the ability for an agent to take a Chrome trace, read insights, and patch the responsible source file in a single conversation is the use case people consistently highlight. Puppeteer MCP is treated as the canonical reference: the “hello world” people install first when they want to try MCP, and the implementation people read when they want to understand the protocol.

We’re deliberately not posting verbatim Reddit/HN quotes here because the cluster of unverified “MCP is great” threads runs hot enough that we’d rather under-claim than misattribute. The primary signals to read instead: each project’s GitHub issues queue (it’s where the real complaints live), the Microsoft Playwright team’s release notes, and Google’s Chrome DevTools blog when they ship new tracing primitives.

Frequently asked questions

Sources

Chrome DevTools MCP

• github.com/chromedevtools/chrome-devtools-mcp — README, tool list, Apache 2.0 license
• npmjs.com/package/chrome-devtools-mcp — published package, install metadata
• Chrome DevTools Protocol reference — the underlying transport CDM uses

Playwright MCP

• github.com/microsoft/playwright-mcp — README, install configs, Apache 2.0 license, tool list
• npmjs.com/package/@playwright/mcp — published package, version history
• playwright.dev — Playwright project home, browser-engine docs

Puppeteer MCP

• github.com/modelcontextprotocol/servers — official reference servers monorepo, MIT license
• npmjs.com/package/@modelcontextprotocol/server-puppeteer — published package, install metadata
• pptr.dev — Puppeteer project home (the underlying library)

Internal links

• /servers/chrome-devtools
• /servers/playwright-browser-automation
• /servers/puppeteer
• /servers/firecrawl
• /servers/browserbase
• /blog/what-is-mcp — protocol primer
• /best-mcp-servers — curated roundup

Related comparisons

• Best web-search MCP servers (2026) — when you want answers from the open web rather than to drive a UI.
• Firecrawl vs anycrawl vs crawleo vs Playwright (2026) — placeholder, post in progress — same neighbourhood, different question: scrape and parse vs interactive browser driving.
• Context7 vs DeepWiki vs Ref Tools vs Docfork (2026) — the canonical docs-RAG MCP comparison; same matrix format, different category.
• /compare/chrome-devtools-vs-playwright — the programmatic two-way comparison page that this deep-dive expands on.