Giving your agent a browser. Playwright MCP, honestly reviewed.

A coding agent without a browser lives in a strange half-world: it can refactor your entire E2E suite but cannot see the page the suite renders. I wired Playwright MCP into Claude Code two weeks ago and let it drive. These are the notes.

What it is

Microsoft’s MCP server over Playwright — the same automation engine that runs your test suite, exposed as tools: navigate, click, type, fill_form, snapshot, take_screenshot, manage tabs, upload files. Setup is one line:

claude mcp add playwright -- npx @playwright/mcp@latest

The design decision that matters: by default it drives the page through the accessibility tree, not pixels. Each snapshot hands the agent a numbered list of interactive elements, and the agent clicks by reference, not by coordinate. No vision model, no screenshot diffing, no “the button moved between screenshots”. There is an opt-in vision mode; the a11y route is the default, and it is the right default — deterministic, fast, and far cheaper than tokenizing images.

What it is good at

• Deploy smoke checks. “Open the staging URL, log in as the seeded user, open the invoices page, confirm the PDF link downloads, report.” Every deploy, on demand, without a test suite change.
• Scraping dashboards that need a login. Anything that renders via JavaScript behind an auth wall is invisible to curl and obvious to a browser.
• Boring form-filling. Admin panels, CRMs, that vendor portal with forty required fields. The agent is faster than you and complains less.
• Reproducing bug reports. “Go to this URL, do these three things, tell me what you see” — the report comes back with an accessibility snapshot instead of a shrug.

Token economics

The snapshot is the page for the agent, and a complex dashboard snapshot runs to thousands of tokens; a long session accumulates them. The fix is phrasing: “find the invoice link” costs a fraction of “describe the page”. Tell the agent what it is looking for and the meter stays polite.

The honest trade-offs

• Sessions and logins. Point it at a persistent profile or a storage-state file, or every session re-authenticates. 2FA flows will eat an afternoon — seed a test user instead.
• Bot detection. It is real Chromium, but headless automation still trips the aggressive detectors. Headed mode and a real profile help; nothing guarantees.
• CAPTCHAs it will not solve — and you should be glad, because the alternative is a product you have to keep away from your own infra.
• SPAs still race it. A re-render mid-task can stale out the refs it is holding; the agent recovers by re-snapshotting, which is tokens again.
• It will click Delete. An agent with a browser and prod credentials is a combination you scope deliberately: throwaway profile, test environment where possible, and no standing admin session.
• Speed. Slower than a human with a mouse on simple pages, much faster on the fortieth repetitive one. Know which job you are giving it.

Where it landed

The deploy smoke check is the keeper. The E2E suite still owns regressions — deterministic, versioned, fast; a browser-driven agent is none of those things. But the ad-hoc “is it up and does it look alive” question, which used to be me opening six tabs after every release, now goes to the agent with a browser. That division of labor has held for two weeks, which in this space is a longevity record.