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 28,000+ GitHub stars, 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. 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 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 extension. Multiple paths to handle the “stay logged in” problem.

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. Claude Code, Cursor, Windsurf, Gemini CLI — everyone points to Playwright MCP as the browser server to use. 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. There’s no built-in pagination or size limiting yet.

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 --isolated flag helps (fresh context per session), but running parallel browser agents 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.

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: Microsoft’s own README acknowledges this alternative. Instead of MCP tools, you give the agent Playwright CLI access and skill files. This uses fewer tokens (no large tool schemas or accessibility trees in context) and is better for coding agents that generate and run scripts. MCP is better for exploratory, iterative workflows where the agent needs to navigate and react in real time. Choose based on your use case.

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