Selenium MCP: Servers, Setup, and When to Use Playwright MCP Instead

The short answer, before anything else: existing Selenium Grid and test suites survive the agent era. A solid community Selenium MCP (angiejones/mcp-selenium) installs in one command and lets your agent drive the WebDriver stack you already trust. For anything new, Playwright MCP is the stronger default.

One category neither route covers: daily tasks behind logins on your own accounts. That job belongs to a session-sharing browser like ego (lite), which is free, inherits every login from your Chrome import, and lets any shell-capable agent drive it in its own Space, without touching your window.

Selenium teams asking about MCP are usually asking a sharper question underneath: do our fifteen years of Grid infrastructure and test suites survive the agent era, or is this the forced migration?

Here's the inventory, the setup, and the honest boundary line, written for the team that owns a real WebDriver estate rather than for the greenfield reader most MCP posts assume.

Which Selenium MCP servers actually exist?

Unlike Playwright MCP, there's no vendor-official Selenium MCP; the ecosystem is community-built. Three implementations come up, and they're not equal.

The rest of this guide uses mcp-selenium, and one framing note matters: community-maintained is not a slur (the repo has real upkeep: tests, CI, a Dockerfile, and an AGENTS.md for agent consumers), but it does mean no vendor SLA behind it. That fact returns in the migration section.

How do you set up Selenium MCP?

Claude Code, one line:

claude mcp add selenium -- npx -y @angiejones/mcp-selenium@latest

Cursor, Windsurf, and other JSON-config clients:

{
  "mcpServers": {
    "selenium": {
      "command": "npx",
      "args": ["-y", "@angiejones/mcp-selenium@latest"]
    }
  }
}

Verify with a real flow: ask the agent to start_browser with Chrome, navigate to your staging site, and read an element's text.

The toolset covers what a Selenium engineer expects: session management, an interact tool (click, double-click, right-click, hover), send_keys and press_key, upload_file, get_element_text and attributes, execute_script for raw JavaScript, window and frame and alert handling, cookie management, and a diagnostics tool that pulls console and network data over WebDriver BiDi. Locators accept id, css, xpath, name, tag, and class.

Browser coverage is Chrome, Firefox, Edge, and Safari, with Safari's usual ceremony: macOS only, a one-time sudo safaridriver --enable, Allow Remote Automation switched on, and no headless mode.

A first real session, as you'd phrase it to the agent, exercises the whole surface:

Start a Chrome browser session, go to staging.ourapp.com/login,
type the test credentials into the form, submit, wait for the
dashboard, and read me the text of the .account-status element.
Then take a screenshot and close the session.

That one prompt walks start_browser, navigate, send_keys, interact, get_element_text, take_screenshot, and close_session, which is most of what daily agent-driven testing uses. If it completes, your setup is done.

The payoff for existing shops: this drives real WebDriver, so it speaks to your Grid, your browser matrix, and the infrastructure you've already paid for. Your agent becomes another client of the stack you have, not a reason to rebuild it.

Should you keep Selenium or switch to Playwright MCP?

Split the question by what the work is, and it stops being controversial. First the two stacks side by side, on the dimensions that differ:

Existing assets: keep them on Selenium MCP. A working Grid, hundreds of stable WebDriver tests, engineers fluent in the stack: migrating that to chase a protocol trend is negative-value work. The MCP layer means agents can already generate, run, and triage against it. Rewrites earn their cost only when the old stack blocks something you need.

New agent automation: start on Playwright MCP. The maintenance asymmetry is the argument: Playwright MCP is vendor-official from Microsoft's Playwright team, with the accessibility-snapshot design agents work best with, one-line installs across every major client, and an ecosystem (docs, issues, third-party guides) a tier deeper than any community Selenium server can match. For greenfield work you'd be choosing the smaller ecosystem on purpose, and there's no prize for that.

If you do decide some suites should eventually move, migrate on evidence, not on era-anxiety. The practical trigger list: a suite whose maintenance cost is dominated by waits and flakiness Playwright's auto-waiting would remove, a browser matrix that's collapsed to Chromium anyway, or a team that's already writing new tests in Playwright and paying double context to keep both stacks in their heads.

Absent one of those, the estate stays put, and the MCP layer is exactly what lets it keep earning while agents arrive.

When should you use Playwright MCP instead?

Concretely, four signals that a task belongs on Playwright MCP rather than Selenium MCP, even in a Selenium shop:

You're starting a repo with no WebDriver history. The task leans on agent-native snapshot semantics (element refs the model can target deterministically). You want vendor-maintained parity with browser changes rather than tracking a community release cycle. Or you're standardizing MCP config across teams that also use Cursor and Codex, where Playwright MCP's official per-client instructions save real onboarding time.

Setup and the failure modes to expect are covered in our Playwright MCP setup guide, and its token economics (the one real tax of the snapshot design) in the token problem breakdown. If you're weighing all of this at once: Selenium MCP for the estate, Playwright MCP for the frontier, and for the logged-in daily work, ego (lite), which keeps their programmatic-control model and adds the sessions neither can carry.

Read the Playwright MCP setup guide, or download ego (lite) for Mac, free, for the third category.

FAQ

Is there an official Selenium MCP server?

No; the Selenium project hasn't shipped one. The de facto standard is the community mcp-selenium by Angie Jones (MIT, ~424 stars, actively maintained), which wraps real Selenium WebDriver.

What's the difference between Selenium MCP and Playwright MCP?

Same idea, different engines and different backing: Selenium MCP drives WebDriver (community-maintained, fits existing Selenium infrastructure), Playwright MCP drives Playwright (Microsoft-official, agent-native snapshot design, bigger ecosystem). Asset situation, not feature lists, should decide.

Can my agent run existing Selenium tests through MCP?

The MCP drives browsers live rather than executing your test suite files; your suite still runs through its normal runner. What agents do well through the MCP: reproduce a failing scenario step by step, extract locators from live pages, and draft new test code against your existing patterns.

Is Selenium MCP free?

Yes: mcp-selenium is MIT-licensed open source, installed via npm at no cost, and Selenium itself is Apache-2.0. As with every MCP in this category, the running cost is the model tokens your agent spends driving it, not the software.

Does Selenium MCP work with Selenium Grid and remote drivers?

The server drives WebDriver locally out of the box; because it's plain WebDriver underneath, teams point it at existing remote infrastructure the same way they would any WebDriver client, which is precisely why it's the asset-preserving choice. Check the repo's configuration options for your Grid topology before rollout.

Does Selenium MCP handle logged-in sites?

Only the way Selenium always has: script the login, manage the cookies, maintain it when 2FA changes. For your own accounts, inheriting a real browser's existing sessions (ego (lite)'s model) replaces that maintenance entirely; for test accounts in CI, scripted login remains correct.