MCP field guide / Playwright
// mcp field guide · browser automation
The most interesting risk profile in the guide, because it breaks the pattern: here the danger isn't in the tool name. browser_click is identical whether it clicks "next page" or "Place order — $4,000." The same handful of tools spans harmless browsing and irreversible real-world commits. That changes what a guard has to look at.
GUARD FIT · READ + NAVIGATE
PASS-THROUGHSnapshots, screenshots, navigation and reads observe or move around. Gating every click is impractical and trains rubber-stamping.
GUARD FIT · SUBMIT / CONFIRM / CODE
STRONGA form submit, a "confirm purchase," a "delete," and arbitrary-code tools (browser_evaluate) are the real checkpoints — often irreversible.
Overall fit: MODERATE → STRONG, and the strength is contextual — it depends on the site, not the tool.
Playwright MCP (@playwright/mcp, by Microsoft, Apache-2.0, v0.0.79 — a pre-1.0 project) gives an LLM real browser-automation control. Its defining design choice: it drives pages through structured accessibility snapshots (the accessibility tree) rather than screenshots, so it needs no vision model and stays deterministic. It exposes 40+ tools across navigation, input, form filling, tabs, network, storage, screenshots and JavaScript evaluation — all operating on a live browser session.13
The tool names are innocuous. The blast radius lives in the target site.
| Tier | Tools |
|---|---|
| read / observe | browser_snapshot, browser_take_screenshot, browser_find, browser_console_messages, browser_network_requests, browser_tabs (list) |
| navigate / input | browser_navigate, browser_click, browser_type, browser_fill_form, browser_select_option, browser_press_key, browser_hover, browser_drag, browser_file_upload, browser_wait_for |
| consequential | browser_evaluate (arbitrary JS), browser_run_code_unsafe (arbitrary Playwright code — the name flags it); any input tool re-pointed at a "Buy" / "Submit" / "Send" / "Delete account" control; storage/cookie writes (browser_cookie_set/_delete), network mocking (browser_route) |
The classification problem, stated honestly: browser_click(ref=…) does not, by its name, tell you whether you're advancing a wizard or charging a card. The risk signal lives in the arguments and current page state — the target URL/origin and the element's accessible label ("Place order", "Pay $X") from the snapshot — not the tool identity. (Names in the opt-in network/storage/DevTools groups are from the repo README only and may shift in this fast-moving 0.0.x project — treat them as UNVERIFIED against your installed build.)
Automated E2E / UI testing. Navigate flows, assert visible elements, emit locators/traces for regression suites.
Scraping & extraction. Snapshot the accessibility tree or evaluate JS to pull structured data from JS-heavy pages.
Agentic web tasks. Multi-step goals on live sites — research, filling forms, booking, comparison shopping.
Gating every action is impractical. One agentic task fires dozens of browser_click/browser_type calls; an "approve each click" wall makes the tool unusable and trains the human to rubber-stamp — worse than no guard.
Gating the consequential confirm is exactly a checkpoint case. A form submit, a "confirm purchase," a "send," a "delete" — the moments a session crosses from browsing into committing real-world state — are the natural, high-value approval points. This is the guide's thesis at its sharpest: the same browser_click is harmless on a test page and consequential at checkout.
Arbitrary code is a standing checkpoint. browser_evaluate and browser_run_code_unsafe have unbounded blast radius regardless of target — they warrant a standing gate (or a policy block), independent of URL heuristics.
The honesty line: most web commits — a captured payment, a sent message, a deleted account — are irreversible; there's no mcp-compensate inverse Playwright can call to "un-buy." A guard here presents the action as irreversible and gates before commit. The engineering challenge — and the honest selling point — is that the impact must be surfaced from the target + element context, because the tool name is deliberately generic. That's compensation is not undo, meeting the open web.
ChronoMCP's classifier keys off the target URL and element label — passing navigation and reads through, and holding the consequential submit/confirm for a human.
Read the quickstart → More MCP profiles@playwright/mcp (v0.0.79, Apache-2.0): npmjs.com/package/@playwright/mcpProfiles describe third-party software from its public sources; ChronoMCP is not affiliated with Microsoft. Core tool names are verified; opt-in group names come from the repo README and may differ in your installed build (a 0.0.x project renames tools between releases). Risk groupings are our classification. Capabilities reflect sources current as of Aug 2026 — re-verify against your version's tools/list.