If you’ve been keeping an eye on AI tooling, you’ve probably seen how Model Context Protocol (MCP) servers let LLMs talk to different APIs, query databases, and read files. Simply put, they do things that make them far more useful than a simple chatbot.
For the past couple of years, we've been using AI tools like Claude, GPT-4/5, and Copilot to generate code. However, the problem was that they couldn’t execute it. MCP has changed that by acting as a universal bridge, allowing AI models to connect directly to local servers and tools.
In the testing world, Playwright MCP is a great example of this shift. It allows AI models to connect with browsers directly and create tests for you using Playwright.
The short version
What it is: Playwright MCP is a Model Context Protocol server that lets a coding agent – Cursor, Claude Code, Copilot – drive a real browser: navigate, click, type, read the page, take snapshots. As an MCP server, it turns “write me a Playwright test” into “go try it and tell me what happened.”
What it’s good for: exploring an app while you build, generating a first draft of a test from a live page, debugging a broken selector without leaving your editor. It is genuinely useful and it is free.
What it isn’t: a test suite. It runs on a developer’s machine, in a developer’s session, at a developer’s request. There is no scheduling, no parallel execution, no verdict on a pull request, no history, no one to own it when the person who set it up moves teams. The tests it writes are still Playwright tests, so they still break when a selector changes.
Who should use which: if you have senior engineers who want browser control inside their coding agent, use Playwright MCP – today. If you need someone other than those engineers to get a reliable pass/fail on every pull request without maintaining the harness, that’s a platform question.
What Is the Playwright MCP Server?
The Playwright MCP server is a Model Context Protocol server that provides browser automation to any MCP-capable client. It’s a translator between your LLM and browser actions.
It provides two key modes:
- Snapshot mode (the default, driven by the accessibility tree)
- Vision mode (a fallback for when the accessibility tree isn’t enough)
In the past, if you wanted Claude Code to interact with a database, you had to write a custom script for every tool. MCP standardises that. You run a local server, it exposes a defined set of capabilities, and the AI client knows when to use them.
The architecture is simple:
AI model → MCP client → Playwright MCP server → Browser
Playwright MCP exposes actions like browser_navigate, browser_click, browser_snapshot, and more as MCP tools that AI models can call directly. As a result, LLMs can interact with web pages without needing a vision model for every step.
The real use cases are numerous: rapid prototyping of UI workflows, ad-hoc automation, test generation, automated form submissions, and much more.
The difference from regular Playwright is who holds the wheel. With standard Playwright you define every turn; with Playwright MCP the agent drives and you specify the destination.
But MCP doesn’t solve everything out of the box. Authentication complexity remains a problem – multi-factor auth, OAuth flows and session management are still not automatic. Flaky tests don’t disappear because AI is running things, and dynamic content such as shadow DOM, iframes and lazy-loaded elements is still difficult to handle.
Getting it running
Playwright MCP is maintained by the Playwright team and the setup is short: install the MCP server, point your coding agent’s config at it, restart the agent. The exact package name, flags and config path move between releases, so rather than print them here and quietly go out of date, use the official setup instructions in the Playwright MCP repository. Those are current by definition. Ours wouldn’t be.
That’s worth sitting with for a second, because it’s the same problem one layer up. This section would go stale for exactly the reason a scripted test goes stale: both are pinned to the specific shape of one version of something, and the something keeps moving. A flag gets renamed, a config path changes, a button gets a new wrapper. The artifact doesn’t know, so it just keeps asserting the old world until somebody notices.
The difference is what it costs. When a docs page goes stale a reader shrugs and finds the README. When a test suite goes stale you either spend the afternoon fixing selectors or you stop trusting the results, and most teams pick the second one without deciding to.
What’s worth knowing before you start, and what the README won’t tell you: it runs as a local process tied to your editor session, it needs a browser it can drive, and the config lives per-client, so getting it working in Cursor doesn’t get it working for a colleague on Copilot. That per-client setup is the first place teams lose an afternoon.
Why Does Playwright MCP Demand Senior-Level Skills?
Playwright MCP is far from bad, but it isn’t for everyone. Getting dependable output from it assumes you already know Playwright well.
The main challenges we see:
- Context management: the server is stateless, so every request starts fresh. There’s no built-in session memory, and keeping the agent oriented across a long flow is on you.
- Prompt engineering: you’re not just writing instructions, you’re constraining LLM behaviour so it doesn’t wander and burn tokens without producing a usable test.
- Zero CI/CD: it runs locally. To make it part of a GitHub Action you’d containerise the server, handle authentication, manage API tokens, and build somewhere for the output to land.
- Flakiness and hallucinations: an agent that has seen a component before may keep reaching for it after it’s gone, instead of re-reading the current state of your app.
The deeper problem isn’t difficulty, it’s distribution. The people who can do this well are usually the people you least want spending their week on it, and the people who most need the tests can’t do it at all. One QA lead described how thin that bench gets on a legacy framework:
“Where the Selenium I had, like one, or maybe actually it was more than I was, like three people who were really able to contribute to Selenium.” – a QA lead at a US enterprise software company
And the success criterion teams actually state when they go looking for something else is almost always about who can maintain it:
“We want to have someone, a non-specialist, that adds and updates the flow pretty fast… it’s not like he’s not technical, but he’s not a tester. He’s a front-end engineer.” – a POC sponsor at a scale-up
“We wanted to explore things that were probably a little bit smarter and that could also have people that aren’t engineers write tests. It could be somebody on our design team, or a product manager.” – an engineer at a large financial-data company
That’s the honest read on Playwright MCP: it moves browser control into the editor, which makes it considerably more powerful for the engineer, and no more accessible to anyone else.
What Playwright MCP is actually good at
It would be easy to write this article as “Playwright MCP is hard, buy a platform.” That isn’t what we hear on calls. Teams are genuinely succeeding with Playwright plus a coding agent, and they’re not wrong to.
A QA lead who moved a full Selenium suite to Playwright and TypeScript put it plainly:
“We’ve been using AI a lot… We have different tools available to us that make the creation and the maintenance of these tests more reasonable. It’s faster. It’s more accurate. Well, I won’t say more accurate. It does it faster.” – a QA lead at a US enterprise software company
And a team that priced us against exactly that setup chose the DIY route, with clear eyes:
“We’re running Playwright and prompting AI directly to create the test setup and the test flow. We have an hourly plan and token costs are included, so it doesn’t cost us much at all.” – an engineering lead at a Nordic recruitment-software company
So be specific about where it wins. Playwright MCP is very good at exploring an unfamiliar app while you build, drafting a first test from a live page instead of a guess, debugging a selector that broke without leaving your editor, and reproducing a bug report step by step. For a senior engineer inside their own project, it removes real friction, and it costs nothing but tokens.
Where it stops being enough
The line isn’t “it doesn’t work.” It’s that the bill arrives as engineering time you spent on your test infrastructure instead of your product. Four concrete limits:
- It’s session-bound. Nothing runs when nobody’s at the keyboard – no schedule, no nightly, no parallel run across environments.
- There’s no verdict surface. Results live in a chat log, not where the merge decision gets made, which is what dynamic testing on every pull request is for.
- The output is still selector-bound Playwright code, with all the test maintenance that implies. Faster generation doesn’t change which of your reds are real, which is the distinction behind flaky tests. Generating a test faster doesn’t make it less fragile.
- There’s no owner. A promising internal setup usually doesn’t fail loudly; it just quietly stops being maintained when the person who built it changes teams.
Fredrik Mellander, who runs these conversations at QA.tech, draws the line the same way every time:
“Playwright is very good when it works, but if updates are made, or you need to do a lot of things that are over-complex, then both the manual time and the cost become quite questionable.” – Fredrik Mellander, QA.tech
“What we hear from other customers who have tried that route is that time becomes the big thing. Even if the cost itself is lower, you have to put in quite a lot of time. That’s time and resources that could have gone to something else.” – Fredrik Mellander, QA.tech
A QA lead described the trade-off as a weekly choice rather than a strategy:
“It’s a matter of prioritisation, right? Because we can spend a week trying to learn this and maybe that’s the right thing to do. Or we could spend a week trying to maintain the test that we have and get to the next release.” – a QA lead at a US enterprise software company
A note on why this page doesn’t print the commands
Everything version-specific about Playwright MCP is in the repository, and we link there rather than copying it, because a copy is out of date the moment they ship. That is a small, honest version of the thing this whole page is about. Anything pinned to the current shape of a moving target needs a human to keep re-pinning it. Test scripts have that property. So do setup docs. So does every selector in your suite.
Agentic testing doesn’t remove that work, and anyone telling you it goes to zero is selling. What it does is move the pinning from the artifact to the goal: “a new user can sign up” survives a redesign, where page.click('[data-testid="signup-btn"]') does not. Our own founders put the honest number at around 90% of the routine verification, with the rest still needing a person.
Playwright MCP versus an agentic QA platform
At this point you have two paths: assemble your own setup around Playwright MCP, or use a platform that already runs one. Here’s what each involves.
Playwright MCP, self-assembled
You write the prompts for every scenario, add retry logic for when the agent fails, and watch token usage. To see results anywhere other than your editor you integrate CI, store history and build somewhere for failures to land. Expect a meaningful chunk of a senior engineer’s time up front and a few hours a week after that, with DevOps support for the CI side.
Managed agentic QA (QA.tech)
The agent already knows how to navigate web apps, so setup is account-level rather than infrastructure-level. Session handling, error handling, run history and CI integration come with it, and platform updates don’t break your tests. Initial setup is a couple of hours, and upkeep is closer to an hour a week – done by any developer who can describe a test in plain language.
In the table below, you’ll find a quick overview of how the two approaches compare:
| Playwright MCP server | Managed agentic QA | |
|---|---|---|
| Setup time | 2 weeks to months | 1–3 hours |
| Ongoing maintenance | 5–10 hours a week | ~1 hour a week |
| Skills required | Senior automation engineer | Mid-level developer |
| Runs unattended | No – session-bound | Yes – schedule and CI |
| Verdict on a pull request | You build it | Built in |
Where QA.tech fits
The difference is mechanism, not marketing. You describe a goal in plain language instead of writing steps in code. The agent decides how to reach that goal on every run, against the app as it is right now. The mechanism has a name – this is agentic testing – and it’s why a renamed button doesn’t take a test down with it. Runs happen in CI against a preview environment on every pull request, so a verdict is posted before merge rather than in a chat log afterwards, which is the whole point of PR testing. When something fails you get a video of what the agent saw, console logs, network requests, and an export to Linear or Jira.
The limits, in the same breath, because you’re here to compare rather than to be sold to: we run on Chromium, not the full browser matrix. There is no Playwright code export – test steps can be exported as plain-language user journeys, but we deliberately don’t generate Playwright code, because a suite you can export is a suite you go back to maintaining. And an agentic run isn’t byte-identical every time, which is the trade you make for not maintaining selectors. If deterministic, repeatable-to-the-pixel assertions are the requirement, keep those in scripts – plenty of teams run both.
If you’d rather see it than read about it, book a demo call and create your first test in a few minutes. Our roundup of the best agentic QA tools compares the managed options if you’re shortlisting.