Add the Playwright MCP server so Claude drives a real browser through the accessibility tree, not screenshots

The Playwright MCP server is Microsoft's official Model Context Protocol server for browser automation. It gives Claude a real browser that it drives through the page's accessibility tree rather than through screenshots, so the model reads and acts on structured page data instead of pixels. Where the last two Fridays covered a read-only documentation server and an account-wired GitHub connector, this is the third shape of MCP worth knowing: a local server that hands Claude a capability — a browser — with no account to connect and no token to scope.

Why feature it now. It has become the reference example for the “give the agent a tool, not an API key” pattern, and the default way to let a coding agent see and click a live web page. It installs with a single command and no Docker. One honest caveat up front: the project's own README now notes that for high-throughput coding work, CLI-driven workflows exposed as skills can be more token-efficient than MCP, because they avoid loading verbose accessibility trees into context. The server is still the cleanest way to understand what an action-capable local MCP server is, but the ecosystem is already weighing MCP against CLI for exactly this job, and it is worth knowing that debate exists before you wire it into everything.

See a page. The core of the server is two tools: browser_navigate opens a URL and browser_snapshot returns the accessibility tree — every interactive element with a stable reference. “Open this docs page and tell me what the pricing tiers are” works without you pasting any HTML, and it is far cheaper in tokens than a screenshot because there are no images to encode and no vision model in the loop.

Drive a flow. On top of snapshot sit browser_click, browser_type, and browser_fill_form. Claude can fill a form, click through a multi-step flow, select a dropdown, and verify the result, all by element reference rather than by guessing coordinates. That is the skeleton of an end-to-end test or a repetitive web chore: “log into the staging dashboard and confirm the deploy banner is gone.”

Opt-in capabilities. The base server is deliberately small. Extra capabilities are off by default and turned on with --caps: vision for coordinate-based clicks, pdf to render a page to PDF, devtools for the console and network panels. That last one is the SRE angle — pull the failing console errors and network traffic off a broken page without leaving the session you are already working in.

The trap to avoid is treating it like a headless robot you forget about. By default it launches a headed browser with a persistent profile saved to disk, which means it can pick up your real cookies and logged-in sessions. For anything automated or untrusted, pass --isolated to keep the profile in memory and --headless to run without a window. And resist enabling every capability: each --caps entry adds tools to context and dulls tool choice, the same failure mode as the wide-open GitHub install warned about last Friday. Turn on what the task needs and nothing more.

The try-it block installs the server and gives you one prompt that exercises navigate plus snapshot, so you can confirm Claude is reading a live page before you point it at anything real.