Best MCP Servers for Testing and QA (2026)

The best MCP server for testing is Playwright MCP for almost everyone: it's Microsoft's official server, drives a real browser through the accessibility tree instead of screenshots, and installs with one line. If you need cross-browser coverage down to Safari, add Selenium MCP. Everything else on this list is situational.

This is a focused shortlist for testing and QA work from an agent — writing checks, reproducing bugs, and evaluating a running app end-to-end. All six servers below run locally over stdio, which tracks the ecosystem at large: about 90% of MCP servers run locally over stdio, and browser drivers have to, because they're launching a browser on your machine.

The short answer: which to install

Install Playwright MCP first and stop there unless you hit a wall. It covers the 80% case — navigate, click, fill, assert, screenshot — without a vision model and without you hand-rolling a Selenium setup.

Here's the whole field at a glance. "Official" means the repo belongs to the vendor, not just that it wraps their tech.

Server	Best for	Official?	Auth	Install
Playwright MCP	Default browser testing	Yes (Microsoft)	None	npx -y @playwright/mcp@latest
Playwright MCP (ExecuteAutomation)	Playwright + API tests, codegen	Community	None	npx -y @executeautomation/playwright-mcp-server
Selenium MCP	Cross-browser incl. Safari	Community	None	npx -y @angiejones/mcp-selenium
Puppeteer MCP	Attaching to a running Chrome	Community	None	npx -y puppeteer-mcp-server
Browser MCP	Your real logged-in profile	Community	None	npx @browsermcp/mcp@latest
web-eval-agent	Autonomous end-to-end debugging	Community	API key	see below

Playwright MCP: the default, and it earns it

Playwright MCP is the one to reach for first. It's Microsoft's official server (@playwright/mcp, ~23.8k stars), and its design decision — driving the page via Playwright's accessibility tree rather than pixels — is the right one for agents.

Why that matters: an accessibility snapshot is structured text, so the model gets stable element references instead of guessing coordinates off a screenshot. No vision model, fewer tokens, far less flakiness. Config is trivial:

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

The trade-off is real: this server can drive a browser to any URL and submit forms with whatever session state the browser carries. Point it at trusted targets, and read our note on what MCP security actually means before you wire it into an agent with broad reach.

When to add Selenium or ExecuteAutomation

Add Selenium MCP only when you need browsers Playwright won't give you — specifically Safari, plus older Chrome/Firefox/Edge matrices. It's the @angiejones/mcp-selenium WebDriver server, and cross-browser coverage is its entire reason to exist. The cost is setup: you need a matching browser and WebDriver installed locally, so it's more moving parts than the Playwright one-liner.

Reach for ExecuteAutomation's Playwright MCP when your testing spills past the browser — it bundles API testing alongside browser automation, with codegen, screenshots, and device emulation. It's the popular community build (~4.5k stars). If you're only doing browser checks, the official server is leaner; if one agent needs to hit your REST endpoints and the UI, this consolidates that into one server.

One caveat on ExecuteAutomation: it can execute arbitrary JavaScript in pages and run generated test code, so treat target URLs and any generated scripts as untrusted.

The two I'd skip for most testing

Skip Browser MCP and Puppeteer MCP unless you have their specific reason.

Browser MCP drives your real browser using your existing profile and logged-in sessions. That's genuinely handy for automating authenticated flows you can't easily script — but it means any client connected to it can act as you in every app you're signed into. For repeatable QA you want a clean, disposable browser, not your daily driver. Note it's a community server and not vendor-verified.

Puppeteer MCP (community) can attach to an existing Chrome over the remote-debugging port (9222). Useful for a very specific case — inspecting a browser that's already in some hard-to-reproduce state — but attaching hands the agent your live cookies and sessions. Enable that mode deliberately or not at all. For green-field test writing, Playwright covers this ground with less foot-gun.

web-eval-agent: a different tool entirely

web-eval-agent isn't a browser driver you script against — it's an autonomous agent that evaluates and debugs your running web app end-to-end from your IDE. Give it a flow ("sign up, add to cart, check out") and it exercises the app and reports what broke, capturing console and network along the way.

It's the odd one out here: Python, needs a free OPERATIVE_API_KEY from operative.sh passed via the env block, and it's community-built (not verified). Config differs from the npx crowd:

{
  "command": "uvx",
  "args": ["--from", "git+https://github.com/Operative-Sh/web-eval-agent.git", "webEvalAgent"],
  "env": { "OPERATIVE_API_KEY": "<YOUR_KEY>" }
}

Use it for exploratory smoke-testing and bug repro, not for the deterministic assertions you'd write with Playwright. The two are complementary, not competitors.

Don't install all six: mind the tool budget

Here's the trap. Every server you add dumps its tools into your client's context, and clients like Cursor start selecting poorly past roughly a 40-tool budget — the math on that limit is unforgiving. Stack three browser servers and you've spent your whole budget on redundant navigate/click/screenshot tools.

Pick one browser driver, add a second only for a coverage gap you actually have, and keep the rest out. If you're already over budget, our config generator helps you trim to a working set. For the wider landscape beyond testing, see the best MCP servers roundup and the full capabilities breakdown.