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. For work on accounts you are already signed into, ego (lite) inherits every login from your Chrome import.
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.
| Implementation | Maintainer and status | Notes |
|---|---|---|
| angiejones/mcp-selenium | Angie Jones (Java Champion, developer-relations veteran); MIT, ~424 stars, tests + CI + Dockerfile in the repo | The default choice; Node-based, installs via npx, broadest client instructions |
| selenium-mcp-server (PyPI) | Community Python implementation, smaller footprint | Fits Python-first teams; check release recency before adopting |
| VS Code marketplace Selenium MCP | Individual publisher, editor-scoped | Convenience wrapper; the npx route above works in VS Code too and stays closer to upstream |
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@latestCursor, 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:
| Dimension | Selenium MCP (mcp-selenium) | Playwright MCP |
|---|---|---|
| Backing | Community-maintained (well-kept, but no vendor SLA) | Microsoft's Playwright team, vendor-official |
| Engine | Selenium WebDriver; speaks to your existing Grid and matrix | Playwright; no bridge to WebDriver infrastructure |
| Agent ergonomics | Classic locators (css, xpath, id); accessibility snapshot exists as a resource but isn't the core loop | Snapshot-and-refs loop built for LLM targeting; the cost is snapshot token weight |
| Ecosystem depth | One main repo, ~424 stars, fewer third-party guides | Official docs, per-client install pages, large issue base |
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 ego (lite) for token-lean agent runs.citrolabs/ego-browser-benchmark-framework.
Read the Playwright MCP setup guide, or download ego (lite) for Mac, free, for the third category.
Should you fix or rewrite a legacy Selenium suite?
Keep the suite when its coverage, Grid capacity, and domain knowledge are valuable; rewrite only when you can name the maintenance cost a new stack will remove. Start with a failure inventory—timeouts, locator churn, environment drift, and duplicate fixtures—then modernize one high-value flow with explicit waits, stable test IDs or roles, isolated data, and artifacts. A wholesale rewrite usually creates two flaky suites before it creates one reliable one.
Use Selenium MCP as an assistant around the estate: reproduce a failing path, inspect a live element, or draft a refactor while the existing runner remains the release gate. Measure failure rate and repair time after each migration slice; keep the old test until the new one proves equivalent behavior in CI.
Can AI generate reliable Selenium tests and locators?
AI can turn written steps into a useful Selenium draft and suggest locators, but generated code is not production-ready by default. Give it the user risk, fixture setup, expected outcome, and locator policy; then review every wait, assertion, cleanup step, and secret-handling path. Prefer stable roles, labels, and dedicated test attributes over deep CSS or XPath generated from incidental DOM structure.
Run generated tests offline against a local fixture when possible, and require a human to approve network access, credentials, and destructive actions. Keep the prompt, generated diff, and test evidence together so a future maintainer can see why a locator was chosen instead of trusting an opaque ‘self-healing’ claim.
Why use Selenium instead of Playwright?
Selenium remains the rational choice when you need the W3C WebDriver standard, broad language bindings, Safari and legacy-browser coverage, or an existing Grid and vendor ecosystem. Playwright is often a better greenfield default for fast Chromium/Firefox/WebKit suites, auto-waiting, tracing, and a unified test runner. The right choice is the one that meets your browser matrix and team's operating cost, not a generic ‘modern’ label.
For agent-driven exploration, compare the MCP layer separately from the framework. Selenium MCP preserves WebDriver assets; Playwright MCP offers a vendor-maintained snapshot workflow. Neither is a substitute for deterministic assertions in your normal test runner.
How do you debug Selenium click and element failures?
When a click returns but the UI does not change, capture the URL, DOM state, console output, and screenshot before trying JavaScript. Check for an overlay, animation, stale element, wrong frame or window, disabled control, and a click target nested inside the visible container. Locate within the intended parent and wait for the post-click state, not an arbitrary sleep.
If a floating banner covers the element, handle the banner according to the test fixture or close it through a supported UI action; do not hide the failure with an unconditional coordinate click. For Alertify or other dialogs, assert the dialog's visible state and wait for it to disappear. A passing click assertion alone does not prove the business action happened.
How do you keep Selenium reliable in Docker and CI?
Pin compatible browser, driver, Selenium, and language versions, and fail fast when a session cannot be created. Give each worker an isolated profile and temporary directory, cap parallel sessions by measured memory, and collect screenshots, logs, and HTML on failure. Long-running Docker jobs should recycle unhealthy sessions instead of letting a leaked process accumulate until the host freezes.
Treat SessionNotCreatedException as a compatibility or capacity signal: check the browser/driver matrix, container permissions, and recent plugin changes before adding retries. One bounded retry can cover a transient startup race; repeated failures should stop the pipeline and preserve the environment details for diagnosis.
How should you learn Selenium automation?
Start with one language your team already supports, the official Selenium documentation, and a small local test that opens a page, finds a semantic element, performs one action, and asserts a user-visible result. Then learn waits, fixtures, page boundaries, browser capabilities, and CI artifacts in that order. Two weeks can build a useful prototype; reliable professional automation takes repeated practice with failures and test design.
Manual QA, support, and software-development backgrounds all transfer: domain knowledge and debugging discipline matter more than choosing Java over Python on day one. Build a portfolio around readable tests, stable fixtures, and failure reports, then add Selenium MCP or another agent tool as an accelerator—not as a replacement for understanding what each assertion proves.
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.
