Playwright MCP vs an AI Testing Agent: What Is the Difference?

Playwright MCP and hosted testing agents both put a language model in front of a browser, so they get compared as if they competed for the same job. They are different layers. One is a capability you add to the coding agent already running in your editor; the other is a system that holds test definitions, runs them on triggers, and returns a verdict with evidence. We build the second kind at TesterArmy (YC 26) and also ship an MCP server, so this post has an interest to declare and a reason to be precise. Everything said here about Playwright MCP comes from its README as of September 2026.

What Playwright MCP is

Playwright MCP is a Model Context Protocol server, published by the Playwright team, that gives an LLM a set of browser automation tools. Its distinctive design choice is how the model sees the page: through structured accessibility snapshots rather than screenshots. The README describes this as fast and lightweight, operating purely on structured data with no vision model needed, and as deterministic tool application that avoids the ambiguity of screenshot-based approaches. browser_snapshot captures the accessibility tree, browser_click and browser_type take an element reference from it, and browser_take_screenshot exists for the human, since the README says you cannot act on a screenshot. A coordinate-based vision capability is opt-in through --caps vision.

It runs where your agent runs: npx @playwright/mcp@latest wired into VS Code, Cursor, Claude Desktop or any other MCP client, with a persistent profile by default, an --isolated mode, a --storage-state file for cookies, and a Chrome extension that attaches to tabs you are already logged into.

The README is candid about its own positioning. It says coding agents increasingly favor the Playwright CLI exposed as skills because CLI invocations are more token-efficient, and it keeps MCP for specialized agentic loops that benefit from persistent state and iterative reasoning over page structure, naming exploratory automation, self-healing tests and long-running autonomous workflows. Nothing below is a complaint about it; the Playwright MCP README is the source for every claim in this section.

What a testing agent is

A testing agent is a hosted system, and the browser is the smallest part of it. With TesterArmy the unit of work is a saved test: an ordered list of plain-English steps with a type each (act, assert, login, files, screenshot), stored in a project alongside encrypted credentials, saved environments and project memory. It executes in a cloud browser or a mobile simulator without a person present: on every pull request through the GitHub App, on an hourly, daily, weekly or cron schedule for production monitoring, from a webhook in any CI, or on demand from the CLI or MCP.

Authentication happens inside the run. Credentials are stored per project with a label and a "when to use" description the agent reads when choosing an account, an authenticator secret on the credential produces a fresh 6-digit TOTP code at the moment the MFA prompt is filled, with neither secret nor code exposed to the model or the transcript, and email and SMS one-time codes arrive through agent mail inboxes and real phone numbers, covered in how to test OTP and 2FA flows automatically.

Every run ends in one of three outcomes. PASSED and FAILED mean what you expect. BLOCKED means the agent could not reach a product verdict because of the environment, missing or rejected credentials, missing seed data, or its own automation limit on a step; the run carries an output.blockedReason with a category and a plain-language summary, is excluded from failure counts and pass rates, and concludes the GitHub check as neutral rather than red. The results model also attaches a video, per-step screenshots, the agent transcript and, for web runs, console and network logs, and the outcome lands on the pull request as a check and a comment.

Where the state lives

The cleanest separation comes from asking where the test exists after the session ends.

With Playwright MCP, the test is the conversation. When the chat ends, what persists is whatever the agent wrote down: a note, or code generated through the --codegen option, which defaults to TypeScript. Re-running the check tomorrow means prompting the agent again, with no guarantee it takes the same path, or maintaining the code it produced, which puts you back in the suite model that the Playwright alternatives guide sorts through.

With a testing agent, the test is a record. Take the flow from our own homepage demo, saved as five typed steps:

Log in as User 1.
Navigate to the API Keys settings page.
Create a new API key.
Verify the new API key is displayed and visible.
Screenshot the newly created API key.

That record runs the same way from every trigger, keeps its history, and produces evidence a reviewer who was never in the chat can open. Nothing in it references a selector or an accessibility node, so a redesign of the settings page changes what the agent sees while the steps stay as written. What that trades away is the subject of self-healing tests: what is real and what is marketing.

Use Playwright MCP when

Start with the cases the README names. You are debugging a page from your editor and want the agent to read the live DOM, console errors and network requests, and propose a fix in the same breath. You need a one-off pull of data from a site with no API. You want to reproduce a bug interactively in a browser that already holds your logged-in session, which the extension mode is built for. In all of these the human is present, the loop is short, and nothing needs to survive the session.

Use a testing agent when

The flow has to run when nobody is watching: on every pull request, nightly against production, or at 2am when a deploy goes out. The login involves a one-time code, an authenticator app or an OAuth provider, and you do not want a person in the loop to type it. The product is a mobile app and the test needs a simulator build rather than a browser. Someone other than the author needs to trust the result, which is what a video and a step trace on the PR are for. And you need the verdict to distinguish a product failure from a broken staging environment, because a red check that means "the database was down" teaches reviewers to ignore red checks. The same shape works for products whose own output is non-deterministic, covered in how to test AI apps beyond evals.

MCP is the transport; what sits behind it is the product

TesterArmy exposes the same testing system over MCP at https://tester.army/mcp, using OAuth 2.1 with dynamic client registration, so there is no API key to paste. Adding it to Claude Code is one line:

claude mcp add --transport http testerarmy https://tester.army/mcp

Once connected, your coding agent can create and update tests, queue a run for a test or a group against a saved environment, read the transcript and browser telemetry of a failure, and fetch a signed link to the run video that expires in 15 minutes. The MCP server docs list the tools and the built-in get_guide resource that teaches the agent how to write steps that finish with a verdict.

The two MCP servers share a protocol and differ in what stands behind it. Playwright MCP hands your agent a browser. The TesterArmy server hands it a testing platform that holds the state, runs the work in the cloud, and reports back. Many teams use both, exploring with the first and asking the second to keep the flow that turned out to matter. The walkthrough of that loop, with CLI commands, is in using Claude Code and Codex to create and run e2e tests.

FAQ

Is Playwright MCP a testing tool? It is a browser automation server for LLM clients. As of September 2026 its README positions it for exploratory automation, self-healing tests and long-running agent loops, and steers coding agents toward the Playwright CLI for token efficiency. It can be part of a testing workflow, and it does not by itself store tests, schedule runs, or produce verdicts.

Can I use TesterArmy through MCP instead of the dashboard? Yes. The hosted server at https://tester.army/mcp works with Claude, Claude Code, Cursor, Codex, VS Code and any MCP client, authenticating through your TesterArmy account over OAuth. The dashboard, CLI, API and MCP server expose the same projects, tests and runs.

Does Playwright MCP use a vision model? It does not by default. It works from structured accessibility snapshots, and the README lists "no vision models needed" as a feature. A coordinate-based vision capability is available as an opt-in through --caps vision.