6 most popular Playwright MCP servers for AI testing in 2026

tldr: Playwright MCP lets AI agents control browsers for testing. Dozens of servers exist. These six dominate by actual usage. Microsoft leads, but the others solve problems it doesn't.

Microsoft's Playwright MCP launched in 2025. Within months, five serious alternatives appeared. Each one exists because Microsoft's server made a trade-off someone disagreed with.

Pick wrong and you'll waste weeks. I've seen teams choose Cloudflare's server for local development (bad idea), or stick with Microsoft when they're burning tokens (expensive mistake).

The biggest Day 2 problem? Authentication. Testing behind a login wall breaks most AI agents. They re-authenticate on every run, hit rate limits, trigger security alerts. Session persistence separates the servers that work in production from demo toys.

The second problem: Shadow DOM. This is the silent killer of AI testing in 2026. Modern design systems like Shoelace, Lit, and corporate component libraries hide elements inside shadow roots. Accessibility tree snapshots can't see them. The AI clicks "nothing" because the button is nested three shadow layers deep. If your app uses Web Components, only servers with raw JS access (playwriter, playwrightess-mcp) can pierce through with selectors like page.locator('my-component').locator('internal::shadow=button').

The third problem: Security. You're giving an AI full browser access. It can navigate anywhere, read any page, potentially exfiltrate data or hit internal endpoints. Some servers offer sandboxing. Most don't. Know your risk profile before deploying.

The fourth problem: Human handoff. AI agents hit walls. CAPTCHAs. MFA prompts. Unexpected modals. The 2026 pattern is "pause and attach" where a human takes over the session, solves the blocker, then hands back to the AI. Not every server supports this.

The fifth problem: Model lock-in. Teams swap between Claude 4, GPT-5, and Llama 4 constantly. Some servers assume vision capabilities. Others require code generation skills. Pick a server that matches your model rotation strategy.

Quick comparison

1. microsoft/playwright-mcp

Weekly installs: 250K+

The official server from Microsoft. Works with VS Code, Cursor, and Claude Desktop out of the box. Uses accessibility tree snapshots instead of vision models. Over 25 tools for browser control.

Frankly, it's overkill for 90% of UI tests. But nobody gets fired for choosing Microsoft. If you're evaluating options for your team, this is the safe default.

Key differentiator: Accessibility tree approach. 2-5KB of structured data per interaction instead of 500KB screenshots. But in 2026, that's not the whole story.

Hybrid mode: The 2026 update added --vision auto. Uses accessibility tree for 90% of interactions to keep latency low. Automatically switches to vision for <canvas> elements, WebGL, complex data visualizations, and anything the tree can't parse. You get fast responses most of the time, with vision as a fallback when needed.

Model agnostic: Pure tree mode works with any reasoning model. Hybrid mode requires vision capabilities (Claude, GPT-5). If you're on open-source models without vision, stick to tree-only.

Shadow DOM caveat: Accessibility snapshots can miss elements inside shadow roots. If your app uses Web Components or Shadow DOM-heavy design systems, test carefully. Some elements may appear invisible to the AI.

Best for:

• Teams new to Playwright MCP
• VS Code and Cursor users
• Multi-browser testing (Chrome, Firefox, WebKit)
• CI/CD integration

Trade-offs:

• Heavier context usage than alternatives
• Full browser instance per session
• No Chrome extension mode

Auth handling: Supports --user-data-dir for persistent browser profiles. Save login state once, reuse across sessions. No re-authentication on every run.

Security: Supports --allowed-origins to restrict navigation to specific domains. Can run headless to prevent visual data leakage. No built-in network isolation. For high-security environments, run behind a proxy or in a container.

Human handoff: Run in headed mode (not headless) to watch the browser. No built-in pause mechanism, but you can see what's happening. For CAPTCHAs, you'll need to solve them manually in the visible browser window while the AI waits.

Setup:

# Claude Code
mcp add playwright -- npx @playwright/mcp@latest --user-data-dir ./browser-data

# Or with bun (faster install)
mcp add playwright -- bunx @playwright/mcp@latest --user-data-dir ./browser-data

GitHub: microsoft/playwright-mcp

2. remorses/playwriter

Weekly installs: 45K+

This is the one I actually use day-to-day.

Controls your existing Chrome tabs via a browser extension. Runs Playwright code in a stateful sandbox. The single execute tool wraps the entire Playwright API.

Key differentiator: 80% less context means faster responses. One tool instead of 25+. In 2026, tokens are cheap but latency kills. Large contexts slow your agent down. playwriter keeps things fast.

Shadow DOM advantage: This is why many teams switch from Microsoft. Full Playwright API means the AI can write page.locator('my-button').locator('internal::shadow=span') to pierce shadow roots. Accessibility-based servers literally can't see these elements. If your app uses Shoelace, Lit, or any component library with Shadow DOM, playwriter is often the only option that works.

Model agnostic: Requires models that can write Playwright code. Works great with Claude and GPT-5. Smaller models may struggle with complex selectors.

Best for:

• Teams optimizing for response speed
• Working with existing browser sessions
• Developers who want full Playwright API access
• Remote browser control via CDP relay

Trade-offs:

• Requires Chrome extension installation
• Chrome only (no Firefox or WebKit)
• Less structured than Microsoft's approach

Auth handling: Best-in-class. Controls your actual Chrome browser with existing sessions. Already logged into Slack, GitHub, your internal tools? The AI sees them logged in too. Zero auth setup.

Security: Lowest isolation. The AI has access to your real browser profile. All your logged-in sessions, bookmarks, history. Don't use on machines with sensitive credentials. Consider a dedicated Chrome profile for AI automation.

Human handoff: This is the only server that natively supports the 2026 "pause and attach" pattern. Because it controls your actual Chrome window, the AI can literally stop mid-test, ask you to solve a CAPTCHA, and watch you do it in real-time. No session transfer. No browser handoff. You solve the blocker in the same tab the AI is using. It sees the solved state immediately and continues. Every other server requires workarounds or doesn't support human intervention at all.

Setup:

mcp add playwriter -- bunx playwriter-mcp

GitHub: remorses/playwriter

3. jae-jae/fetcher-mcp

Weekly installs: 12K+

Built for reading the web, not testing it. Uses Playwright headless browser with Mozilla's Readability algorithm for content extraction. Processes multiple URLs in parallel.

Honestly, this barely belongs in an "AI testing" article. But teams keep asking about it, so here it is. If you're scraping, not testing, this is clean and fast.

Key differentiator: Content extraction focused. Blocks images, fonts, and unnecessary resources automatically.

Best for: Scraping, research automation, content aggregation. Not testing.

The trade-off is the feature: Read-only by design. No form filling, no clicks, no state changes. This is the safest MCP server precisely because it can't do much. If security is your top concern and you just need to read pages, start here.

Setup:

mcp add fetcher -- bunx fetcher-mcp

GitHub: jae-jae/fetcher-mcp

4. cloudflare/playwright-mcp

Weekly installs: 8K+

Microsoft's server forked for Cloudflare Workers and Browser Rendering API. Optimized for serverless deployment and edge computing.

The papercut: setting it up still requires wrestling with Wrangler environment variables. If you're not already comfortable with Cloudflare's tooling, budget extra time.

Key differentiator: Runs on Cloudflare's edge network. No server management.

Best for: Teams already on Cloudflare who want browsers running at the edge. If that's not you, skip this one.

Security tip: This is the only server on the list with network isolation out of the box. The browser runs on Cloudflare's infrastructure, not your network. It physically cannot hit your internal metadata endpoints, company wikis, or AWS instance roles. In 2026, security teams are blocking MCP servers that have full network access. If your infosec team is nervous about AI agents on the corporate network, Cloudflare's isolation model is the answer.

The real trade-off: Stateless by design. Each request starts fresh. Strong security isolation, but no human handoff possible. Browser runs remotely. You can't see it or take over when things go wrong.

Setup:

# Requires Cloudflare account and Browser Rendering enabled
npx wrangler deploy

GitHub: cloudflare/playwright-mcp

5. terryso/claude-code-playwright-mcp-test

Weekly installs: 5K+

This one is polarizing. It bets that YAML is the right abstraction for test specs. You write natural language steps, the framework figures out element targeting.

I'm genuinely unsure if this is the future or a dead end. YAML-as-test-spec has failed before. But the dynamic element identification is clever. No CSS selectors to maintain. Tests describe intent, not implementation. When your UI changes, the framework adapts instead of breaking.

The catch: it's Claude Code specific. If you're not already in that ecosystem, the value proposition disappears. And the community is small. When you hit edge cases, you're mostly on your own.

One thing it does well: session persistence. Login once, save the browser state, skip auth on subsequent runs. Claims 80-95% faster execution after initial setup. If you're running the same test suite repeatedly, that adds up.

Worth trying if you hate writing Playwright code and want to see if declarative testing works for your use case. Not for everyone.

bun install -g claude-test
mcp add playwright -- bunx @playwright/mcp@latest

GitHub: terryso/claude-code-playwright-mcp-test

6. mitsuhiko/playwrightess-mcp

Weekly installs: 2K+

Armin Ronacher built this. He created Flask. When Armin releases something, even a "small experiment," it's usually worth paying attention.

The idea is almost aggressively simple: one tool, playwright_eval, that executes JavaScript in a persistent environment. No tool proliferation. No abstractions. You write Playwright code, it runs. State survives between calls.

Why does that matter? Because every other server resets between interactions. playwrightess lets you build up complex scenarios incrementally. Store a reference to a shadow host. Reuse it ten calls later. Set up a complicated auth flow piece by piece, debugging as you go. When you're stuck on something the other servers can't handle, this is where you end up.

The downside is obvious: it's experimental. Documentation is sparse. There are no guardrails. If you don't already think in Playwright, this will be frustrating. But if you do, the persistent JS environment is genuinely powerful. It's the escape hatch for edge cases.

Also useful if you want to understand how MCP servers work. The code is clean and readable. Good learning material.

mcp add playwrightess -- bunx playwrightess-mcp

GitHub: mitsuhiko/playwrightess-mcp

How to choose

The 2026 verdict: If you're building in a standard corporate CI/CD environment, stick with Microsoft. It's the standard library of MCP. But if you're running agents on a loop and your API latency is killing productivity, the 80% context savings from playwriter isn't a luxury. It's a requirement. For teams moving toward agentic web scraping rather than pure QA, fetcher-mcp is the only one that doesn't get tripped up by heavy JS frameworks.

That's the short version. Here's the longer decision guide:

Agent responses too slow? playwriter. 80% smaller context means faster inference. Tokens are cheap in 2026. Latency isn't.

Shadow DOM everywhere? This is non-negotiable. If your app uses Shoelace, Lit, or any modern component library, Microsoft's server will fail silently. The AI will report "element not found" on buttons that are clearly visible. playwriter or playwrightess-mcp are your only options. They can pierce shadow roots with raw JS selectors.

CAPTCHAs and MFA blocking tests? playwriter is the only option with native human intervention. The AI stops, you solve the blocker in your actual Chrome, it watches and continues. No session export, no browser switching. This is the 2026 "pause and attach" pattern, and only playwriter supports it out of the box.

Security team nervous? fetcher-mcp if you only need to read. Cloudflare's server if you need interaction but want true network isolation. It's the only option where the browser physically can't reach your internal network. No AWS metadata endpoints, no internal wikis, no accidental SSRF.

Already deep in Cloudflare? Their fork makes sense. For everyone else, it's extra complexity for no benefit.

Hate writing Playwright code? Try terryso's YAML framework. I'm skeptical of YAML-as-test-spec, but some teams love it.

Swapping models frequently? Microsoft's server. Text-based accessibility data works with any reasoning model. No vision required. Most portable.

Nothing else works? playwrightess-mcp. Armin's experiment is the escape hatch when you need raw control.

Don't want to manage any of this? These servers are infrastructure. They give you browser control, not test intelligence. You still need to figure out what to test, maintain tests when UI changes, and verify bugs are real. If you want the natural-language-to-Playwright workflow without the MCP plumbing, Bug0 Studio generates tests from plain English. If you'd rather skip the infrastructure layer entirely, Bug0 Managed QA handles test creation, maintenance, and verification. Different trade-off: less control, less maintenance.

FAQs

What is Playwright MCP?

Playwright MCP is a Model Context Protocol server that connects AI agents to Playwright's browser automation. It translates AI commands into browser actions. No vision models required. The AI reads structured accessibility data instead of screenshots.

Which Playwright MCP server should I start with?

Start with microsoft/playwright-mcp. It's the official server with the most documentation and community support. Works with VS Code, Cursor, and Claude Desktop. Graduate to specialized servers when you hit specific constraints.

Why is playwriter faster than Microsoft's server?

Context size drives inference latency. playwriter uses a single execute tool that wraps the entire Playwright API. Microsoft's server exposes 25+ separate tools. Each tool definition adds to context. One flexible tool means 80% less data per request, which means faster agent responses. In 2026, tokens are cheap. Latency is the bottleneck.

Can I use multiple Playwright MCP servers together?

Yes. MCP servers are independent processes. You can run Microsoft's server for general automation and fetcher-mcp for content extraction in the same project. Configure each in your MCP settings.

What's the difference between Playwright MCP and managed testing platforms?

Playwright MCP is infrastructure. You get browser control, but you build everything else: test logic, maintenance, flake detection. Managed platforms handle the full stack. Bug0 Studio sits in the middle: you describe tests in plain English, it generates Playwright code. Bug0 Managed QA goes further with a forward-deployed team handling everything. QA Wolf and others offer similar full-service models. Trade-off is control vs. maintenance burden. Most teams start with MCP to learn, then evaluate managed options when maintenance costs spike.

Is Cloudflare's Playwright MCP only for Cloudflare users?

Primarily, yes. It's optimized for Cloudflare Workers and their Browser Rendering API. If you're not already on Cloudflare infrastructure, use microsoft/playwright-mcp instead. The fork doesn't add value outside Cloudflare's ecosystem.

How do I handle authentication with Playwright MCP?

The simplest path: use --user-data-dir with Microsoft's server to persist browser profiles. Login once, reuse forever. Even easier with playwriter since it controls your actual Chrome where you're already logged in. For CI pipelines, store auth cookies or tokens and inject them at session start. The goal is never re-authenticating on every test run.

Which Playwright MCP handles Shadow DOM best?

Servers with full Playwright API access handle Shadow DOM better. playwriter and playwrightess-mcp can use Playwright's shadow-piercing selectors directly. Microsoft's accessibility tree approach sometimes misses elements inside shadow roots. If your app uses Web Components or Lit, test with playwriter first.

How do I secure Playwright MCP in production?

At minimum, use --allowed-origins to keep the agent on approved domains. For real production safety, run the browser in a container with no internal network access. If you're using playwriter, create a dedicated Chrome profile without your real credentials. But if your security team wants true isolation, Cloudflare's server is the only option where the browser physically can't reach your internal network. No AWS metadata endpoints, no accidental SSRF. fetcher-mcp is also safe since it's read-only by design.

How do I handle CAPTCHAs and MFA with Playwright MCP?

playwriter is the only server with native "pause and attach" support. The AI controls your actual Chrome. When it hits a CAPTCHA, it stops and waits. You solve it in the same browser window. The AI watches you complete it and continues automatically. No session export, no tab switching. For Microsoft's server, you can run headed mode and manually intervene, but it's clunkier. The AI doesn't "see" your intervention the same way. Cloudflare's remote browser doesn't support human handoff at all.

Which Playwright MCP works with Claude, GPT-5, and Llama 4?

Microsoft's server is the most portable. It uses accessibility tree data (text-based), so any reasoning model works. playwriter requires models that can write Playwright code. Claude and GPT-5 handle this well. Smaller open-source models may struggle with complex selectors. If you're rotating models frequently, stick with Microsoft's server for consistency.