Playwright MCP in VS Code and Claude Code

Playwright MCP is a small server from Microsoft that lets an AI agent, such as GitHub Copilot in VS Code or Claude Code, open a real browser and click, type and read the page through its accessibility tree. Use it to explore an app and draft tests, then keep the result as an ordinary Playwright test file that runs in CI without the agent.

This is for testers and test leads who use Playwright and want to know what MCP adds in practice. I use Playwright, MCP and VS Code in my own work, and most of what follows is about where an agent's results need checking.

What is MCP, in one paragraph?

MCP, the Model Context Protocol, is an open standard for connecting AI applications to outside systems, and its own site compares it to a USB-C port for AI. The tool you type into, VS Code with Copilot or Claude Code, is the host. An MCP server is a small program that offers the host a set of named tools. The Playwright MCP server offers browser tools such as browser_navigate, browser_click, browser_type and browser_snapshot, and the agent decides which one to call next.

What does the Playwright MCP server do?

It starts a real browser and gives the agent a structured snapshot of the page instead of a picture. The snapshot comes from the accessibility tree, the same roles and names a screen reader uses, so the agent sees a button called "Sign in" and a textbox called "Email" rather than pixels. No vision model is needed.

That has two consequences for testers. Pages with proper labels and roles are easy for the agent, and pages full of unlabelled divs are hard, which tells you something about their accessibility too. And every step is a round trip between the model and the browser, so a session is far slower than a script doing the same clicks.

VS Code also has built-in browser tools, and its docs suggest those for everyday browsing. When you want Playwright's tools, name the server in your prompt.

How do I add Playwright MCP to VS Code?

You need Node.js 18 or newer, because the server is started with npx. Check with node --version and npx --version first.

In VS Code, open the Command Palette and run MCP: Add Server. Choose Command (stdio), enter the command below, give it the ID playwright, then pick Global and Copilot Global for a personal setup.

npx -y @playwright/mcp@latest

That stores the server in your Copilot user file at ~/.copilot/mcp-config.json, which looks like this:

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

The VS Code docs also give a one-line install for the terminal. It writes the older VS Code format, which still works.

code --add-mcp '{"name":"playwright","type":"stdio","command":"npx","args":["-y","@playwright/mcp@latest"]}'

Then select Agent from the agent picker in the chat input, and test the connection with a prompt that names the server and changes nothing:

Use the playwright MCP server to open https://playwright.dev and tell me the page title. Do not change any files.

Expand the tool call in the chat and check three things. A Playwright tool ran, it returned output without a connection error, and the answer matches that output.

And in Claude Code?

The Playwright MCP README gives one command:

claude mcp add playwright npx @playwright/mcp@latest

Run claude mcp list to confirm it, or /mcp inside a session. Put --scope project before the server name to store it in a .mcp.json file at the root of the repository, so the whole team gets the same setup. Claude Code asks for approval before it uses servers from that file.

What is a good first task for Playwright MCP?

Pick a flow you know well, on a test environment, with a throwaway test account. Login is ideal, because you already know every rule it should follow.

Ask the agent to explore and report before it writes any code.
Check its report against what you know the app should do. The agent describes what happened, and deciding whether that was right is still your job.
Ask for a test file with role-based locators and web-first assertions, which is what Playwright's own best-practice guide recommends.
Run the file yourself with npx playwright test, without the agent.
Break the test on purpose by changing the expected error text, and confirm it fails.

The first prompt can be this plain:

Use the playwright MCP server. Open https://test.example.com/login.
Sign in with the throwaway test account I give you, sign out, then try
a wrong password and an empty email. For each attempt, report what the
page showed, the exact error text and the URL you ended on.
Do not write any code yet.

Once you have checked its report, the second prompt asks for the file:

Now write tests/login.spec.ts for Playwright Test covering what you did.
Use getByRole and getByLabel locators and web-first assertions.
Read the email and password from environment variables.

A test worth keeping looks something like this, and it runs in CI like any other:

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

test('wrong password shows an error and stays on the login page', async ({ page }) => {
  await page.goto('/login');
  await page.getByLabel('Email').fill(process.env.TEST_USER_EMAIL ?? '');
  await page.getByLabel('Password').fill('wrong-password');
  await page.getByRole('button', { name: 'Sign in' }).click();
  await expect(page.getByRole('alert')).toContainText('Incorrect email or password');
  await expect(page).toHaveURL(/\/login/);
});

Playwright also ships three test agents, a planner, a generator and a healer, that run this loop for you. npx playwright init-agents --loop=vscode or --loop=claude sets them up. Read every change the healer makes, because a test edited until it passes can also hide a real bug.

Where is it good, and where does it go wrong?

Job	How well it works	What to watch
Exploring an unfamiliar flow	Good	It reports what happened, which is different from whether it was right
First drafts of tests	Good, with review	Locators can be whatever worked once, so ask for role-based ones
Reproducing a bug from a ticket	Good	Give it the exact steps and test data from the ticket
Running a regression suite	Poor	Slow and costly per step, so run the test files instead
Judging its own success	Poor	It can report a pass without checking the thing that matters
Anything with real accounts	Risky	It acts with whatever access you give it

Cost matters too, because every step sends a page snapshot to the model.

The weakness I watch most closely is a check that passes without checking anything. While building this website with AI assistants, a text sweep reported zero hits for an old slogan that was still on the page, baked into a PNG image. An overflow check measured an element width that could never fail. My fix was the break-check. Before I trust a new check, I break the thing it guards and confirm the check fails.

On an architect exam app I built, an AI drafting pass reported all 40 questions as compliant, and an independent rule-based count found 36 failures. Since then I never let a model self-report something I can count. The OIC Architects website has a 52-check pre-publish gate and Playwright visual regression at 4 viewports. It once checked 1,351 links and found 0 broken, while the deploy folder still held about 22 MB of staff photos that were about to go public. A green check only proves the question the check asked.

How do you keep it safe?

Never give it production credentials or a real customer account. Use a test environment and throwaway users.
Take the README at its word that Playwright MCP is not a security boundary. Its allowed-origins option does not make it one.
Add --isolated to the server's arguments so the browser profile stays in memory and nothing is saved to disk.
Leave tool approvals on, approve only actions you understand, and skip the allow-all modes.
Treat everything on the page as untrusted input, since Claude Code's docs warn that servers fetching outside content carry a prompt-injection risk.
Keep tokens and passwords out of mcp-config.json, .mcp.json and anything you commit.
Review every generated test like a colleague's pull request, and break-check it before you merge.
Run the tests in CI the normal way. The agent has no place in the pipeline.

Add the server, run the title check, then try the login exercise on a test environment and break the test it gives you before you keep it. My work page shows the testing I have done on real systems.

Questions people ask

What is the difference between Playwright MCP and Playwright CLI?

Both let an AI agent drive a browser with Playwright. Playwright MCP offers browser tools to the agent through MCP and keeps the browser open between steps. Playwright CLI, the @playwright/cli package, is a command-line tool the agent calls, packaged with skills. The Playwright team says the CLI uses fewer tokens for coding agents, because it avoids loading large tool schemas and verbose accessibility trees. MCP still suits exploratory work, self-healing tests and long sessions where keeping the browser state matters more than token cost.

Does Playwright MCP work with Claude Code?

Yes. Run claude mcp add playwright npx @playwright/mcp@latest in a terminal, then confirm it with claude mcp list, or with /mcp inside a session. Claude Code starts the server when it needs browser tools. Add --scope project to share the setup with your team through a .mcp.json file in the repository. The same server also works with GitHub Copilot in VS Code and with other MCP clients, because MCP is an open standard.

Do I need to know Playwright to use Playwright MCP?

You can drive a browser with plain-English prompts and never write Playwright code. To keep anything useful, though, you need enough Playwright to read the test the agent writes, judge its locators and assertions, and fix it when it fails in CI. The generated file is ordinary Playwright Test code. If you cannot tell whether it checks the right thing, you cannot trust it when it passes.

Can AI-driven test automation with Playwright replace my test suite?

No. Use the agent to explore, draft and reproduce, then keep what it produces as normal Playwright tests in your repository. Those tests run in CI without a model, cost no tokens per run and repeat the same steps every time. An agent clicking through your regression suite on every build would be slower and dearer, and someone would still need to check its verdicts.

Sources

Share on LinkedIn

Playwright MCP in VS Code lets an AI agent drive your browser tests