[TABLE_OF_CONTENTS]

It's Friday afternoon. You ask Claude Code to cover the checkout flow. Playwright MCP opens a browser, clicks through cart, shipping, and payment, and hands you a passing checkout.spec.ts. Four minutes, zero dollars. You commit it and go home.

Three weeks later, the test fails in CI. You're on vacation. Nobody else knows how the fixtures log in, so the red build gets retried twice and then ignored. On Tuesday, support hears from a customer that checkout is broken.

The test was fine. The problem was where it lived.

That's the gap this article is about. Playwright MCP is the best free way to let an AI agent drive a browser, and we'll say so in detail. But it isn't a regression system. So, do you still need a testing tool if AI writes the tests? It depends on who else needs to run them, read them, and fix them when they break.

Yes, AI Can Write Your Playwright Tests, and It Costs Nothing

Let's get the concessions out of the way, because they're real.

What Playwright MCP actually does

Playwright MCP is Microsoft's MCP server for browser automation. Instead of reading pixels, it works from the page's accessibility tree: each tool call returns a structured snapshot of elements, their roles, and their text, and the model acts on elements by reference.

A simplified snapshot looks like this:

- heading "Checkout" [level=1]
- textbox "Email" [ref=e4]
- textbox "Card number" [ref=e7]
- button "Pay now" [ref=e12]

The agent reads that, decides to type into e4, and calls the next tool. No vision model, no guessing coordinates.

Setup in Claude Code is one line:

claude mcp add playwright npx @playwright/mcp@latest

It's also genuinely cross-browser. The config lets you choose chromium, firefox, or webkit, and a recent release added mobile and device emulation flags. That's a real advantage, and we'll come back to it.

Playwright Test Agents: planner, generator, healer

MCP gives an agent a browser. Test Agents give it a testing workflow. The planner explores your app and writes a Markdown test plan, the generator turns that plan into Playwright Test files, and the healer runs the suite and repairs failing tests.

You scaffold them with npx playwright init-agents. The documented loop options are vscode, claude, codex, and opencode, and you need Playwright 1.56 or later.

The healer deserves credit for one design choice. When the feature itself looks broken rather than the test, it marks the test with test.fixme() instead of patching it until it passes. A healer that turns everything green is a bug-hiding machine. This one isn't.

The output is also normal code. Generated tests are standard Playwright specs that run in GitHub Actions, GitLab CI, Jenkins, or anything else.

The CLI that's quietly replacing MCP in Claude Code

One thing most Playwright MCP guides skip: Microsoft now points coding agents somewhere else. The Playwright README says coding agents increasingly prefer CLI plus Skills over MCP, because the CLI avoids loading big tool schemas and verbose accessibility trees into context.

Our verdict

If every person who touches your tests is a developer, this stack is hard to beat. It's free, it's open source, it's cross-browser, and the output is plain code you own.

Best for: developer-owned test suites, teams with CI maturity, anyone who needs Firefox or WebKit.

Avoid if: the people who know what to test aren't the people who read TypeScript.

That second line is where it gets interesting.

The Catch Isn't the Code. It's Where the Suite Lives.

AI made writing Playwright tests nearly free. It didn't change anything about what happens after the test exists.

Follow the workflow to the end:

• The suite lives in one repo, usually shaped by one developer's conventions.
• Only people with repo and CI access can run it. Your QA lead, your PM, and your support team can't.
• A failure arrives as a stack trace in a CI log. Nobody outside engineering reads it.
• The fixtures, auth state, and runner config live in one person's head. When that person is busy, on vacation, or gone, the suite quietly rots.

Here's the moment it shows up. A release is going out in an hour, and your PM asks: "Is checkout working on staging right now?" With a Playwright-only setup, the answer is "let me ask Marek." Marek is in a meeting.

Our CEO has a line about this: test automation without an owner is just expensive decoration. AI makes the decoration faster to build. It doesn't assign an owner.

To be fair: if your team is five developers who all write, run, and fix tests, none of this is your problem. Skip to the decision framework. But if regression knowledge lives with QA, support, or product, it's the whole problem.

From a customer: One long-time customer recently moved their suite to Playwright, and they were right to. When they started, they had a single QA engineer and no one with time to write test code, so BugBug fit. Years later, the team had grown into wanting Git-reviewed changes, API-driven test data, and full ownership of their tooling. The migration took about three months, and they had to build their own reporting and failure triage along the way.

That's the line: BugBug is the right fit while regression is owned by people who know what to test but shouldn't have to build and maintain the system around it. When your team is ready to own that whole layer, code is the better call.

Same Protocol, Two Very Different Things on the Other End

Both tools speak MCP. The difference is what the agent is connected to once the protocol handshake is done.

With Playwright MCP, the agent borrows a browser

The agent gets tools like browser_navigate, browser_click, and browser_snapshot. It can do anything a person can do in a browser tab. When the session ends, everything the agent learned ends with it, unless someone commits code.

MCP browser control is not rare anymore. Playwright ships it for free, and it does it well. So BugBug MCP doesn't compete on that. It isn't a better browser driver, and it doesn't try to be.

With the BugBug Plugin, the agent joins your regression suite

The BugBug Plugin has two parts. The MCP server gives your agent access to your real suite: tests, runs, failures, evidence. Skills teach it how to work with that suite the way a BugBug expert would. Tools without knowledge get misused, and knowledge without tools stays theory. You need both.

Skills are supported by the leading AI coding agents, so this isn't tied to one editor. Install the plugin and your agent stops starting from zero. It can see the tests your team already has, what ran last night, what failed, and why. That changes what you can ask it to do.

Plan coverage without duplicating what exists. Ask the agent to review the checkout tests and propose what's missing, without changing anything yet. The plan-tests skill uses BugBug MCP to read your existing suite first, so you get a gap analysis instead of a fourth copy of the login test.

Debug a failure from the real evidence. No more pasting error messages into chat. Through MCP, the agent pulls screenshots, console and network logs, DOM snapshots, JUnit reports, test definitions, and BugBug's error-code docs for the exact run that failed. Then it tells you whether it's an app bug or a broken test.

Fix selectors without weakening the test. UI changes break selectors all the time without breaking the flow. The heal-step-selector skill repairs the locator, and you can tell it outright: fix the selector, don't touch the assertions. You keep the test's intent and lose the busywork.

Triage visual changes before anyone approves them. The review-visual-regression skill explains what changed on screen and whether it matches the redesign you just shipped. You make the call with context.

Get a release-day health check in one prompt. report-project-status summarizes which tests are failing or unstable before you deploy. It works for a QA lead or PM, not just the developer in the IDE.

Clean up the suite when nothing is on fire. review-test flags redundant steps and flaky selectors. refactor-test applies only the changes you approve.

Connecting takes one command in Claude Code:

npx @bugbug-io/cli plugin --agent=claude

You authorize through OAuth, or use a project API token for CI and clients that can't do OAuth. It works with Claude Code, Cursor, VS Code, Codex, and GitHub Copilot.

The payoff isn't that the agent is smarter. It's that everything the agent does lands in the same place your team already looks.

BugBug MCP: One Test, Recorded by a PM, Fixed from Cursor

This is the workflow Playwright MCP can't replicate. The reason isn't the protocol. The reason is that Playwright has no surface for the person who knows the product but doesn't write code.

Here's how it plays out with BugBug:

Monday. Your PM records the checkout flow with the BugBug Chrome extension. She clicks through it the way a customer would and adds an assertion that the order confirmation appears. Time spent: about ten minutes. Code written: none.

Thursday. A deploy renames the "Pay now" button. The scheduled run fails. Your PM opens the run in BugBug and sees step 7 highlighted, with a screenshot of the new button. She knows exactly what broke and doesn't need to read a log.

Thursday, five minutes later. A developer, already in Cursor, types:

Debug the latest failed checkout run. If it's a selector issue, propose a fix. Don't change assertions.

The agent pulls the run evidence, confirms the button text changed, and proposes a new selector. The developer approves it and asks for a rerun. It passes.

Thursday, still. The PM sees green in the BugBug UI. No ticket, no handoff, no "can you check if this is fixed."

One test, two people, two interfaces. Nobody had to learn the other person's tools.

Compare that with Playwright. Codegen can record a flow, but its output is TypeScript, and a PM can't maintain TypeScript. A PM can write the Markdown brief the Playwright planner works from, and that gets you part of the way. But the finished test still lands in a repo only developers touch. The PM's knowledge goes in once and can't come back out.

Try it yourself: one command, one read-only check

You don't have to take the Thursday story on faith. Connecting your agent takes one command and a sign-in.

1. Install the BugBug Plugin for your client. For Claude Code:

   npx @bugbug-io/cli plugin --agent=claude
   

   Swap in cursor, vscode, codex, or copilot for other clients. You'll need Node.js 24 or newer. The plugin sets up BugBug MCP and BugBug Skills together, so your agent gets both the tools and the know-how to use them.

2. Restart your client and sign in. It walks you through OAuth with your BugBug account.

3. Prove the connection without touching anything. Start with a request that can't break anything:

   Read my available BugBug projects and list their names only.
   

If your projects come back, you're ready. Your first real prompt can be the Thursday one: debug the latest failed run, read-only, and propose the smallest fix.

What your agent can now do

The plugin gives your agent multiple MCP tools, ready-made workflow prompts, and BugBug Skills. In practice, that means your agent can:

• Find the right test instead of writing a duplicate. It lists and inspects existing tests, suites, and reusable components, and shows where each component is used before it proposes changes.
• Diagnose failures from real evidence. It pulls the failed step's details, screenshots, logs, and DOM snapshot. It can query that snapshot by CSS or XPath to check whether a selector ever matched.
• Fix exactly what you approve. It can patch a single step, move it, or update a selector, without rewriting the whole test.
• Run and watch. It starts a test or suite, streams progress until the run finishes, and stops a run that's gone wrong.
• Handle the awkward parts of real apps. It manages variables and run profiles per environment, and uploads files for upload steps.
• Keep humans in charge of visual changes. It reviews expected, observed, and diff screenshots, and accepts a new baseline only when you say so.
• Answer "how do I…?" from the docs. It can query BugBug's documentation and return source links, instead of guessing.

The Skills are the part most MCP servers don't have. They tell the agent when to inspect, when to change something, when to ask you, and when to stop. Refactoring, for example, starts read-only unless you explicitly allow changes. You get an agent that behaves like a careful colleague, not one that turns tests green at any cost.

One setting worth turning on: enable human confirmation in your AI client for any tool that creates, updates, deletes, imports, or runs BugBug assets. Keep the agent read-only while it plans, reviews, and debugs. Approve changes one at a time.

Plan note: BugBug MCP requires a Pro plan or higher. BugBug Skills work on every plan, including free.

"It's in Our Repo" Isn't the Same as "It's Portable"

The strongest objection to any testing platform is lock-in. "With Playwright, the tests are just files in our repo. We own them." That's true, and it's worth taking apart.

The .spec.ts files are portable. Everything that makes them run isn't:

• The CI workflow that installs browsers and shards the suite
• The fixtures that seed data and reset state
• The storageState setup that keeps tests logged in
• The runner infrastructure and its secrets
• The one person who understands how all of that fits together

That last one is the real lock-in. You're not locked into a vendor. You're locked into a person.

BugBug handles portability from the other direction. Every plan, including free, exports tests as human-readable YAML, with a JSON Schema your CI can validate and a side-by-side diff before an import overwrites anything. You can put tests in Git, review changes in pull requests, and keep an independent backup of your whole project.

Now the honest part, stated before someone says it for us: BugBug YAML isn't executable code. It doesn't run on its own; you import it back and run it locally, in the cloud, or from CI.

So here's the accurate claim. What's portable is your test intent: every step, selector, and assertion, readable by humans and diffable in Git. What isn't portable is an engine, because the engine is BugBug. If you leave, you take a precise, reviewable spec of your coverage, not a runnable suite. For most teams that's still worth more than a folder of tests nobody else knows how to run. Just know which one you're getting.

Playwright MCP vs BugBug MCP: When You Need Both

"Same protocol, different job" isn't only a comparison. It's also how teams actually use them together.

Use Playwright MCP (or the CLI) for work in the moment:

• Exploring a page you've never seen
• Reproducing a bug report while you're coding the fix
• A quick "does this still work?" check during development

Use BugBug MCP for work that has to last:

• The regression suite that runs before every release
• Scheduled checks on critical flows like signup, login, and checkout
• Failures that someone outside engineering needs to understand

Here's a combined flow that works well. A customer reports a broken coupon field. You ask your agent to reproduce it with Playwright MCP, and it confirms the bug in two minutes. You fix the code. Then you ask the agent, through BugBug MCP, to turn that reproduction into a regression test next to your existing checkout tests, reusing the login component you already have.

The bug gets fixed once, and it stays fixed, because now the whole team can see it.

Which One Should Your Team Actually Use?

Start with who owns quality on your team, not with the tools.

Choose Playwright MCP + Test Agents if:

• Developers write, run, and fix all your tests, and that's a deliberate choice
• You need Firefox, Safari/WebKit, or mobile emulation coverage
• Your CI is mature and someone owns it
• You want zero vendors and zero spend

Choose BugBug MCP if:

• Manual QA, support, or product owns regression, and developers are busy shipping
• You don't have, and don't plan to hire, a dedicated automation engineer
• Failures need to be readable by people who don't read stack traces
• You'd rather not build and babysit test infrastructure
• Chromium coverage is enough for your users

Where BugBug falls short:

• It's Chromium and Chrome only, with no Firefox or Safari.
• It has no native mobile or desktop app testing.
• MCP access requires a paid plan, while Playwright MCP is free.

If any of those is a hard requirement, Playwright is the better call.

If Playwright fits your team, start with the official Playwright MCP. Then try the CLI if you're working inside a coding agent.

If your regression lives with more people than your developers, record one critical flow, connect BugBug MCP to the agent you already use, and ask it to debug the first failure. No credit card, and your first test runs in under ten minutes. Ready to catch some bugs?

Happy (automated) testing!