Playwright vs Cypress vs Selenium in 2026: the MCP axis nobody charts

An MCP (Model Context Protocol) server is the bridge an AI agent uses to take real actions inside a tool. For testing, that means the agent calling navigate, snapshot, click, or type_text and the framework actually executing those calls against a real browser. 'First-party' means the framework's own maintainers ship and own the MCP. As of May 2026, only Playwright has one of those: @playwright/mcp on the microsoft/playwright-mcp GitHub repo. Cypress has an official Cloud MCP, but it queries Cypress Cloud test results (flaky tests, run statuses, Test Replay links); it does not click buttons in your app. The proposal to add a first-party browser-driving Cypress MCP is open as Issue #33412 on cypress-io/cypress and not yet shipped. Selenium has no first-party MCP. There are community implementations (Angie Jones's mcp-selenium, naveenanimation20/selenium-mcp, others on PyPI), but the Selenium project itself does not maintain one. If your 2026 plan is to layer an AI agent on top, the framework you pick is the framework whose vendor already ships the MCP.

Because the bottleneck moved. In 2018 the bottleneck was 'can I run my tests on Firefox' and Selenium won. In 2021 the bottleneck was 'can I write a test without flaky waits' and Playwright won. In 2026 the bottleneck is 'how much human time goes into authoring and maintaining selectors' and the answer is an AI agent that calls real framework primitives off a plain English plan. That answer needs an MCP. Browser support is now table stakes (all three cover Chromium; Playwright adds WebKit and Firefox). Language bindings are mostly solved (TypeScript/JS for Playwright and Cypress, polyglot for Selenium). Parallel execution is solved (every framework parallelizes, every CI runner shards). The new axis differentiates because only one of the three has it.

Cloud MCP counts for what it does, which is read-only access to your existing Cypress Cloud run history. The blog post and docs are explicit: an AI agent connects to the Cypress Cloud MCP endpoint and queries run statuses, flaky tests, and Test Replay links. It is observability for the run, not control of the browser. To make Cypress click buttons via an agent in 2026 you have to write or adopt a community MCP. The proposal for an official @cypress/mcp that drives the browser is Issue #33412 and is open. So the honest summary is: Cypress has the official MCP for the runs you have already executed, not for the runs you want an agent to execute next.

You can get the rough outcome: an agent issues click and type calls, Cypress executes them. The difference is the warranty. yashpreetbathla/cypress-mcp and jprealini/cypress-mcp are MIT-licensed community projects, maintained by individuals, with no SLA. When Cypress 14 ships and changes a runner internal, those repos may or may not adapt. @playwright/mcp is published on the same npm namespace as @playwright/test, lives in the same GitHub org, and ships from the same release engineering team. That is the security argument for the framework choice in 2026: not 'who has features today' but 'who is on the hook to keep MCP working when their next major version drops'.

It is a real architectural constraint. Cypress runs the test runner inside the browser as a same-origin iframe alongside your app, which gives Cypress its time-travel debugger and synchronous-feeling commands. An MCP server is a separate process that talks to the AI agent over stdio. To bridge the two you need either a browser-extension shim (the Cloud MCP path is HTTP, not browser-side) or a HTTP/WebSocket plug into the runner. Both are doable; both are why the proposal is still open in May 2026 instead of shipped. Playwright's architecture is the inverse: the runner is out-of-process, controlling the browser through CDP. Wrapping that in MCP was straightforward enough that Microsoft shipped @playwright/mcp v0.0.70 with the snapshot, click, type_text, and select_option primitives all backed by Playwright locator calls.

Selenium is still the right answer when you need WebDriver-protocol cross-language reach (Java, Python, Ruby, .NET, JS), or when you have a fleet of Selenium Grid nodes you cannot rip out. The community MCP servers from Angie Jones (mcp-selenium), naveenanimation20, and others wrap WebDriver into MCP-compatible tools. They work. They are not first-party. Most teams that show up asking 'Playwright vs Cypress vs Selenium' in 2026 are not coming from a Java enterprise stack with a Selenium Grid; they are coming from a Node app and a CI pipeline. For that team, Selenium's lack of a first-party MCP combined with the fact that none of its language ergonomics are required puts it third on the list.

On startup, Assrt calls require_.resolve('@playwright/mcp/package.json') from /Users/matthewdi/assrt-mcp/src/core/browser.ts line 284 and spawns it as a child process over stdio. If the package is not installed, the runtime errors out before the first scenario starts. There is no fallback path that targets a Cypress MCP or a Selenium WebDriver session. That is not a marketing position; it is a hard dependency declared in the package.json (@playwright/mcp ^0.0.70). Anyone proposing 'just port it to Cypress' has to either (a) ship the missing browser-driving Cypress MCP themselves, or (b) wire the agent to a community shim with no maintenance guarantee. Both are real engineering projects, not config swaps. That asymmetry is the framework choice in 2026.

Yes. If your team already owns thousands of cy.* tests and the maintenance cost of rewriting them outweighs the AI-agent ergonomics gain, do not migrate. If you live inside the Cypress Cloud product (Test Replay, Smart Orchestration, the new Cloud MCP for run analytics) and the value you get from those is high, the AI-driving gap is solvable later via a community MCP or a shipped @cypress/mcp when Issue #33412 closes. If your testing surface is mostly component testing rather than full-app E2E, Cypress component tests remain very good. The 2026 framework choice is a tradeoff, not a verdict.

Yes. Cross-browser reach beyond Playwright's matrix (Edge, Safari on iOS, native Android Chrome) often still routes through WebDriver. Cross-language teams (a Java backend QA org, a Python data-science team that writes its own UI tests) have ergonomics in Selenium that Playwright cannot match without language-specific bindings of varying quality. Existing Selenium Grid investments are real and not free to retire. For greenfield JavaScript or TypeScript work in 2026, the MCP gap is decisive against Selenium; for established polyglot or Grid-backed shops, the migration cost almost always exceeds the AI-agent gain.

Three checks, two minutes each. One: visit npmjs.com/package/@playwright/mcp and confirm the publisher is the @playwright npm scope, the repo is microsoft/playwright-mcp, and the most recent version is current (0.0.70 or newer in May 2026). Two: visit github.com/cypress-io/cypress/issues/33412 and read the proposal status. If it is still open, there is no first-party browser-driving Cypress MCP yet. If it has shipped, the framework comparison should be re-run. Three: search the official selenium.dev docs and github.com/SeleniumHQ for 'mcp'. If the result set is empty or only points at community forks, Selenium remains in the no-first-party-MCP column. That is the entire diligence loop for the new axis.