The agent clicked an element ref and the wrong action executed — no error, no exception, just silently wrong behavior. What happened?
The signature silent failure of snapshot-based automation: stale element references. Refs (e5, e12...) are scoped to the exact snapshot that generated them. If the page re-renders between the snapshot and the click — React hydration, a lazy-loaded banner, an A/B test swap — the ref can be recycled by a DIFFERENT element, and the server clicks it without complaint. The engineering fix: treat refs as single-use tokens. Re-run browser_snapshot after any action that triggers navigation, DOM mutation, or a timed re-render, and never reuse refs across tool-call chains longer than one step. If your workflow is click-heavy, enable the server's snapshot-on-action behavior so every response carries a fresh tree.
Playwright MCP vs Firecrawl — when do I use which?
Firecrawl wins for read-only extraction: it is faster, cheaper per page, and returns clean markdown. Playwright MCP wins the moment the workflow requires interaction: login flows, form submission, multi-step wizards, infinite scroll, or content behind clicks. The mature stack runs both — Firecrawl for reading the web, Playwright for operating it.
Why does the agent freeze on pages with alert or confirm dialogs?
JavaScript dialogs block the page's main thread, and the snapshot call hangs waiting for a page that cannot respond. The server exposes browser_handle_dialog precisely for this — instruct the agent to accept or dismiss dialogs immediately when they appear, or the session deadlocks silently until timeout.
Can it run multiple isolated sessions in parallel?
Not within one server instance — the session is stateful and single-browser by design. For parallelism, run multiple MCP server instances on different ports, or delegate to a browser-grid backend via --cdp-endpoint. Forcing parallel prompts through one session produces interleaved, corrupted state.