What it does

Gives an agent a real browser it can navigate, click, type into and read — using Playwright’s accessibility-tree snapshots instead of screenshots, so the model works from structured text rather than pixels.

Tested hands-on (2026-07-29)

Ran it directly over stdio — bunx @playwright/mcp@latest, no config, no auth, no account. The initialize handshake came back clean in under a second, exposing 24 tools: navigation, clicking/typing/hovering/dragging, tabs, network and console inspection, file upload, dialog handling, and a raw JS evaluator.

The core claim held up under an actual test: browser_navigate to a real page took 983ms (mostly the browser cold-starting), but the follow-up browser_snapshot came back in 12ms with a clean structured accessibility tree — headings, links, and text nodes with stable refs, not a screenshot. That’s the whole pitch, and it’s real.

One thing worth flagging that only showed up by actually testing it: the tool list includes browser_run_code_unsafe — arbitrary JS execution in the browser context, named unsafe by its own author. It’s genuinely useful for edge cases, but it’s also the one tool in this list that deserves real scrutiny before you grant it to an agent you don’t fully trust. Scope your agent’s allowed tools rather than handing over the full 24.

The short verdict

The accessibility-tree approach is the right call: faster and far more deterministic than vision-based browsing, and it degrades gracefully on complex pages. This has become the de-facto standard browser tool for coding agents — for good reason. Watch memory if you leave sessions open for long agent runs, and treat browser_run_code_unsafe as a distinct permission decision, not part of the default toolset.

Playwright MCP (Microsoft)

What it does

Tested hands-on (2026-07-29)

The short verdict