Playwright CLI vs MCP vs Chrome DevTools MCP vs Browser Use: How to Choose (2026)

If you give an AI agent a browser in 2026, you are choosing between at least five tools: Playwright MCP, the Playwright CLI, Chrome DevTools MCP, Browser Use and the old Puppeteer MCP server. Most comparisons stop at a feature checklist. That’s the wrong question. The right one is where does your agent run, and what does it need to see? This guide answers that, with numbers I measured myself and a decision table at the end.

The five options in one table

Playwright CLI vs Playwright MCP: the token story has changed

The loudest claim in this space is that the CLI uses roughly a quarter of the tokens MCP does. You’ll see figures like 114,000 tokens for MCP against about 26,000 to 27,000 for the CLI on the same multi-step task. The Playwright project itself leans on the same idea. Its README recommends the CLI with skills for coding agents because CLI commands avoid loading large tool schemas and verbose accessibility trees into context.

That was true of older MCP versions, which returned the full page snapshot inline on every call. It is much less true now.

What I saw when I ran both

I performed the same step in both tools: open the TodoMVC demo, then type into the input box. Here is the MCP response (trimmed) next to the CLI’s:

# Playwright MCP 0.0.84: browser_type
### Ran Playwright code
await page.getByRole('textbox', { name: 'What needs to be done?' }).fill('Buy milk');
await page.getByRole('textbox', { name: 'What needs to be done?' }).press('Enter');
### Page
- Page URL: https://demo.playwright.dev/todomvc/#/
- Page Title: React • TodoMVC
- Console: 1 errors, 0 warnings
### Snapshot
- [Snapshot](.playwright-mcppage-2026-11-06T18-02-01-739Z.yml)

# Playwright CLI 0.1.23: fill e8 "Buy milk"
### Ran Playwright code
await page.getByRole('textbox', { name: 'What needs to be done?' }).fill('Buy milk');
...
- Snapshot: [Snapshot](.playwright-clipage-2026-11-06T18-08-14-645Z.yml)

They are nearly the same thing. Both return the Playwright code that ran, the URL, the title, the console count and a file path to the snapshot, not the snapshot itself. The CLI’s help text even describes itself as “run playwright mcp commands from terminal”. They share an engine.

A third-party re-run points the same way. A DEV Community author benchmarked @playwright/[email protected] against @playwright/[email protected] on a seven-step login flow and reported about 3,580 characters returned by MCP against about 3,620 by the CLI, within roughly 1% of each other. That is one author’s result with no published tokenizer or run count, so treat it as a signal and not a verdict. But it matches what I saw.

So where does the cost actually live?

In the fixed overhead the agent carries before it does anything:

The numbers are in the same ballpark. The structural difference is when you pay. MCP tool definitions are in context from the first message whether you browse or not. The CLI skill is pulled in when the task calls for it, and its reference files only when a specific topic like request mocking or tracing comes up. For a long coding session where the browser is used twice, that matters. For a session that is mostly browsing, it largely washes out.

The differences that are real

• Shell access. The CLI needs one. Claude Desktop and other clients without a shell can only use MCP.
• State. MCP holds a persistent browser inside one long-running server, which suits exploratory loops. The CLI uses named sessions (-s=name); the profile is kept in memory by default and saved to disk with --persistent.
• Scriptability. CLI commands compose in shell scripts and CI. MCP tools exist only inside an agent conversation.
• Visibility. The CLI has playwright-cli show, a dashboard for watching and controlling running sessions.
• Tool surface. The CLI exposes it as commands (open, goto, snapshot, click, fill, find, eval and more) and takes either snapshot refs like e15 or Playwright locators.

# Install the CLI and its skill for your agent
npm install -g @playwright/cli@latest
playwright-cli install --skills

# Then your agent (or you) can run
playwright-cli open https://demo.playwright.dev/todomvc --headed
playwright-cli snapshot
playwright-cli fill e8 "Buy milk"

The Playwright team’s own guidance sums it up: use the CLI for coding agents that can run commands, and MCP for specialized loops that need persistent state, rich page introspection and iterative reasoning, such as exploratory automation, self-healing tests and long-running workflows. One practical reading of that: default to the CLI in a shell-enabled agent, keep MCP configured for the day you need to watch the agent work interactively.

Chrome DevTools MCP vs Playwright MCP

These two are less rivals than neighbors. Chrome DevTools MCP lets an agent control and inspect a live Chrome. Its pitch is depth inside the browser: it records performance traces and extracts insights, analyzes network requests, reads console messages with source-mapped stack traces, takes screenshots and automates actions using Puppeteer under the hood. Performance tools can also fetch Chrome UX Report field data.

Playwright MCP is broader in a different direction: cross-browser coverage, test-oriented tools (locator generation and verification assertions), network mocking, storage control and an extension mode for real tabs.

Three details worth knowing before you install the DevTools server. It officially supports Google Chrome and Chrome for Testing only. Usage-statistics collection is on by default, and you can opt out with --no-usage-statistics. And its performance tools may send trace URLs to Google’s CrUX API unless you pass --no-performance-crux. There is also a --slim flag that exposes a reduced tool set for basic tasks, which helps if the tool-schema overhead is your concern.

You can run both: Playwright MCP to drive the flow, DevTools MCP when a flow reveals something slow. They are separate servers and don’t conflict.

# Chrome DevTools MCP
{ "mcpServers": { "chrome-devtools": { "command": "npx", "args": ["-y", "chrome-devtools-mcp@latest"] } } }

Browser Use vs Playwright MCP: different layers, not rivals

This is the comparison people get most confused by, because the two don’t sit at the same level.

• Playwright MCP is a tool. Your agent (Claude Code, Cursor) is the brain and calls it.
• Browser Use is an agent. It is an open-source Python library with its own loop: you give it a task and a model, and it decides the clicks. Its docs describe three paths: the Python library, a CLI that gives an existing agent such as Claude Code or Codex browser access, and a hosted cloud API.

Browser Use Cloud adds things Playwright MCP deliberately doesn’t try to be: hosted stealth browsers, proxies, CAPTCHA solving and a live-view URL, with browsers priced from $0.02 per browser-hour according to the project’s README. That is a different product category, aimed at agents that run unattended against sites that resist automation.

Because Browser Use is Python, it also fits teams already building on LangChain or similar stacks. If you’d rather keep your own agent and just borrow Playwright’s browser tools inside LangChain or LangGraph, the pillar guide shows the adapter shape.

Playwright vs Puppeteer MCP: it’s mostly settled

The reference Puppeteer MCP server (@modelcontextprotocol/server-puppeteer) offers seven tools: navigate, screenshot, click, hover, fill, select and evaluate. Its repository was archived and made read-only on May 29, 2025. That alone is a reason not to start a new project on it. Set that list against Playwright MCP’s default 25: the Puppeteer server has no snapshot tool, no network inspection, and no tab, dialog or file-upload tools.

Puppeteer itself isn’t dead. Chrome DevTools MCP is built on it. The question is only about the abandoned reference server. If you use “claude code puppeteer” today, the swap is short:

claude mcp remove puppeteer
claude mcp add playwright npx @playwright/mcp@latest

Then replace prompts that said “take a screenshot and describe it” with “snapshot the page and report what you find”. The text snapshot is cheaper and more precise than a screenshot for most questions.

Making Playwright MCP faster and cheaper without switching

A search for “faster alternatives to Playwright MCP” usually has a simpler answer than a new tool. Before you migrate, try the settings that cut the cost of the one you have:

1. Keep the default tool set. Each capability you enable adds definitions. Measured: 25 tools by default, 30 with testing, 42 with storage, 38 with devtools.
2. Omit images for text-only models. --image-responses=omit stops screenshot bytes flowing back when your model can’t use them.
3. Search, don’t re-read. Prompt the agent to use browser_find on large pages instead of re-requesting the whole snapshot. In the third-party re-run mentioned above, a scoped find pulled about 450 characters from a page whose full tree ran to around 97,000.
4. Go headless and isolated. --headless --isolated avoids window rendering and profile locking.
5. Reduce console noise. --console-level=error keeps the agent from reading debug chatter.
6. Split long jobs. One flow per session. Page content accumulates in context.

If you’ve done all that and context is still the bottleneck, that is the signal to try the CLI.

The decision table

Questions people ask when choosing

Sources

• microsoft/playwright-mcp (CLI vs MCP guidance, flags, tools)
• microsoft/playwright-cli (commands, sessions, skills)
• ChromeDevTools/chrome-devtools-mcp
• browser-use/browser-use
• Archived Puppeteer MCP server
• Playwright CLI vs Playwright MCP re-benchmark (DEV Community)
• Ranger: the hidden cost of fewer tokens (runtime, tool-call and cost comparison)