The Playwright MCP Server — The New Standard for Browser Automation

If you read our Puppeteer MCP review, you know the punchline: Playwright MCP has overtaken it for most use cases. Now it’s time to explain why. The Playwright MCP server (@playwright/mcp) is Microsoft’s official MCP interface for browser automation, maintained by the same team that builds Playwright itself. It has 30,900+ GitHub stars, 2,500+ forks, 519+ commits, support from 15+ MCP clients, and one architectural decision that changes everything: the accessibility tree.

Instead of making agents craft CSS selectors to target page elements, Playwright MCP represents pages as structured accessibility trees — semantic labels like “Submit button” and “Email input” that agents can reference by stable IDs. This single design choice makes browser automation dramatically more reliable for AI agents. Part of our Developer Tools MCP category. Here’s the full picture.

What It Does

The server exposes 25+ tools organized into capability tiers:

Core tools (always available):

• browser_navigate / browser_navigate_back — Navigate to URLs and go back in history.
• browser_snapshot — Capture the page’s accessibility tree. This is the primary way agents “see” the page — no screenshots or vision model needed.
• browser_click — Click elements by accessibility tree reference (not CSS selector).
• browser_type — Type text into editable elements.
• browser_fill_form — Fill multiple form fields at once. No more field-by-field workflows.
• browser_select_option / browser_hover / browser_drag — Standard interactions.
• browser_press_key — Send keyboard events (Enter, Escape, shortcuts).
• browser_take_screenshot — Visual capture when the accessibility tree isn’t enough.
• browser_evaluate / browser_run_code — Execute JavaScript or Playwright code snippets.
• browser_file_upload — Upload files directly. (Puppeteer doesn’t have this.)
• browser_handle_dialog — Manage alerts, confirms, and prompts.
• browser_wait_for — Wait for text to appear or a timeout.
• browser_tabs — List, create, close, and switch between tabs.
• browser_network_requests / browser_console_messages — Monitor network traffic and console logs.

Vision mode (--caps=vision): Adds coordinate-based mouse tools — click, move, drag, scroll at pixel coordinates. For canvas elements, complex custom widgets, or anything the accessibility tree misses.

Testing mode (--caps=testing): Adds assertion tools — verify element visibility, check text presence, validate form values. Useful for QA automation workflows.

PDF mode (--caps=pdf): Save pages as PDF files.

Code generation (--codegen=typescript): Records agent actions and outputs reproducible Playwright test scripts. Turn an agent session into a test suite.

Setup

For Claude Desktop, add this to your config:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

VS Code, Cursor, and most other MCP clients use the same format. Many have one-click install buttons in the Playwright MCP README. The server requires Node.js 18+ and downloads the browser binary on first run.

Key configuration flags:

• --browser chromium|firefox|webkit — Choose your browser engine (Chromium is default).
• --headless — Run without a visible window (default). Omit for headed mode.
• --caps=vision,pdf,testing — Enable capability extensions.
• --viewport-size=1280x720 — Set viewport dimensions.
• --device="iPhone 15" — Emulate a device.
• --storage-state=auth.json — Load saved authentication state.
• --user-data-dir=./profile — Use a persistent browser profile.
• --allowed-origins / --blocked-origins — Network security controls.
• --save-trace — Save Playwright traces for debugging.

All flags are also available as environment variables (PLAYWRIGHT_MCP_HEADLESS=true, etc.).

Setup difficulty: Easy, but more to learn. The basic config is one npx command — same as Puppeteer. But there are 60+ configuration options. You don’t need most of them to start, but the surface area is larger than simpler MCP servers.

What’s New (January–April 2026)

The Playwright MCP server has shipped 20+ releases since our original review, now at v0.0.70. The January–March features remain significant, and the March–April updates bring Playwright 1.59 integration that changes how agents use browsers.

April 2026: Playwright 1.59 Integration

Playwright 1.59 — the agent-native release (April 1, 2026). The underlying Playwright framework shipped three features that fundamentally improve MCP workflows:

• browser.bind() API — Share a single launched browser across @playwright/mcp, @playwright/cli, and other Playwright clients simultaneously. Named pipe and WebSocket binding options. This means an agent can start a browser via MCP and a human can inspect it in the dashboard, or multiple tools can collaborate on the same browser session.
• page.screencast API — Unified video capture with action annotations, visual overlays, chapter titles, and real-time frame streaming. Agents can produce annotated walkthrough videos as “receipts” for human review — recording exactly what they did, with highlighted interactions and chapter markers. This is a major accountability feature for autonomous agent workflows.
• Observability Dashboard — Run playwright-cli show to see all bound browsers, their statuses, and access DevTools for background browser inspection. Manual intervention into agent sessions is now built-in.
• CLI Debugger for agents — npx playwright test --debug=cli attaches a CLI debugger to tests, enabling automated test-fixing workflows.
• CLI Trace Analysis — npx playwright trace commands let agents explore traces and diagnose failing or flaky tests from the command line.
• Browser versions: Chromium 147, Firefox 148, WebKit 26.4.

v0.0.70 (April 1). Maintenance release aligned with the Playwright 1.59 branch point.

v0.0.69 (March 30). Two new tools and several enhancements:

• browser_network_state_set — Toggle network offline mode for connectivity testing. Agents can now simulate offline conditions without external tools.
• browser_video_chapter — Full-screen chapter markers with blurred backdrop for video recordings. Combined with the screencast API, this enables professional-grade agent session documentation.
• browser_mouse_click_xy enhanced with button, clickCount, and delay options.
• browser_network_requests now supports filtering with optional headers/body fields.
• Non-ref selectors now accept plain CSS and text selectors alongside aria-ref handles — agents are no longer locked into accessibility references only.
• 10 bug fixes including iframe verification, Chromium lock file handling, Unicode characters, Node.js 18 compatibility, and context isolation.

January–March 2026 (still relevant)

@playwright/cli — the 4x token-saving companion. Microsoft released @playwright/cli as a standalone companion tool that uses plain shell commands instead of the MCP protocol. MCP streams entire accessibility snapshots into the LLM’s context window; CLI saves them to disk. The Playwright team’s benchmarks: ~114,000 tokens via MCP versus ~27,000 via CLI — roughly a 4x reduction. Use CLI when your agent has filesystem access (Claude Code, Copilot, Cursor); use MCP when it doesn’t (Claude Desktop, web-based clients). The CLI exposes 50+ commands with persistent session configuration via playwright-cli.json.

Network mocking (v0.0.63). Route requests by URL pattern, mock responses with custom status codes, bodies, and headers. Agents can test against simulated API responses without modifying backend code.

Browser storage control (v0.0.63). Full state management: save and load browser state, manipulate cookies, access Web Storage APIs (localStorage, sessionStorage).

Incognito by default (v0.0.64). Browser profiles are now ephemeral by default — no leftover state from previous sessions.

Session management overhaul (v0.0.64). Sessions are binary: running or gone. Workspace-scoped daemons prevent cross-project interference.

Video recording (v0.0.62). video-start and video-stop commands capture browser sessions as video files.

Playwright MCP Bridge extension (v0.0.67). Chrome Web Store extension for connecting to existing authenticated browser sessions.

GitHub Copilot auto-integration. Playwright MCP is now configured automatically for GitHub Copilot’s Coding Agent — no manual setup required. The agent can read, interact with, and screenshot web pages hosted on localhost during code generation.

What Works Well

Accessibility tree targeting is a game-changer for agents. This is the headline feature, and it delivers. Instead of the agent needing to figure out that the login button is button.btn-primary-2x.auth-submit, it sees “Submit [button, ref=s3e45]” in the accessibility snapshot and references it by ID. This is deterministic, immune to CSS class changes, and doesn’t require a vision model. It’s the reason Playwright MCP is more reliable than Puppeteer MCP for complex, dynamic web applications.

Three browser engines, one API. Chromium, Firefox, and WebKit. Switch with a single flag. This matters for cross-browser testing and for sites that behave differently across engines. Puppeteer gives you Chrome and nothing else.

The tool set is comprehensive. 25+ tools cover the full range of browser automation needs. File uploads, dialog handling, tab management, form bulk-fill, keyboard events, network monitoring — Puppeteer MCP has 7 tools. The gap is significant. You rarely hit a wall where you need to drop into raw JavaScript.

Code generation bridges agent work and test suites. The --codegen=typescript flag records agent actions as reproducible Playwright test scripts. An agent debugging a workflow can produce a test that captures exactly what it did. This is a unique capability no other browser MCP server offers.

Incremental snapshots reduce token usage. By default, subsequent browser_snapshot calls only return the parts of the accessibility tree that changed. This is a thoughtful optimization for LLM-based agents where every token counts.

Session persistence is well-designed. Save authentication state with --storage-state, use persistent browser profiles with --user-data-dir, or connect to existing authenticated browser sessions via the Playwright MCP Bridge Chrome extension. The new browser storage control tools (v0.0.63) add cookie management and Web Storage APIs for even finer-grained state manipulation. Multiple paths to handle the “stay logged in” problem.

Network mocking unlocks test scenarios. Since v0.0.63, agents can mock API responses by URL pattern — no backend changes needed. This means an agent can test error handling, simulate slow responses, or verify UI behavior against specific data shapes, all without touching production infrastructure.

Screencast and bind bring accountability to agent workflows. Playwright 1.59’s page.screencast API lets agents produce annotated video recordings with action highlights and chapter markers — visual proof of what the agent did. The browser.bind() API means a human can inspect an agent’s browser session in real time via the observability dashboard (playwright-cli show). These aren’t just nice-to-haves: for production agent workflows, having an audit trail and the ability to intervene is table stakes.

The ecosystem support is unmatched. 15+ MCP clients have explicit installation instructions. VS Code uses it as the example MCP server in their quickstart docs. GitHub Copilot now auto-configures it. Claude Code, Cursor, Windsurf, Gemini CLI — everyone points to Playwright MCP as the browser server to use. PulseMCP ranks it #1 globally with 40.5 million all-time visitors. This matters for documentation, community support, and long-term maintenance.

What Doesn’t Work Well

Accessibility tree snapshots can be enormous. This is the primary practical limitation. Complex pages with deep DOM trees produce massive snapshots — potentially thousands of tokens per capture. Users have reported snapshots that overwhelm context windows. The incremental mode helps on subsequent calls, but that first full snapshot of a complex page is expensive. The new @playwright/cli companion mitigates this by saving snapshots to disk instead of streaming them into context — but that requires filesystem access, so it’s not a universal fix.

Not everything appears in the accessibility tree. Canvas elements, complex custom widgets, SVG-heavy interfaces, and elements without semantic ARIA markup may be invisible in snapshots. You need to fall back to vision mode (--caps=vision) or browser_evaluate for these. The accessibility tree is powerful, but it’s not a complete representation of every page.

Configuration complexity can overwhelm. 60+ options is a lot. For someone who just wants “give my agent a browser,” the number of flags, capabilities, and modes creates decision fatigue. The defaults are sensible, but the docs are dense. Puppeteer MCP’s “install and go” simplicity has real appeal by comparison.

Still v0.0.x — expect breaking changes. The rapid release cadence (multiple versions per week) means the API is still evolving. Pinning a version for stability is wise. The version number is honest: this is early, active development. It works well in practice, but upgrading requires attention.

Browser lock errors in multi-agent setups. If multiple agents or sessions try to share the same browser instance, you’ll hit “browser is already in use” errors. The v0.0.64 session overhaul (workspace-scoped daemons, incognito-by-default) helps significantly, but running parallel browser agents still requires careful configuration.

The “controlled by automated test software” banner. Chrome displays this warning in headed mode. It’s cosmetic, but it can confuse users watching an agent work and may interfere with certain screenshot-based workflows where the banner appears in captures.

Process leaks in long-running integrations. OpenAI Codex users reported (#17832) 213 leaked Playwright MCP process pairs consuming 13.6 GB of RSS. The issue is in the host’s subagent lifecycle management, not in Playwright MCP itself — but it highlights a real operational concern: any MCP client that spawns stdio processes must properly reap them. If you’re running Playwright MCP in a long-lived process, monitor for orphaned children.

Windows and WSL compatibility issues. Users on Windows and WSL report installation problems and connection errors. If you’re on Linux or macOS, you’re fine. Windows support is improving but less polished.

Compared to Alternatives

vs. Puppeteer MCP Server: The most direct comparison, and we covered it extensively in that review. Summary: Playwright wins on element targeting (accessibility tree vs. CSS selectors), browser support (three engines vs. one), tool count (25+ vs. 7), and ecosystem adoption. Puppeteer wins on simplicity (fewer options, smaller surface area) and stability (mature, rarely changes). For new projects, start with Playwright. For quick one-off browser tasks where you want the simplest possible setup, Puppeteer still has a place.

vs. Browserbase MCP Server: Browserbase runs browsers in the cloud — no local Chromium process eating your RAM. Better for production workloads, CI/CD, and environments where you can’t install a browser. Playwright MCP is better for local development, testing, and workflows where you need fine-grained control. Different trade-offs: convenience vs. control.

vs. Firecrawl MCP Server: Firecrawl extracts clean content from web pages. If you just need to read a webpage, Firecrawl is more efficient — no browser process, lower resource usage, structured output. Playwright is for when you need to interact: click, type, navigate multi-step flows. Use both: Firecrawl for content extraction, Playwright for interaction.

vs. @playwright/cli (SKILLS approach): Now an officially published companion package. The CLI saves snapshots and screenshots to disk instead of streaming them into context, cutting token usage by ~4x (27K vs. 114K tokens per typical task). It exposes 50+ commands and supports persistent sessions via playwright-cli.json. With Playwright 1.59’s browser.bind(), CLI and MCP can now share the same browser session — use MCP for the initial setup and CLI for subsequent low-token interactions. Use CLI when your agent has filesystem access (Claude Code, Copilot, Cursor); use MCP when it doesn’t (Claude Desktop, web-based clients).

vs. Cloudflare Playwright MCP: Cloudflare maintains a fork (@cloudflare/playwright-mcp) that runs browsers in Cloudflare’s Browser Rendering infrastructure. Cloud-hosted, no local browser process. Currently synced to upstream v0.0.30, so it lags behind on features (no video recording, no network mocking, no v0.0.69 tools). Better for serverless deployments and environments where you can’t install a local browser. The official Playwright MCP is better for local development, full feature access, and keeping up with the rapid release cadence.

Who Should Use This

Yes, use it if:

• You need reliable browser automation for dynamic web applications
• Cross-browser testing matters (Firefox, WebKit support)
• You’re using Claude Code, Cursor, VS Code, or another MCP client that recommends it
• You want to turn agent sessions into reproducible test scripts
• You need file uploads, tab management, or other capabilities beyond basic navigation
• You’re building production-grade agent workflows that interact with the web

Consider Puppeteer MCP instead if:

• You want the absolute simplest browser setup with minimal configuration
• You’re doing basic browser tasks (navigate, screenshot, click) and don’t need the full tool set
• You prefer stability over features — Puppeteer MCP changes rarely

Skip browser MCP entirely if:

• You just need to read web page content (use Firecrawl or a fetch server)
• You’re on a constrained server with limited RAM
• Your target sites aggressively block automated browsers

This review was last edited on 2026-04-16 using Claude Opus 4.6 (Anthropic).