5 Best Playwright MCP Alternatives in September 2026

What Does Playwright MCP Do?

Playwright MCP hands browser automation to an AI agent as a set of callable tools over the Model Context Protocol. The agent does not write Playwright code and run it; it calls navigate, click, or snapshot mid-task, and the browser becomes one more tool in its loop alongside file access or search.

That distinction is the whole reason this category exists, and it is worth separating from the CLI question. A CLI runs when you invoke it; an MCP server sits in the agent context waiting to be called. The setup, tools, and agent workflows for the Microsoft server are covered in the Playwright MCP server guide, and the CLI comparison sits in MCP vs CLI.

Why Look for an Alternative?

Playwright MCP works well on a laptop with a human watching. The reasons teams move off it are rarely that the automation is bad.

• The browser is where the agent is - a local server drives a local Chrome, which stops being available the moment the agent moves into CI or runs as a hosted service.
• Tools cost context - every registered tool occupies part of the context window before the agent does anything, and screenshots consume more.
• Sessions do not persist - a fresh browser each time means logging in again, which is why hosted servers advertise persistent state and stealth handling.
• Private environments need plumbing - reaching staging or localhost from a hosted browser needs a tunnel that a plain local server never had to think about.

The context point is measurable rather than theoretical. Running the Chrome DevTools MCP server locally shows how directly its authors treat it: tool categories can be switched off individually, screenshot format can be forced to JPEG or WebP because those are roughly three to five times smaller than PNG, and a slim mode collapses the whole surface to three tools.

$ npx -y chrome-devtools-mcp@latest --help

  --slim                  Exposes a "slim" set of 3 tools covering navigation, script
                          execution and screenshots only. Useful for basic browser tasks.
  --categoryPerformance   Set to false to exclude tools related to performance.  [default: true]
  --categoryNetwork       Set to false to exclude tools related to network.      [default: true]
  --categoryEmulation     Set to false to exclude tools related to emulation.    [default: true]
  --screenshotFormat      Override the default output format used by take_screenshot.
                          JPEG and WebP are ~3-5x smaller than PNG, which helps reduce
                          context size in AI conversations.  [choices: "jpeg", "png", "webp"]
  --isolated              Creates a temporary user-data-dir that is automatically cleaned up.
  --headless              Whether to run in headless (no UI) mode.  [default: false]

Read that as a design statement rather than a flag list. The server ships with performance, network, and emulation tools switched on, and expects you to turn off whichever ones your agent will never call.

What Are the Best Playwright MCP Alternatives?

The table sorts by the decision that matters first, which is where the browser runs. Tool counts are as documented by each project at the time of writing.

1. Chrome DevTools MCP

The chrome-devtools-mcp repository describes this server as letting a coding agent control and inspect a live Chrome browser, naming Claude, Cursor, and Copilot among the clients. It is published under the ChromeDevTools GitHub organization.

Of the five servers compared in this article, it is the only one that hands an agent the profiler, which is why it leads the list for local work.

Key features:

• Performance traces - the agent can record a trace and extract performance insights, which no other server on this list offers.
• Debugging surface - network requests, console messages, and screenshots are all callable, so the agent sees what a developer would.
• Context controls - the help output above lists per-category toggles, a three-tool slim mode, and a configurable screenshot format, each aimed at what the tool surface costs in context.
• Connects to a running Chrome - browserUrl or wsEndpoint attach to an already-open debuggable instance rather than launching a new one.
• Network restriction - blockedUrlPattern and allowedUrlPattern constrain what the browser is allowed to reach during a run.
• Usage statistics default on - Google collects usage data unless you set usageStatistics to false or the CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS environment variable.

Best fit for: Local development where the agent needs to explain why a page is slow, not only whether it works.

2. Selenium MCP

Maintained by Angie Jones, this server puts Selenium WebDriver behind the protocol, which buys the one thing every Chrome-based option lacks: Safari. It is the widest browser coverage on this list by some distance.

Key features:

• Four browsers - Chrome, Firefox, Edge, and Safari, with Safari requiring macOS and its own driver configuration.
• Eighteen tools - the mcp-selenium repository lists start_browser, navigate, interact, upload_file, execute_script, frame, alert, and cookie handling among them.
• One-line install - claude mcp add selenium adds it through npx with no account to create.
• Real WebDriver semantics - frames, alerts, and cookies behave the way an existing Selenium suite expects them to.
• MIT licensed - free to use and modify, with no hosted dependency.

Best fit for: Teams with a WebDriver estate, and anyone who needs an agent to touch Safari. Our own walkthrough of the protocol sits in Selenium MCP.

3. Kane CLI by TestMu AI

Kane CLI is a browser agent the coding agent calls, and it takes a plain-English objective rather than a sequence of tool calls, so there is no server to configure per client.

The argument Kane CLI makes is about where the reasoning happens. Playwright MCP hands an agent browser primitives and selectors to stitch together, which leaves the agent planning the steps, tracking page structure, recovering stale selectors, and interpreting raw output. Kane CLI moves that work into the tool.

Key features:

• Objectives, not tool calls - the agent passes one plain-English sentence instead of stitching navigate, click, and snapshot together itself.
• No server to configure - it installs as a CLI and as a skill for Claude Code, Cursor, Codex, and Gemini, so there is no per-client MCP configuration to maintain.
• Adapts instead of failing - when the interface moves it re-plans and retries rather than handing a stale selector back to the agent to recover from.
• Returns a verdict, not raw output - a run ends in a verified pass or fail with built-in assertions, video evidence, and a shareable replay link, so the agent does not have to interpret a transcript.
• NDJSON for agents - the agent flag emits one JSON object per event, which is what a coding agent or pipeline parses directly.
• Export to Playwright - a validated flow exports to native Playwright with one command, so choosing it does not strand the work.
• Runs cost credits - the verification below consumed 16.57 credits, which is a per-run cost the local MCP servers here do not have.

Best fit for: Coding agents that should come back with a verdict rather than a transcript to reason over. Setup steps are in the Kane CLI getting started documentation.

Why Choose Kane CLI Over Other Tools?

The other four servers here register a tool surface into the agent context before any work begins, and that surface is the standing cost of having them installed. Kane CLI registers nothing, because the agent calls it as a command and gets back a status field. The chrome-devtools-mcp flags earlier in this article exist to manage that cost, and this is the entry that avoids paying it in the first place.

The run below is real and unedited apart from trimmed file paths. The objective is a negative case, which is the kind of check an agent stitching selectors together tends to get wrong.

$ kane-cli run "Open the Selenium Playground, click Input Form Submit, submit the form with no fields
    filled, and verify a validation message blocks the submission" --agent --headless

{"step":2,"status":"done","remark":"navigate: Navigate to .../selenium-playground/"}
{"step":3,"status":"done","remark":"click: Clicked via DOM locator: internal:role=link[name=\"Input Form Submit\"i]"}
{"step":4,"status":"done","remark":"click: Clicked via DOM locator: internal:role=button[name=\"Submit\"i]"}
{"step":5,"status":"done","remark":"analyze: ANALYZE(textual_visual, 'a validation message blocks submission')"}
{"step":6,"status":"done","remark":"assert: a validation message blocks the submission"}
{"type":"run_end","status":"passed","credits_consumed":16.57,"reason_code":"success.complete",
 "summary":"The form remained blocked and displayed required-field validation, confirming
            that empty submission was prevented."}

No selector was written for that run, and the agent received a status field rather than a page dump to interpret.

4. Mobile MCP

Playwright MCP does not drive native mobile apps, so for that job the alternative is not a better browser server but a different one entirely. Mobile MCP gives an agent iOS and Android through a platform-agnostic interface, covering simulators, emulators, and real devices.

Its design choice is worth borrowing even if you never test mobile. It drives apps from the native accessibility tree rather than from screenshots, which the project describes as fast and cheap because it uses no vision model and no image tokens, falling back to screenshots and coordinates only when it has to.

Key features:

• Accessibility tree first - no vision model and no image tokens on the common path, which is the cheapest way to keep an agent oriented on a screen.
• Four device targets - iOS simulators, iOS real devices, Android emulators, and Android real devices.
• Device and app control - mobile_list_available_devices, mobile_launch_app, mobile_install_app, and mobile_set_orientation cover setup before any interaction.
• Interaction and capture - mobile_click_on_screen_at_coordinates, mobile_swipe_on_screen, mobile_type_keys, plus screenshots, element listing, and screen recording.
• Single-command start - the mobile-mcp repository documents npx -y @mobilenext/mobile-mcp@latest, with no account required.
• Apache-2.0 licensed - permissive, and the project is actively developed.

Best fit for: Any agent whose job reaches a native app, which is the one thing no browser MCP server on this list can do.

5. ExecuteAutomation Playwright MCP

Not every reason to leave Microsoft’s server means leaving Playwright. This is an independent MIT-licensed Playwright MCP that adds test code generation and API testing to the usual browser tools, which suits an agent expected to leave something behind.

Key features:

• Generates test code - the agent can produce a durable test rather than only performing the actions once.
• API testing alongside the browser - the same server covers requests as well as pages.
• Familiar Playwright behaviour - it runs on Playwright, so page semantics match what your suite already does.
• Standard install - published as @executeautomation/playwright-mcp-server and configured through npx like the others.
• MIT licensed and active - independent of Microsoft’s server, with its own release cadence.

Best fit for: Teams who want a different Playwright MCP rather than a different browser engine, especially when the agent should hand back a test.

Which Browser MCP Servers Are No Longer Maintained?

Two servers that still appear in current recommendations have stopped. Both were checked directly rather than taken from a list, and both matter because adopting either means building on something that will not be patched.

• Puppeteer MCP - the reference server in the Model Context Protocol archived servers repository was archived on 29 May 2025 and is read-only. Its README also warns that the server can reach local files and internal IP addresses.
• Midscene MCP - Midscene retired its MCP packages, naming the web bridge, Android, iOS, HarmonyOS, and computer variants, and now directs users to Skills so coding agents drive it through the platform CLIs. Version 1.9.8 is documented as the last release with MCP support.

The Midscene move is the more interesting of the two, because it is a deliberate choice rather than abandonment. That trade between protocol tools and installed skills is worked through in MCP vs agent skills.

How Do You Choose a Playwright MCP Alternative?

Answer where the agent runs first, because that eliminates most of the list before any feature comparison starts.

• The agent runs on a developer machine and the work is debugging. Chrome DevTools MCP, because nothing else here returns a performance trace.
• The agent runs in CI, where no one is watching a browser. Kane CLI fits, because the agent invokes it as a command and gets a pass or fail back rather than a transcript to interpret.
• The task involves Safari or a WebDriver grid you already own. Selenium MCP is the only entry that covers four browsers.
• The job reaches a native app. Mobile MCP, because no browser server here drives iOS or Android at all.
• Context is tight and the agent already has many tools. Prefer a small surface, or run Chrome DevTools MCP in slim mode with unused categories switched off.

One habit is worth adopting whichever you pick. Check the repository before you wire a server in, because two widely recommended ones have already stopped, and a roundup written six months ago will not tell you that.

Conclusion

Start by writing down what your agent is meant to hand back. If it is debugging evidence from a page, add Chrome DevTools MCP today and turn off the tool categories you will not call. If it is a pass or fail your pipeline can act on, the tool calls are the wrong shape and Kane CLI is the shortlist.

For an agent that should hand back a verified result rather than a transcript, install Kane CLI with npm install -g @testmuai/kane-cli and give it one objective; the Automation MCP server documentation covers the MCP route if you would rather register a server. If you are assembling a wider agent toolkit rather than replacing one browser server, the MCP servers for test automation roundup covers the non-browser pieces such as source control, error tracking, and documentation.