Playwright MCP

Playwright MCP is a Model Context Protocol server that exposes a real browser to an LLM. Its distinguishing design choice is that it drives pages through Playwright's accessibility tree rather than screenshots, so the model works on structured text and no vision model is required. That makes element targeting deterministic in a way pixel-based approaches are not, and it is the reason the project became the default browser tool for most agent stacks.

The continuity signals are unusually good. The repo was created on 21 March 2025 and carries 36,131 stars and 3,025 forks as of 15 August 2026, with releases roughly monthly (v0.0.79 on 6 August 2026, v0.0.78 on 9 July, v0.0.77 on 29 June). Commit history is dominated by Pavel Feldman (242 commits) and Yury Semikhatsky (158) — Playwright's own leads, not volunteers adjacent to the project.

One structural point that makes the repo's metrics misleading: the implementation no longer lives there. src/ now contains only a pointer file explaining that the source moved into the Playwright monorepo at packages/playwright-core/src/tools/mcp. That is why the repo shows just three open issues — it is now a distribution, docs and issue-tracking front end. Read the low issue count as a relocation artefact rather than as evidence of either neglect or exceptional triage. The practical upshot is positive: the MCP server ships as part of playwright-core and is versioned with Playwright itself.

This is the thing a buyer is most likely to miss, and it comes from the vendor's own README rather than from any critic. Near the top of the page, before the feature list, Microsoft writes: "If you are using a coding agent, you might benefit from using the CLI+SKILLS instead." It argues that CLI invocations avoid loading large tool schemas and verbose accessibility trees into the model's context.

This is a redirection, not a deprecation, and the README is specific about where MCP still wins: "specialized agentic loops that benefit from persistent state, rich introspection, and iterative reasoning over page structure, such as exploratory automation, self-healing tests, or long-running autonomous workflows where maintaining continuous browser context outweighs token cost concerns."

The alternative is real and actively built. microsoft/playwright-cli is at v0.1.18 with commits through 13 August 2026 explicitly about skills management. Be aware the repo is a revived 2020-era project whose GitHub description still reads "Record and generate Playwright code, inspect selectors and take screenshots" — that blurb describes the old tool, not the current skills-based product, and will mislead anyone judging it from the repo card.

Adoption still favours MCP heavily: @playwright/mcp drew 6,659,312 npm downloads in the week to 9 August 2026 against 808,099 for @playwright/cli in the same window. So the CLI is meaningful but not yet dominant. The honest read: if your agent is a coding agent working across a large codebase, evaluate both. If you are building a persistent browsing loop, MCP remains the vendor's own recommendation.

A specific pair of numbers — 114,000 tokens for MCP versus 27,000 for the CLI — circulates widely and is frequently attributed to Playwright team benchmarks. That attribution does not hold up. The figure traces to a blog post by Provar, which measured it itself and which sells a competing product, "Provar MCP"; the post's own benchmark note credits a script in Provar's repository. It is a competitor's measurement of a competitor's product, and should not be repeated as Microsoft's.

We could not find any published benchmark number from Microsoft or on playwright.dev. The vendor's claims about token efficiency are qualitative only.

The one independent measurement we found points the other way. Stefan Judis of Checkly ran the same shopping-cart task three times against both setups in Claude Code on 30 July 2026 and recorded 48k–50k context tokens for MCP against 45k–48k for the CLI, concluding there is "no big difference in using CLIs or MCPs these days." He is candid that the test was not exhaustive.

The reasonable conclusion is that the direction of the effect is real — the vendor says so, and streaming accessibility trees into context plainly costs more than writing them to disk — but the magnitude is not established and appears to scale with page complexity. Provar's scenario was Salesforce Lightning, an unusually heavy enterprise UI; Judis's was a small demo shop. If token cost is your deciding factor, measure it on your own pages. Note also that the server ships several levers aimed directly at this: --snapshot-mode none, --mobile (documented as saving tokens because mobile pages are lighter), browser_find for searching a snapshot instead of capturing all of it, and a filename parameter on snapshot, console and network tools that writes output to disk rather than into the response.

The README states plainly: "Playwright MCP is not a security boundary." That sentence is load-bearing, and it is applied consistently. The --allowed-origins and --blocked-origins flags carry the note that they do not serve as a security boundary and do not affect redirects. Secrets redaction is documented as "a convenience and not a security feature." allowUnrestrictedFileAccess is described as "a convenience defense to catch unintended file access, not a secure boundary."

Two public reports tested that position in March 2026. Issue #1495, "Critical RCE in Playwright-MCP Server via browser_run_code," was opened and closed on 30 March; issue #1479, on indirect prompt injection via accessibility snapshots, was closed on 31 March. Both were closed by a Playwright team member pointing to the README's Security section. Two commenters state their separate reports were rejected, one relaying the response "this behavior is by design and does not constitute a security vulnerability" — those accounts are second-hand and we could not independently confirm them. The repo has no published GitHub security advisories.

The team did respond substantively, just not with a sandbox. The tool was browser_run_code in v0.0.68 (14 February 2026) and in v0.0.71 (27 April); by v0.0.72 (30 April) it had been renamed browser_run_code_unsafe and now carries the description "Unsafe: executes arbitrary JavaScript in the Playwright server process and is RCE-equivalent." Naming and documenting the hazard is a legitimate answer for a tool intended to run as trusted local infrastructure — it is, in effect, the same trust level as giving an agent a shell.

One detail matters more than the rest and is not stated on any marketing page. We checked the source: runCode.ts declares capability: 'core', and the tool filter in tools.ts includes every tool whose capability starts with core unconditionally, before consulting the user's capabilities config. So browser_run_code_unsafe is always exposed by the server, and the --caps mechanism that gates vision, pdf, devtools, storage, network and testing cannot turn it off. The documented option list contains no per-tool disable flag; playwright.dev's guidance to "only enable it for trusted MCP clients" is therefore something you enforce on the client side, not on the server.

For a local single-user setup this is coherent and mostly unremarkable. It becomes a real decision if you follow the README's own instructions for running the server as a long-lived Docker service on port 8931 with --host 0.0.0.0: anyone who can reach that port gets RCE-equivalent access. --allowed-hosts is DNS-rebinding protection, not authentication. If you deploy that way, the boundary has to be yours.

A few documented limits are easy to miss until they bite.

The persistent profile is single-holder. The README flags it as important: "A persistent profile can only be used by one browser instance at a time, so concurrent MCP clients sharing the same workspace will conflict." Running several agents in parallel means --isolated or a distinct --user-data-dir per client. Profiles are keyed by a hash of the MCP client's workspace root, so different projects separate automatically but two agents in one project do not.

The Docker image is narrower than the local install. The README notes: "The Docker implementation only supports headless chromium at the moment." If your evaluation depends on Firefox, WebKit or Edge, that happens outside the container.

The server runs headed by default — --headless is opt-in, which is the reverse of most CI expectations. Node.js 18 or newer is required.

Over HTTP, playwright.dev documents a five-second heartbeat timeout and advises adjusting timeout variables if your MCP client or proxy does not answer server-initiated pings. That is a plausible cause of unexplained disconnects behind a proxy.

The server documents 69 tools, up from 34 at v0.0.68 in February 2026 — the surface roughly doubled in six months, which is worth knowing both as evidence of active investment and as a context-budget consideration.

Most of it is off by default. Only the core automation group (23 tools) and tab management (1) load unless you ask for more; storage (16 tools), devtools (10), coordinate-based vision (6), network (4), testing (5), pdf and config are opt-in via --caps. So the default footprint is 24 tools, and you enable the rest deliberately. This is a genuinely well-judged default and the main reason the tool count should not alarm anyone.

The configuration surface is correspondingly deep: roughly fifty CLI flags, every one with an environment-variable equivalent, plus a JSON config file. Notable for evaluation work are --storage-state for seeding an authenticated session, --init-script and --init-page for setting up page state before any page script runs, --test-id-attribute, --device for emulation, and --codegen to emit TypeScript, Python, Java or C#. The opt-in vision capability exists as the escape hatch for pages where the accessibility tree is not enough — worth knowing if your target app leans on canvas or custom-rendered widgets, since that is precisely where the tree-based approach has least to work with.