# Playwright MCP reads the accessibility tree, pins an alpha Playwright build, and its own README points coding agents elsewhere

> Playwright MCP is a Microsoft Model Context Protocol server that gives an LLM browser automation through Playwright, exposing pages as structured accessibility snapshots instead of screenshots so no vision model is needed. It is the right shape for long-running agent loops with persistent browser state, and the project itself argues that a coding agent doing bulk work should use the Playwright CLI with skills instead, because MCP tool schemas are expensive in context.

**microsoft/playwright-mcp** — Playwright MCP server

- Repository: https://github.com/microsoft/playwright-mcp
- Website: https://www.npmjs.com/package/@playwright/mcp
- Stars: 37,695 · Forks: 3,202
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-08-17 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-playwright-mcp

## The tool surface is the accessibility tree, not a picture

The design decision that defines this server is that it does not take screenshots. It gives the model structured accessibility snapshots produced by Playwright, so a page arrives as a tree of roles, names, and states that the model can reason about directly. The stated consequences are speed and size, since there is no image to send and no vision model to run, and determinism, because a named control is a target rather than a set of pixels to guess at. The three headline properties are framed that way: fast and lightweight because it uses the accessibility tree rather than pixel-based input, LLM-friendly because it operates purely on structured data, and deterministic in tool application, which is described as avoiding the ambiguity common with screenshot-based approaches. The trade is that anything not represented in the accessibility tree is not something the agent can see.

## The runtime dependency is an alpha build of Playwright 1.64

This is the detail to look at before you rely on it. The package declares only two runtime dependencies, and both are pinned to a pre-release build:

```json
  "dependencies": {
    "playwright": "1.64.0-alpha-1790635538000",
    "playwright-core": "1.64.0-alpha-1790635538000"
  },
```

The version string carries a build timestamp suffix rather than a clean release number, and the word alpha is part of the identifier, so this is not a stable Playwright release being pinned exactly. Everything else in the manifest is looser by comparison, with the MCP SDK and the Node type definitions on caret ranges and only the Playwright-related packages fixed. The practical consequence is that the browser layer under the server can change shape without a version bump in this repository, and a regression in Playwright upstream surfaces as a Playwright MCP bug. The dev dependencies repeat the same alpha pin for the test runner, so the test suite exercises the same build you ship.

## The version is still 0.0.83, and releases land every week or two

Read the version number and the release dates together. The package is published as @playwright/mcp at version 0.0.83, with recent tags v0.0.83, v0.0.82, and v0.0.81 landing on 28 September, 18 September, and 14 September 2026 respectively, and the last push to the main branch is dated 28 September 2026. So the code is moving constantly and the project is not standing still. The consequence is that a 0.0.x number carries no compatibility promise in the usual semantic versioning sense, since breaking changes are permitted at every increment, and the release tags themselves say nothing, carrying no changelog text beyond the version. Pinning an exact version is therefore the only way to keep a deployment reproducible, which is the opposite of the @latest convention the setup instructions use.

## The project's own guidance sends coding agents to a different tool

The most useful section in the documentation is the one arguing against this package for a particular audience. The comparison states plainly that this package provides the MCP interface into Playwright, and that if you are using a coding agent you might benefit from the Playwright CLI with skills instead. The reasoning is token cost. Coding agents increasingly favour CLI-based workflows exposed as skills, because CLI invocations avoid loading large tool schemas and verbose accessibility trees into the model context, letting the agent act through short, purpose-built commands. That makes the CLI route better suited to high-throughput coding agents that have to balance browser automation against large codebases, tests, and reasoning inside a limited context window. MCP is positioned as still relevant for specialised agentic loops that need persistent state, rich introspection, and iterative reasoning over page structure.

## Every client config is the same npx line under a different key

Installation is uniform enough that the differences are what matter. The standard block names a command of npx with a single argument, @playwright/mcp@latest, and that form is stated to work in most tools, including VS Code, Cursor, Windsurf, Claude Desktop, Goose, Grok, and Junie. Claude Code and Codex take a one-line CLI route instead, `claude mcp add playwright npx @playwright/mcp@latest` and `codex mcp add playwright npx "@playwright/mcp@latest"`, and Codex can also be configured by hand in `~/.codex/config.toml` under an mcp_servers.playwright table. Copilot has its own key, `~/.copilot/mcp-config.json`, and that one adds a `type` of local and a tools list of `*`. Cline's file is the most explicit, carrying a type of stdio, a timeout of 30, a `-y` flag on the npx invocation to skip the install prompt, and a disabled flag set to false.

## npm run lint regenerates the README instead of checking code

A few naming quirks in the repository are worth knowing if you contribute or read the CI. The lint script is `node update-readme.js`, so running lint rewrites documentation rather than analysing source, and the same file at the root is the generator behind the client install links in the README, which the file itself marks as generated by node utils/generate-links.js. The build script is `echo OK`, because the package ships plain JavaScript that is loaded rather than compiled, with a root index.js as the main export and a cli.js registered as the playwright-mcp binary. Testing is where the real coverage lives, with the default test script running playwright test and separate projects for chrome, firefox, and webkit, plus a docker project gated behind an MCP_IN_DOCKER environment variable. Publishing is gated on both the readme regeneration and the test run.

## The container exists mainly so browsers do not become zombies

The Dockerfile is a small, opinionated image built on node:lts-slim, and the comments explain what each step is defending against. The base stage is described as containing only the minimal runtime dependencies, so the install runs npm ci with dev dependencies omitted and then npx -y playwright-core install-deps chromium to pull the shared libraries the browser needs. The image installs tini explicitly, with a comment that gives the reason plainly: it reaps orphaned browser processes that would otherwise become zombies under node running as PID 1. A browser that spawns a renderer and is then killed leaves the child behind, and a container that accumulates them will eventually hit a process limit. The build also takes a Debian mirror host as a build argument and rewrites apt's sources only for the duration of the install, so the published image keeps the default archive host.

## Node 18 is the floor, and the whole server is one bin entry

The requirements are short and the surface is small. Node.js 18 or newer is the only stated runtime requirement, matching the engines field in the package manifest, and the client list is described as VS Code, Cursor, Windsurf, Claude Desktop, Goose, Grok, Junie, or any other MCP client. The package exposes exactly two things through its exports map, the package.json itself and the root entry, and the root entry carries a types file and a default JavaScript file, so there is nothing to configure in code if you only want to run it. The binary name is playwright-mcp, pointing at cli.js. The project also identifies itself to registries with an mcpName of io.github.microsoft/playwright-mcp, which is how a directory-style discovery mechanism would find it rather than requiring you to know the npm scope.

## Conclusion

Playwright MCP suits exploratory automation, self-healing tests, and long-running agent workflows where a continuous browser session is worth the context cost, and it installs into any MCP client with a single npx entry. It does not suit a high-throughput coding agent working across a large codebase, which is the case the project explicitly argues belongs to the Playwright CLI with skills, and it does not suit anyone who needs a stable dependency contract, since the package is at 0.0.83 and pins an alpha build of Playwright. Before adopting it, read the MCP versus CLI section in the project documentation and decide which side of that line your workload is on, then check whether you can accept an alpha Playwright underneath before you put this in front of a long-running agent.

## FAQ

### how to install playwright mcp

Add an mcpServers entry whose command is npx and whose only argument is @playwright/mcp@latest. That standard block is stated to work in most clients, and Node.js 18 or newer is required. Individual clients also offer a one-line CLI command for adding the same server.

### how to use playwright mcp with claude code

Run `claude mcp add playwright npx @playwright/mcp@latest` from the Claude Code CLI. Claude Desktop is configured differently, by following the Model Context Protocol install guide and using the standard mcpServers block.

### how to use playwright mcp in cursor

Cursor offers a one-click install button for the Playwright server. To add it by hand, go to Cursor Settings, then MCP, then Add new MCP Server, choose the command type, and use `npx @playwright/mcp@latest` as the command.

### What is MCP with Playwright?

It is a Model Context Protocol server that gives an LLM browser automation through Playwright. Pages are exposed as structured accessibility snapshots rather than screenshots, so the model can act on the page without a vision model or visually tuned input.

### Is the Playwright MCP free?

The package is published under the Apache-2.0 licence and authored by Microsoft Corporation, and it runs locally through npx against the open source Playwright package. There is no hosted service or paid tier involved in the configuration described in the documentation.

## Sources

- [Official documentation](https://www.npmjs.com/package/@playwright/mcp)
- [Official README](https://github.com/microsoft/playwright-mcp#readme)
- [Project repository](https://github.com/microsoft/playwright-mcp)
- [Release notes](https://github.com/microsoft/playwright-mcp/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-playwright-mcp