Getting started with Playwright MCP: let your AI assistant drive the browser

Ask an AI assistant to "write a Playwright test for my login page" and you'll get code that looks right — with locators the model invented, because it has never seen your login page. It's guessing from patterns. Playwright MCP fixes exactly this. It gives the assistant a real browser, so instead of hallucinating your app's structure, it opens the page, reads it, clicks through the flow and writes the test from what it actually observed.

What MCP actually is

The Model Context Protocol (MCP) is an open standard for connecting AI assistants to tools and data. An MCP server exposes capabilities — "navigate to a URL", "click this element", "read the page" — and any MCP-capable client (Claude, VS Code assistants, Cursor and others) can call them. The AI stops being a text generator and becomes an agent that acts.

Playwright MCP is Microsoft's MCP server for browser automation. The key design decision: it exposes pages primarily through the accessibility tree — the same structured view screen readers use — rather than screenshots. That matters for two reasons:

• It's fast and deterministic: the agent sees "button, name: Sign in" instead of interpreting pixels.
• It nudges generated tests toward getByRole-style locators — the resilient, user-facing locators you should be writing anyway.

Setup in two minutes

You need Node.js 18+. In most MCP clients, registering the server is one config entry:

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

In Claude Code it's a single command: claude mcp add playwright -- npx @playwright/mcp@latest. Restart the client and your assistant now has browser tools: navigate, click, type, take snapshots, read network activity.

Your first agent-driven test

Here's the workflow I teach in class, using any practice site you like:

1. Explore. Prompt: "Open the site, explore the login flow as a new user would, and list what you find — fields, validations, error states." Watch the agent navigate and report. This alone is a lesson in how it perceives the page.
2. Plan. "Based on what you saw, propose test cases for the login feature — happy path, wrong password, empty fields." You review the plan like a lead reviews a junior's — add the cases it missed (it usually misses locked accounts and password managers).
3. Generate. "Write Playwright TypeScript specs for the approved cases, using role-based locators, in our page object structure." Because the agent saw the real DOM, the locators refer to elements that exist.
4. Run and iterate. Run the specs. If one fails, paste the error back — or let the agent run and fix them itself.

What it's genuinely good at (and not)

Good at: exploring unfamiliar apps quickly, drafting coverage for standard flows, converting a user story into runnable specs, and repairing tests after UI changes — it re-reads the page and updates locators in seconds.

Not good at: knowing your business rules. It cannot know that a discount shouldn't apply twice, that a specific GST calculation matters, or which of your 40 flows carry revenue. It also happily writes assertions that pass but check the wrong thing — an assertion that the page "looks fine" is not a test.

Treat the agent as a fast junior engineer with no product context. It does the typing; you own the test strategy, the review and the merge.

Two cautions before you point it at real systems

• Only automate apps you're authorised to test. An agent clicking through a production system can create orders, send emails and delete data with the same enthusiasm it explores a demo site. Use test environments.
• Review generated code before committing. Agents occasionally hard-code credentials they were given or leave debugging steps in specs. The pull-request review discipline applies to AI authors too.

Why this skill is worth your time

Teams are quietly splitting into engineers who direct agents and engineers who compete with them. The first group writes the test strategy and reviews ten agent-drafted specs before lunch. Learning MCP-based workflows now — while most QA teams haven't — is one of the few genuine early-mover advantages left in this field.