Playwright MCP Server Agent Testing: Browser Workflows That QA Can Trust

Playwright MCP server agent testing means using the Playwright Model Context Protocol server as a controlled browser interface for an AI coding agent, then turning the agent's observations into tests, fixtures, and reviewable evidence. The practical payoff is not that the agent "tests for you." The payoff is that the agent can inspect a real page through Playwright, reason over accessibility snapshots, perform realistic user actions, and hand QA engineers a traceable path from exploration to automated coverage.

For QA and test-automation engineers, the server is most useful when the work is deliberately bounded. Let the agent explore a user journey, capture what it observed, propose Playwright assertions, and expose missing accessibility names or unstable interaction points. Keep the final test code owned by your suite, reviewed like any other change, and executed by Playwright Test in CI. That split keeps agent speed without making a chat transcript your test framework.

The strongest workflow treats Playwright MCP as an agent-facing browser workbench. It is excellent for discovering how the page behaves right now, reproducing a bug in a live UI, finding the right role-based locators, and collecting page evidence. It is weaker as the final source of truth for pass or fail decisions. This article shows how to design that boundary, how to diagnose common failures, and how to build runnable workflows around the official Playwright MCP behavior documented at https://playwright.dev/docs/getting-started-mcp and https://playwright.dev/mcp/introduction.

Place Playwright MCP in the Testing Stack Before You Automate

Playwright MCP is a server that exposes browser automation capabilities to MCP clients. A coding agent connects to it, asks for page snapshots, clicks elements, types text, checks network and console information, and can use Playwright-powered browser state. The official documentation emphasizes a key design choice: the default interaction model works from the accessibility tree, not pixels. The agent receives structured information such as headings, textboxes, buttons, roles, names, and element references. It can then act on those references instead of guessing screen coordinates.

That distinction matters for QA. Pixel-based automation is tempting because it looks like a human view of the page, but it is easy for an agent to misread icons, click approximate coordinates, or miss invisible state. Accessibility snapshots force the conversation back to semantics. If the agent cannot find a "Submit expense" button in the snapshot, either the UI is not exposing the control well enough, the flow is not ready for automation, or the prompt is asking for the wrong thing.

Think of the stack as four layers:

Layer	Owner	What it produces	Main risk
Product UI	Application team	DOM, accessibility tree, network behavior	Missing labels, unstable async state
Playwright MCP server	Browser automation boundary	Agent-readable snapshots and browser actions	Tool misuse, persistent state surprises
AI coding agent	Exploration and draft generation	Reproduction notes, proposed tests, locator candidates	Overconfident assumptions
Playwright Test suite	QA-owned automation	Versioned tests, fixtures, reports, CI gates	Maintenance debt if drafts are accepted blindly

The MCP server should not replace Playwright Test. It should shorten the path to good Playwright Test code. Use the server while exploring, debugging, or authoring. Use the test runner to enforce repeatability.

This is also where Playwright MCP server agent testing differs from ordinary record-and-playback. A recorder captures what happened. An agent can inspect the current page, ask follow-up questions through tools, notice a disabled button, read an error region, and adjust. That flexibility is useful during discovery, but it must be constrained before it becomes a CI check.

Configure the Server as a Test Instrument, Not a Personal Browser

The basic MCP client configuration for Playwright uses npx with @playwright/mcp@latest. Many clients use an mcpServers JSON object with a server name, command, and arguments. The exact place to put that object depends on the client. The Playwright documentation lists client-specific examples for VS Code, Cursor, Claude Code, Claude Desktop, and other MCP clients.

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

That setup is enough for a human-supervised local workflow. For QA work, decide how much browser state the agent may retain. The official docs describe persistent profiles by default, isolated sessions with --isolated, loading storage state with --storage-state, choosing browser engines with --browser=firefox, and headless execution with --headless. Those are not cosmetic choices. They define whether the agent is seeing a clean user, an already authenticated user, a browser with prior cookies, or a browser matching the target engine.

Use persistent state when debugging a sticky product problem in a local development environment. Use isolated state when authoring test cases that should not depend on yesterday's login. Use a checked-in storage state file only when your team already treats that state as a fixture and understands how it is created.

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "@playwright/mcp@latest",
        "--isolated",
        "--browser=chrome"
      ]
    }
  }
}

For test-automation workstations, a useful convention is to keep two MCP entries: one exploratory profile and one isolated profile. The exploratory server can preserve login and speed up bug reproduction. The isolated server is used when asking the agent to generate test candidates. Keep their names explicit in the client config so prompts can reference the right one.

Configuration choice	Use it when	QA consequence
Default headed browser	You want to watch the agent work locally	Easier human supervision, less suited to remote workers without display support
--headless	The browser should run without a visible window	Useful in controlled environments, harder to visually supervise
--isolated	Each session should start clean	Better for repeatable test authoring and state-leak diagnosis
--storage-state	Authentication state is a deliberate fixture	Good for logged-in flows if fixture creation is reviewed
--browser=firefox or another documented browser value	You need engine-specific exploration	Helps find cross-browser differences before writing final projects
Standalone HTTP server with --port	The client needs to connect to a separately started server	Useful for worker processes or display constraints

What people get wrong: they connect the agent to their everyday browser state, ask it to author a test, and later wonder why CI cannot reproduce the path. The agent may have relied on a cookie, a localStorage entry, a dismissed modal, an A/B assignment, or a previously created record. Treat state as test data, not convenience.

Give the Agent a QA Charter Instead of a Vague Goal

An agent with browser access still needs a test charter. "Test checkout" is too vague. The agent may browse happy paths, skip error handling, or spend time on irrelevant page details. A useful charter names the user role, starting state, feature flag assumption, target journey, data constraints, expected evidence, and stopping point.

The best prompts are not long essays. They are operational briefs. They tell the agent what to inspect, what not to mutate, and how to report uncertainty. This is especially important when the page has destructive actions, payments, email notifications, or shared test data.

Role: QA automation engineer using Playwright MCP.

Target: Validate the self-serve trial signup journey on the local app.

Starting state:
- Use an isolated browser session.
- Start at http://localhost:3000/signup.
- Use a disposable email address from the test data file.

Scope:
- Complete the form until the confirmation screen.
- Do not submit payment details.
- Record every field label, required validation message, and final heading.

Output:
- A concise reproduction path.
- Candidate Playwright locators based on roles or labels.
- Assertions that belong in an automated test.
- Any accessibility names that are missing or ambiguous.

That prompt turns the agent into a bounded investigator. It also gives reviewers something concrete to compare against the generated test. If the final test asserts only a URL change and ignores validation messages, the gap is visible.

For longer suites, keep charters in version control as markdown files. They become reusable agent inputs and QA documentation. Ready-made QA skills can install from qaskills.sh with the qaskills CLI, but your team should still adapt each skill or charter to your product's data model, risk profile, and environment.

Charter field	Example	Why it matters
User role	Billing admin, anonymous visitor, read-only analyst	Prevents accidental privilege assumptions
Starting URL	Local signup page, staging order detail, seeded account dashboard	Removes exploratory wandering
Data rule	Use order ORD-10045, do not create real shipment	Controls side effects
Evidence required	Snapshot summary, console errors, final assertion candidates	Makes output reviewable
Stop condition	Stop before payment submission	Avoids irreversible actions
Uncertainty rule	Report if a control is not visible in the accessibility snapshot	Surfaces accessibility and locator risks

Use Playwright MCP for exploratory depth, then connect it to your broader agent test strategy. If you are designing the whole practice, pair this workflow with Agentic AI Testing Guide 2026, which covers agent roles, review gates, and governance beyond one browser server.

Convert MCP Observations Into Playwright Tests

An MCP session is not the artifact you want to run forever. The durable artifact is a Playwright test file with stable fixtures, explicit expectations, and evidence on failure. After the agent explores the page, ask it to produce a test draft that uses Playwright Test conventions already present in your repository. Then review the code as if a junior engineer wrote it quickly under supervision.

The conversion should preserve observed semantics. If the MCP snapshot showed a textbox named "Work email", the test should prefer getByLabel('Work email') or another user-facing locator over a brittle CSS class. If the agent clicked a button by a snapshot reference such as e12, do not copy that reference into the test. Snapshot refs are session artifacts. They are useful for tool calls, not long-lived selectors.

import { test, expect } from '@playwright/test';

test('trial signup shows confirmation after required profile fields', async ({ page }) => {
  await page.goto('/signup');

  await page.getByLabel('Work email').fill('trial-user@example.test');
  await page.getByLabel('Company name').fill('Northwind QA');
  await page.getByRole('button', { name: 'Create trial' }).click();

  await expect(page.getByRole('heading', { name: 'Check your email' })).toBeVisible();
  await expect(page.getByText('We sent a verification link')).toBeVisible();
});

Notice what the test does not include. It does not include the agent's reasoning. It does not include a giant page snapshot. It does not include a hidden DOM selector because the agent happened to see it. It expresses the user path in Playwright terms.

When the agent suggests a locator, ask for the reason. Good reasons sound like "the accessible name matches the visible label" or "the button role and name match the user action." Weak reasons sound like "this selector worked during exploration" or "the element had class btn-primary-1." Your review should reward locators that reflect product semantics.

For teams that already use custom fixtures, make the agent follow those fixtures rather than inventing a standalone file. A reliable prompt is: "Use the existing fixture style in tests/fixtures/auth.ts, but do not modify the fixture file." The agent can read patterns and produce a small test change without broad refactoring.

import { test, expect } from '../fixtures/test';

test('billing admin can open the invoice download menu', async ({ billingPage }) => {
  await billingPage.gotoInvoices();
  await billingPage.openInvoice('INV-2026-0142');

  await billingPage.page.getByRole('button', { name: 'Download' }).click();

  await expect(
    billingPage.page.getByRole('menuitem', { name: 'PDF invoice' })
  ).toBeVisible();
  await expect(
    billingPage.page.getByRole('menuitem', { name: 'CSV line items' })
  ).toBeVisible();
});

The page-object example is intentionally small. Let the agent use existing abstractions when they make tests clearer, but resist a large page-object generation burst from one exploratory session. If the UI is still changing, a generated abstraction can lock in the wrong model and create more maintenance than it saves.

Use Accessibility Snapshots as a Locator Quality Review

Because Playwright MCP works from accessibility snapshots by default, it gives QA teams a useful proxy for testability. If the agent cannot distinguish two "Edit" buttons, a screen reader user may face the same ambiguity. If the checkout icon is not exposed as a button with an accessible name, both the agent and assistive technology lose semantic context.

Build a locator review step into the workflow. After the agent explores a page, ask it to list controls that were ambiguous, unlabeled, duplicated, hidden from the snapshot, or only reachable by visual fallback. Then triage those as accessibility issues, testability issues, or acceptable product constraints.

Snapshot finding	Likely product issue	Automation response
Multiple buttons named Edit in one repeated list	Missing row-specific accessible names or context	Prefer scoped locators, file a UX accessibility improvement
Icon button absent from snapshot	Native role or accessible name missing	Fix markup before relying on coordinate clicks
Textbox appears with placeholder but no label	Labeling problem, placeholder-only design	Add label or accessible name, then test by label
Modal heading visible but focus remains behind page	Dialog focus management defect	Add accessibility test and user-flow assertion
Agent needs vision mode for ordinary form controls	Accessibility tree is incomplete	Treat as product bug, not agent limitation

This review produces actionable feedback even before a test exists. It also helps prevent a common failure mode: the team adds data-testid attributes everywhere because the agent struggled. Test IDs are fine for controls that have no stable user-facing name, but they should not be the default substitute for missing accessibility.

A disciplined locator hierarchy for agent-generated drafts looks like this:

1. Prefer role, label, placeholder, text, and alt text when those reflect the user experience.
2. Scope repeated controls to a row, region, dialog, or card with stable visible text.
3. Use test IDs for internal controls, repeated widgets, or cases where visible text is intentionally variable.
4. Avoid generated classes, React component internals, XPath copied from the browser, and MCP snapshot refs.

import { expect, Locator, Page } from '@playwright/test';

async function openLineItemMenu(page: Page, itemName: string): Promise<Locator> {
  const row = page.getByRole('row', { name: itemName });
  await row.getByRole('button', { name: 'Actions' }).click();
  const menu = page.getByRole('menu');
  await expect(menu).toBeVisible();
  return menu;
}

That helper keeps the semantics explicit. It scopes the action to a row and uses role names a user can understand. An agent can discover this pattern through MCP, but the final code should be written for maintainers.

Decide When Vision Mode Belongs in the Workflow

The official Playwright MCP documentation describes vision mode as an additional capability for coordinate-based tools that work with screenshots. It is useful for canvas apps, maps, image editors, charts, and custom widgets that are not exposed in the accessibility tree. It is not the first tool for normal web forms, menus, and buttons.

Enable vision mode only when the page interaction is genuinely visual. The documented configuration uses the vision capability. A client configuration can pass --caps=vision to the server.

{
  "mcpServers": {
    "playwright-vision": {
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--caps=vision"]
    }
  }
}

The QA risk with vision mode is false confidence. An agent may successfully click a coordinate on your laptop and fail on a different viewport, zoom level, locale, or theme. If the product is a canvas drawing tool, that risk is part of the domain. If the product is a settings page with ordinary controls, the coordinate click is evidence that the UI is not exposing a usable automation surface.

Use this decision matrix before letting a vision-based step into a test plan:

Scenario	Use default snapshots	Use vision mode	Final automated assertion
Login form	Yes	No	Role and label locators, error text
Data grid with row actions	Yes	Rarely	Scoped role locators or test IDs
Canvas diagram editor	Partially	Yes	Screenshot comparison, model state, or exported JSON
Map pan and zoom	Partially	Yes	URL state, map control state, or service request
Chart tooltip	Often for controls, sometimes for data point	Sometimes	Tooltip text plus data fixture
Icon without accessible name	No, because markup is deficient	Temporary diagnostic only	Fix accessible name, then use snapshot

When a vision step is unavoidable, keep viewport, device scale factor, seed data, and theme stable. Then assert something durable after the visual action. For a map, assert the selected region name or network request. For a diagram editor, assert exported JSON or object count. A coordinate click without a postcondition is not a test.

Add Network and Console Evidence Without Turning the Agent Loose

Playwright MCP can help an agent inspect console output and network activity, and the official docs describe network monitoring, mocking, console messages, screenshots, tracing, and related developer tools. Use those capabilities to explain failures, not to let the agent silently rewrite the environment.

A strong workflow asks the agent to report network and console evidence before proposing code changes. For example, if a page spinner never disappears, the agent should identify whether the API returned an error, a console exception occurred, or the locator waited for the wrong UI state. That evidence belongs in the bug report and often becomes a test fixture.

import { test, expect } from '@playwright/test';

test('profile page shows API validation errors inline', async ({ page }) => {
  await page.route('**/api/profile', async route => {
    await route.fulfill({
      status: 422,
      contentType: 'application/json',
      body: JSON.stringify({
        errors: {
          displayName: ['Display name is required']
        }
      })
    });
  });

  await page.goto('/profile');
  await page.getByRole('button', { name: 'Save changes' }).click();

  await expect(page.getByText('Display name is required')).toBeVisible();
});

The code above belongs in the Playwright suite, not inside an MCP transcript. The agent may discover the error payload shape by inspecting the app or reading tests, but the final test controls the route explicitly.

For console evidence, prefer targeted assertions around known failures rather than a global "no console messages ever" rule. Many applications log harmless development warnings locally. A strict global rule can create noisy tests that teams learn to ignore. Instead, capture errors around the user action being validated, or use project-level policy if your app already treats browser console errors as release blockers.

import { test, expect } from '@playwright/test';

test('checkout review does not throw a browser error', async ({ page }) => {
  const browserErrors: string[] = [];

  page.on('pageerror', error => {
    browserErrors.push(error.message);
  });

  await page.goto('/checkout/review');
  await page.getByRole('button', { name: 'Place order' }).click();

  await expect(page.getByRole('heading', { name: 'Order received' })).toBeVisible();
  expect(browserErrors).toEqual([]);
});

The agent can use MCP to reproduce the issue and identify the visible failure. Your suite should express the policy in ordinary Playwright code.

Diagnose the Failure Mode: Agent Passed Locally, CI Fails Later

The most common Playwright MCP server agent testing failure is a draft that passes during local exploration but fails as soon as it becomes a normal CI test. The root cause is usually hidden state, unstable data, insufficient waiting, missing accessibility semantics, or a mismatch between what the agent observed and what the runner controls.

Use this diagnostic path before rewriting the test:

Symptom	Likely cause	How to diagnose	Fix
Test passes after manual login but fails in CI	Persistent MCP profile leaked auth	Run with isolated context and a known storage-state fixture	Generate auth state in setup or test login through UI/API
Agent clicked button, test cannot find it	Snapshot ref was mistaken for locator stability	Compare final code locator to accessible role/name	Replace with role, label, or scoped test ID
Confirmation sometimes appears late	Async backend or frontend hydration race	Review trace and wait for user-visible postcondition	Assert final state, not arbitrary timeout
Test behaves differently by browser	Agent explored only one engine	Run Playwright project matrix	Add engine-specific bug or robust locator
UI changed after test generation	Agent captured stale copy	Review diff and product copy source	Update assertion to stable product contract
Local data disappears in CI	Agent used manually created record	Seed data in fixture or API setup	Own test data lifecycle

A useful reproduction command is the ordinary Playwright runner command your repository already uses. Do not create a separate agent-only way to execute tests. If your repo uses a package script, run that. If it uses direct Playwright invocation, run the project-specific command. The exact command depends on your package scripts, so keep it in your contributor docs.

npm test -- --project=chromium tests/signup.spec.ts
npx playwright test tests/signup.spec.ts --project=chromium --trace=on

Those commands are examples of common patterns, not a requirement to rename your scripts. The important part is that the failing draft must run outside the MCP session. Once it runs under the same runner, retries, trace collection, fixture setup, and reporter behavior as the rest of the suite, it can be debugged like a normal test.

One subtle mistake is letting the agent "fix" the failure by adding waits before every action. That often hides the true issue. If the page is waiting for a network response, wait for the user-visible state caused by that response. If the locator is ambiguous, fix the locator or UI. If the test data is missing, seed the data. Time is rarely the real contract.

Build an Agent-to-Test Review Gate

Playwright MCP accelerates drafting, which means teams need a review gate that is faster than a full manual rewrite but stricter than accepting generated code. The gate should be a checklist that reviewers can apply in minutes.

Review question	Pass signal	Reject signal
Does the test state a user-observable behavior?	Name and assertions describe a product outcome	Test only checks that a selector exists
Are locators user-centered?	Roles, labels, text, scoped test IDs	CSS chains, generated classes, snapshot refs
Is state explicit?	Fixture, setup call, or isolated flow creates data	Depends on prior MCP session or local account
Are waits meaningful?	Expects visible state, URL, response, or event	Uses arbitrary sleeps to mask races
Is failure evidence useful?	Trace, screenshot, or assertion points to problem	Failure says timeout on a vague locator
Is the blast radius controlled?	One scenario, few helpers, no broad refactor	Agent rewrites fixtures or page objects unnecessarily

Automate part of the gate with linting and convention tests. For example, you can block hard waits, discourage CSS locators except in approved helpers, and require test files to use project fixtures. Do not overfit the lint rules to one generated mistake. The point is to encode stable engineering preferences.

type GeneratedTestReview = {
  behaviorNamed: boolean;
  usesStableLocators: boolean;
  ownsTestData: boolean;
  avoidsArbitraryWaits: boolean;
  hasFailureEvidence: boolean;
};

function readyForHumanReview(review: GeneratedTestReview): boolean {
  return review.behaviorNamed
    && review.usesStableLocators
    && review.ownsTestData
    && review.avoidsArbitraryWaits
    && review.hasFailureEvidence;
}

The type above is not a production library. It is a compact way to show the policy you want reviewers and agents to internalize. Many teams get better results by pasting this checklist into the agent prompt and asking the agent to self-review before opening a patch. The self-review does not replace human review, but it reduces obvious cleanup.

For teams adopting MCP more broadly, this gate should align with your server testing practices. The companion article MCP Servers for Test Automation in 2026 explains where browser MCP servers fit alongside test-data, CI, reporting, and quality-intelligence servers.

Keep Security and Side Effects in the Test Plan

An MCP-connected browser can click real buttons. That is useful and risky. A QA workflow should define which environments the agent may access, what data it may create, and which actions require explicit human confirmation. Do not connect an agent to production admin pages and ask it to explore freely. Even read-only exploration can expose customer data in transcripts or logs.

Use a simple environment policy:

Environment	Agent access	Allowed actions	Required guardrail
Local development	Broad	Create, edit, delete seeded data	Disposable database or reset script
Ephemeral preview	Moderate	Validate changed flows	Test tenant and scoped credentials
Shared staging	Limited	Read and create clearly marked test records	Naming convention and cleanup
Production	Exceptional	Read-only diagnostics with approval	No secrets in prompt, no destructive actions

The official docs also call out that running arbitrary Playwright code through an MCP tool is equivalent to remote code execution and should be enabled only for trusted clients. That warning deserves operational weight. Browser automation is already powerful. Arbitrary code execution in the server process is a different risk category. If your client exposes such a capability, treat it as privileged, restrict who can use it, and avoid using it as a casual shortcut for test authoring.

Do not paste production secrets into prompts. Do not ask the agent to invent test credit cards unless your payment provider documents valid sandbox data. Do not let the agent create permanent accounts without a cleanup path. These are ordinary QA hygiene rules, but MCP makes violations easier because the agent can take action quickly.

Make the Workflow Repeatable in CI Without Running MCP in CI

Most teams do not need the MCP server in CI. CI should run the Playwright tests that came out of the workflow. The agent-facing browser server is for exploration, reproduction, and authoring. Keeping CI on the normal test runner has practical benefits: fewer moving parts, clearer reports, existing sharding, existing artifacts, and standard retry behavior.

A typical pipeline is:

1. QA engineer or developer asks the agent to explore a scoped flow through Playwright MCP.
2. Agent returns observations, candidate locators, and a test draft.
3. Human reviews and edits the Playwright test.
4. Local runner executes the test with trace on first failure or project policy.
5. CI runs the same test with the rest of the suite.

name: playwright

on:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test

That GitHub Actions example uses documented actions and a standard Playwright install command. Your organization may pin Node differently, cache dependencies, shard tests, or upload reports. The key principle is unchanged: MCP is an authoring interface, and Playwright Test is the enforcement interface.

If you do run an MCP server in a CI-like environment for an agentic coding workflow, isolate it from release gates. Give it a disposable workspace, scoped credentials, and a timeout. Persist only the artifacts you need for review, such as generated patches, screenshots, trace archives, or notes. Do not let an autonomous browser session share credentials with deployment jobs.

Measure Whether Agent Browser Testing Is Helping

The team should measure Playwright MCP server agent testing by its effect on automation throughput and defect discovery, not by the number of agent sessions. A browser agent that creates ten brittle tests per day is adding debt. A browser agent that helps one engineer reproduce a complex staging bug and land one robust regression test is useful.

Track a small set of metrics:

Metric	Good signal	Bad signal
Draft-to-merge ratio	More generated drafts survive review with modest edits	Many drafts are abandoned after failing locally
Locator revision count	Agent suggestions often align with final locators	Reviewers constantly replace brittle selectors
Time to reproduce UI bugs	Complex bugs get reproduced faster	Sessions wander without clear evidence
New flaky tests from agent drafts	Low or declining	Agent-authored tests dominate quarantine list
Accessibility issues discovered	Ambiguous controls become product fixes	Team works around missing names with coordinates
CI failure diagnosis speed	Traces and assertions point to clear causes	Failures require replaying agent transcripts

Use these numbers to tune prompts and gates. If locators are poor, add a locator hierarchy to the prompt. If data state causes failures, require the agent to identify setup assumptions. If accessibility findings are common, create a product ticket pattern. If drafts are too broad, reduce the charter size.

The hidden benefit is often not the first generated test. It is the discovery of why a page is difficult to automate: unlabeled controls, inconsistent copy, hidden state, slow hydration, environment drift, and unclear user outcomes. A good QA engineer uses the agent as a fast reader of the system, then applies judgment.

Frequently Asked Questions

Is Playwright MCP server agent testing a replacement for Playwright Test?

No. Playwright MCP is best treated as an agent-facing browser interface for exploration, bug reproduction, and test drafting. Playwright Test remains the repeatable runner for assertions, fixtures, reporting, retries, traces, and CI gates. The MCP session can reveal the path and suggest locators, but the final automated check should be committed as normal test code and reviewed with the same standards as any other Playwright test.

Should QA teams use snapshot mode or vision mode first?

Use the default accessibility snapshot workflow first for ordinary web applications. It gives the agent roles, names, text, and element references, which map closely to strong Playwright locators. Use vision mode when the target is genuinely visual, such as canvas, maps, image editors, or chart data points that are not exposed semantically. If a normal button requires vision mode, treat that as an accessibility and testability issue.

How do we stop agent-generated tests from becoming flaky?

Require explicit state, stable locators, meaningful waits, and ordinary Playwright execution outside the MCP session. Do not accept tests that rely on persistent local login, snapshot refs, arbitrary sleeps, or manually created records. Run the draft with the same project, fixtures, and reporter used by CI. When it fails, diagnose the contract: data, locator, async state, browser difference, or product behavior.

What should the agent report after exploring a browser flow?

Ask for a reproduction path, observed accessible names, candidate Playwright locators, user-visible assertions, network or console evidence for failures, and uncertainty notes. The uncertainty notes are important because they reveal missing labels, ambiguous buttons, state assumptions, and places where the agent relied on visual fallback. That report gives QA reviewers enough context to turn exploration into a maintainable regression test.