Microsoft’s Playwright MCP hands an AI agent a real Chromium and a structured accessibility tree instead of pixels. It is genuinely fast. The bill arrives in tokens, not milliseconds.
- 24
- Tools exposed
- 18ms
- tools/list
- 84ms
- Warm navigate
- 31.8k
- Tokens per snapshot
How this was tested
Same laptop as the rest of this series: an i5-10210U, 7.62 GiB to Docker Desktop 29.6.2 on WSL2, with Immich, Paperless and Jellyfin all stopped first.
I ran the official mcr.microsoft.com/playwright/mcp image in HTTP mode and drove it with my own JSON-RPC harness rather than through an AI client. That matters: every figure below is the protocol round trip, with no model latency mixed in.
Reported version is @playwright/mcp 0.0.79 on Node 22.23.2, with the server identifying as Playwright 1.63.0-alpha-2026-08-05 and negotiating MCP protocol 2025-06-18.
Installation
One image, one command, no configuration file. It pulled in 38.3 seconds and the port was accepting connections 10.9 seconds after docker run.
# Verified on Windows 11 + Docker Desktop 29.6.2 (WSL2), 9 Aug 2026
docker run -d -i –rm –init
–name playwright-mcp -p 8931:8931
–entrypoint node mcr.microsoft.com/playwright/mcp
/app/cli.js –headless –browser chromium –no-sandbox
–port 8931 –host 0.0.0.0
The image is 1.46 GB, which is modest given it carries a full Chromium. Fresh idle memory before any browser launches is 74.6 MiB.
It is fast
The handshake takes 146 ms and tools/list returns 24 tools in 18 ms. Once a browser is warm, navigating to a simple page takes 84 ms and an accessibility snapshot 13 ms.
The first navigate in a session costs 1,176 ms because it launches Chromium. Worth knowing if your agent creates a session per task rather than reusing one: in a separate run where each attempt opened a fresh session, navigation ranged from 2.6 to 6.0 seconds.
Under sustained load the container peaked at 190.5% CPU and 189.3 MiB. After roughly a dozen sessions it settled back to 90 MiB against a 74.6 MiB baseline, so browsers are being cleaned up rather than leaked.
The real cost is context, not time
This is the number nobody mentions. A snapshot is text, and it goes straight into your model’s context window.
Example.com returns 411 characters, about 102 tokens. Playwright’s own homepage returns 14,380. A GitHub repository page returns 56,344. A single Wikipedia article returns 127,347 characters, roughly 31,800 tokens.
One snapshot of one ordinary page can consume more context than most conversations. An agent that browses three or four content-heavy pages will exhaust a 128k window on page structure alone, before it has done any thinking. Budget for that, and prefer browser_find over blanket snapshots where you can.
The tools, and one that should worry you
Twenty-four tools covering navigation, clicking, typing, form filling, drag and drop, tabs, dialogs, file upload, network inspection and console messages. The coverage is genuinely complete for agent work.
One deserves a hard look before you enable it. browser_run_code_unsafe executes arbitrary JavaScript in the Playwright server process and is, in Microsoft’s own framing, remote-code-execution equivalent. The project documentation also states plainly that Playwright MCP is not a security boundary.
It works, and here is the proof
That image was produced by the tool under review. I resized the viewport to 1280×800 through browser_resize, navigated, waited, then called browser_take_screenshot, which returned a 344 KB PNG as base64 over the wire.
Where it wobbled
Two things, and I want to be precise about both because neither is damning.
A session died mid-run with an HTTP 404, meaning the server no longer recognised the session ID. The container had not restarted, RestartCount was 0 and it was not OOM killed. I could not reproduce it: three fresh attempts at the same page all succeeded. One unexplained session drop in roughly a dozen sessions.
More reproducible, and more useful to know: a snapshot taken immediately after navigation returned 58 characters where the same page returned 14,014 a moment later. The page had not settled. If your agent navigates and immediately snapshots, it will sometimes read an empty room. Use browser_wait_for.
Who should use it
Use it if you are building agents that need to operate real web applications, and you want structured accessibility data rather than vision models guessing at screenshots. It is fast, complete and officially maintained.
Think twice if your context budget is tight, or if the agent will visit pages you do not control. The token cost is the binding constraint, and the security posture is explicitly not a sandbox.
