What Is Playwright MCP? 7 Strengths and 3 Ways to Choose

If you have connected Playwright MCP to Claude Code or Cursor and said "go test this," the first run is impressive. A real browser opens, clicks through your app, and reports back in plain language. After a few days something else shows up: the scope of what gets checked shifts from run to run, and you have no way to tell whether what passed yesterday still passes today. This post covers what Playwright is and what it does well in 7 points, what Playwright MCP changes, and which of 3 situations you are actually in.

What is Playwright

Playwright is a browser automation tool Microsoft released on 31 January 2020. Anything a person does in a browser — open a page, click a button, type text, read what appeared — you write once as code and a machine performs it.

Selenium held this ground for years. Playwright redesigned several parts of it, and it is now the default pick for teams starting fresh.

The basics first:

Maintained by	Microsoft
Released	31 January 2020
License	Apache 2.0 — free, commercial use included
Languages	JavaScript·TypeScript (primary), Python, Java, .NET (C#)
Browsers	Chromium, Firefox, WebKit
Cost	The tool is free. You only pay for whatever runs it

Free, open source, and actively developed by Microsoft. Those three alone make it hard to argue against.

Playwright testing strengths — 7 things it does well

It is worth being specific about why this became the standard.

1. It waits on its own. The most common failure in browser automation is clicking something before the page is ready. Older tools made you hardcode "wait 3 seconds," which was too short some days and wasted time on others. Playwright waits until the element is genuinely actionable. That change alone removed a large share of flaky failures.

2. It drives 3 browsers. Chromium (Chrome and Edge), Firefox, and WebKit (Safari) run from the same code. "Works in Chrome, breaks in Safari" gets caught before a user finds it.

3. It keeps a record of failures. Trace viewer captures the whole run so you can rewind and see the exact step where things stopped. That is a different class of information from tools that only leave a log line.

4. It writes the code for you. Turn on codegen, click through the browser yourself, and your actions come back as code. It removes most of the barrier to the first test.

5. It fits into how you already ship. Wire it to GitHub Actions or similar and it runs on every push, without anyone remembering to trigger it.

6. It runs many at once. As your checks grow into the dozens, parallel execution keeps total runtime down. The gap widens the more you have.

7. It sees past the screen. Beyond clicking, it can inspect the requests your app makes to the server, or fake a specific response to reproduce an error state on purpose.

Put together: if you can read and write code, there is not much reason to look elsewhere. If that describes you, take the rest of this post as context and go use Playwright.

If you can write code, there is not much reason to look elsewhere

What Playwright MCP changes

This is the part that shifted recently.

MCP is a way to hand an external program to an AI tool as something it can operate. Connect something over MCP to Claude Code or Cursor, and the AI picks it up and uses it.

Playwright MCP is Microsoft's official connector — a Playwright MCP server your AI tool talks to. With it in place, the AI drives a real browser. You say:

"Check that signup still works."

The AI opens a browser, walks to the signup screen, fills the fields, reads the outcome, and explains it back. Not one line of code, and a real browser moved.

That is not a small shift. Using Playwright used to require writing code, and that requirement appears to be gone.

The question that shows up after a few days

Which leads to the obvious next question: is this all I need now?

More precisely: some of it is handled, and some still needs you. The boundary is not a gap in the tooling. It follows from what MCP was built to be.

MCP hands a tool to an AI. A person asks, the AI picks the tool up and uses it. That is a good design and it suits conversation. It also carries consequences.

First, you have to ask every time. You said "check signup" today; after tomorrow's deploy you have to say it again. If you don't say it, nothing gets checked. The more often you ship, the more this leans on your memory.

Second, the scope moves. The same sentence can produce slightly different steps on different days. Today it also checks the invalid-email case; tomorrow it stops at "signup succeeded." That is natural for a conversational tool, but it makes "was this held to the same bar as last time" hard to answer.

Third, the AI ends up deciding what passing means. Unless you fix that beforehand, the verdict is the AI's to make. What happens when the side that built something also judges it is covered with research in the previous post.

Fourth, results don't accumulate. Conversations move on. To later say "fine through run 3, failing from run 4," that history has to live somewhere, and ad-hoc requests don't leave it behind.

Neither is better — they were built for different problems

None of this is a flaw in Playwright

Worth stating plainly: none of the above exists because Playwright fell short.

Playwright was built as an automation tool a developer controls through code. What to check lives in the code; when to run lives in your pipeline. Used that way, all 4 points above disappear — scope is fixed because it is written down, it runs on every deploy because CI triggers it, the pass criteria are in the code, and results accumulate as run history.

In other words, the way to get the most out of Playwright has always been to write code. MCP is a convenient doorway that lowers the entry barrier, not a replacement for everything code was doing.

Which of these 3 situations you are in

Putting it together, it splits like this:

• You can read and write code → Use Playwright through code. That is what this post recommends.
• You can't read code but only need occasional checks → Playwright MCP is enough. Just ask.
• You can't read code and need the same bar checked on every deploy → This is the gap.

What the gap actually needs

For the third case, the answer is not smarter browser control. Driving a browser is a solved problem. What is missing sits on top of it, and there are 2 pieces.

1. A human approves the pass criteria. Decide up front what counts as passing and the verdict never migrates to the AI. Fixed criteria are what make "the same bar as last time" mean anything.

2. It repeats on every deploy by itself. It runs without anyone asking, and each run leaves a pass or fail so you can later trace when a problem started.

Specnote handles those 2. The browser-driving part uses the same family of technology, so there is nothing special there. What differs is who owns the verdict and the repetition — the pass conditions are read and approved by someone who cannot read code, and execution repeats itself on every deploy.

Specnote also connects over MCP. You keep the AI tool you already use.

For the first 2, keep using Playwright

What this series will cover next

Playwright has a lot of surface area, and each piece deserves its own explanation. Coming up:

• Codegen — clicks turned into code, and how far you can trust the output
• Locators — how elements get found, and why small UI changes break things
• Trace viewer — what a failure leaves behind, and how to rewind it
• Fixtures — starting every run from the same state
• CI integration — running on every push automatically

Try it now