Playwright MCP Explained: Let AI Write Your Tests

Before Playwright MCP, AI-generated tests failed on locators because the AI imagined a DOM structure that didn't match the real application. With MCP, the AI opens your browser, inspects the actual accessibility tree, and generates getByRole and getByLabel locators from what it sees rather than what it assumes. This article explains how Playwright MCP works, how to configure it with Claude Desktop, what the AI can and can't access through the browser, and the workflow for generating, reviewing, and refining tests against a running application.

What MCP is and why it matters for testing

MCP (Model Context Protocol) is an open protocol that lets AI assistants connect to external tools and data sources. Anthropic released it in 2024, and the Playwright team added official MCP support in 2025.

What this means practically: when you use an MCP-connected AI assistant (like Claude in your IDE), it can open a browser, navigate to your application, inspect the DOM, and understand what elements exist, all before writing a single line of test code.

Before MCP, AI test generation worked like this:

1. You describe your application in text

2. AI generates code based on the description

3. You discover the locators are wrong because the AI imagined a structure that doesn't match reality

4. You fix the locators manually

With MCP, it works like this:

1. AI opens your application in a browser

2. AI inspects the actual DOM structure

3. AI generates code using real element roles, real labels, real data-testids

4. The locators work on the first run (usually)

The difference isn't just convenience. It's a qualitative change in output quality.

Setting up Playwright MCP

Prerequisites

• Node.js 18 or higher
• An MCP-compatible AI client (Claude Desktop, or an IDE with MCP support)

Installation

npm install -g @playwright/mcp

Or add it as a project dependency:

npm install --save-dev @playwright/mcp

Connecting to Claude Desktop

Add the MCP server to your Claude Desktop configuration. Open the config file:

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

Restart Claude Desktop. You should see a new Playwright tool available in the tools menu.

Connecting to VS Code

If you're using an MCP-compatible VS Code extension (like the Claude VS Code extension), the configuration is similar: add the server in the extension's MCP server settings.

What the AI sees through MCP

When the AI connects through Playwright MCP, it has access to:

Generating a test with MCP

Here's what a real MCP session looks like. You open your AI assistant, ask it to write a test, and it starts working:

The AI sees:

• A navigation bar with a "Login" button (role: button, name: "Login")
• A modal with two input fields (label: "Username", label: "Password")
• A submit button (role: button, name: "Submit")
• After login: a heading with text "My Travel Items"

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

test('user can log in with valid credentials', async ({ page }) => {
  await page.goto('https://lab.becomeqa.com');
  
  await page.getByRole('button', { name: 'Login' }).click();
  await page.getByLabel('Username').fill('admin@becomeqa.com');
  await page.getByLabel('Password').fill('testpass123');
  await page.getByRole('button', { name: 'Submit' }).click();
  
  await expect(page.getByRole('heading', { name: 'My Travel Items' })).toBeVisible();
});

The locators are correct because the AI looked at the actual application, not a description of it. getByRole('button', { name: 'Login' }) works because the AI verified that button exists with that exact accessible name.

Running MCP-generated tests with your existing setup

MCP generates standard Playwright tests. They integrate with your existing test suite without any changes:

# Runs just like any other test
npx playwright test tests/login.spec.ts

# Or run all tests
npx playwright test

The generated tests use the same playwright.config.ts, the same reporters, the same CI pipeline. MCP is a generation tool, not a separate test runner.

Practical workflow: AI-assisted test development

Here's a workflow that works well in practice:

Ask the AI to write a test for a specific scenario. Be specific about what you want to verify: not just "test the login" but "verify that logging in with valid credentials shows the dashboard with the user's name in the navigation."

Check:

• Are the locators using getByRole / getByLabel / getByTestId? (Good)
• Are there any getByXpath or locator('div.some-class') patterns? (Bad, these will break)
• Are there page.waitForTimeout(2000) calls? (Bad, use await expect(...) instead)
• Does the test have meaningful assertions, not just "page loaded"?

npx playwright test tests/login.spec.ts --headed

Watch it run. Does it match what you expected?

If something is wrong, tell the AI what happened. "The test fails at the modal step. It seems the modal takes a moment to appear. Can you add a proper wait?" The AI can navigate back to the application and inspect what's happening.

Once the happy path test works, ask for negative tests: "Now write a test for the case where the password is wrong." MCP lets the AI interact with the application to see what actually happens: what error message appears, where it appears, how it's phrased.

What MCP generates well vs. poorly

• Happy path flows with clear UI structure
• Form interactions (fill, select, click)
• Assertions on visible text and headings
• Modal and dialog interactions
• Tests for accessible applications with good semantic HTML

• Complex state-dependent scenarios ("user has exactly 3 items in a specific state")
• Tests that depend on backend data setup
• Visual layout tests (is this element positioned correctly?)
• Race conditions and timing-sensitive scenarios
• Tests that need database or API setup/teardown

For the second category, AI-generated code gives you a starting structure that needs manual refinement.

MCP vs. traditional AI code generation

| Aspect | MCP | Prompt-based generation |

|--------|-----|------------------------|

| Locator accuracy | High, from real DOM | Variable, from description |

| First-run success rate | Usually works | Often needs fixes |

| Requirement | Browser access to app | Just text description |

| Useful when | App is running locally | App not yet built |

Both approaches have a place. For testing a deployed application, MCP is dramatically better. For writing tests before the application exists (test-driven development), prompt-based generation from a specification is still useful.

Using MCP in CI

MCP is a development tool, not a CI tool. The workflow is:

1. Use MCP locally to generate and iterate on tests

2. Commit the generated tests to your repository

3. CI runs the tests in headless mode using standard Playwright

You don't run MCP in CI. You run the tests MCP helped you write.

FAQ

Any web application accessible via a browser. It doesn't matter if the frontend is React, Vue, Angular, or plain HTML. MCP works at the browser level, not the framework level.

Experimentally, yes. You can ask the AI to look at the current application and fix a test that's failing due to a UI change. In practice, this works well for locator updates but less well for structural changes to the test flow.

The @playwright/mcp package is open source and free. You need an MCP-compatible AI client. Claude Desktop (Anthropic) has free and paid tiers. Other compatible clients vary.

Both. Specify which you want: "Write this test in TypeScript with strict mode" or the AI will use whichever matches your existing project config.

With the right MCP configuration and AI client, yes. You can ask the AI to run a test, observe the failure, inspect the application in the failing state, and update the test. This is the agentic testing workflow that's emerging in 2026: the AI iterates on tests autonomously until they pass.