Stack d'Automatisation Navigateur MCP

What this pack actually solves

The MCP browser servers all promise the same thing — let your AI assistant click, type, and read a webpage. In practice they make different tradeoffs around determinism, cookie scope, iframe support, debug visibility, and CI-friendliness. This pack picks ten servers that together cover those tradeoffs explicitly, and orders them so each install unlocks the next layer.

The target user is a developer wiring a browser into Claude Code, Cursor, or Gemini CLI for end-to-end testing, scraping behind a login, agent-driven dogfooding, or live UI debugging. By the end of the install order your agent can pick the right MCP for a given task instead of brute-forcing one server into every shape.

Install in this order

1. Playwright MCP Server (official, Microsoft) — start here. Snapshot-based actions are deterministic, the API surface is small, and it works against Chromium, Firefox, and WebKit. The accessibility-tree snapshot is what makes agents reliable: they read structured node IDs instead of guessing CSS selectors. According to the Playwright docs the snapshot format is the recommended interface for AI clients.
2. Playwright MCP — Browser Automation Server (community npx) — same engine, lighter setup via npx. Use this when you want to bolt onto an existing Playwright install without the official package's bundling. Good fit for Codex / Cursor power users.
3. Chrome DevTools MCP — the second MCP you install, not the first. It hangs off DevTools Protocol and exposes network, console, performance traces, and DOM inspection. Pair it with Playwright MCP: Playwright drives the page, Chrome DevTools MCP tells you why it broke.
4. Chrome MCP Server (extension-based) — different model. Runs as a Chrome extension instead of a separate browser process, which means it reuses your real logged-in profile — cookies, extensions, saved passwords. Pick this when the site is gated by SSO or anti-bot and a fresh Playwright context gets challenged.
5. Puppeteer MCP — Headless Chrome Server — the lean choice for CI. No extra cross-browser layer, smaller install, faster cold start. Use it for pure Chromium scraping pipelines where you don't need Firefox / WebKit fallbacks.
6. Browserbase MCP — Cloud Browser — the escape hatch when local Chromium hits IP blocks, stealth requirements, or scale ceilings. Cloud-hosted browser pool with stealth profiles; the MCP server exposes the same tool shape so agent code is portable.
7. Multi-Browser MCP Proxies (Arc / Chrome Beta variants) — the iframe-aware layer. Stock Chrome MCP can't always reach into Arc's split panes or Beta's variant DOM trees; this proxy multiplexes between Arc / Beta / Chrome Stable so the agent picks the right window. Critical when the site renders core UI inside an iframe (most embedded checkouts, Stripe, Cloudflare challenges).
8. Chrome Fleet — Multi-Agent Browser Pool with Shared Login State — once you have multiple agents, login fatigue dominates. Fleet keeps a warm pool of authenticated browsers and hands each agent a checked-out instance. Cookie scope is per-fleet, not per-agent, which is the design tradeoff: faster onboarding, weaker isolation. Use it when your agents trust each other.
9. Chrome MCP Background Proxy — Popup / Focus Fix — the bug-fix MCP. Stock Chrome MCP loses focus when a popup or OAuth window opens and the agent's next click lands on the wrong tab. This proxy intercepts focus events and reroutes them deterministically. Install this before you wire up any login-required flow, not after you debug a flaky run.
10. BrowserToolsMCP — Audit Browser Logs via MCP — closes the loop. After the agent finishes a session, BrowserToolsMCP lets it (or you) replay console errors, network failures, and page lifecycle events. This is the difference between "the test passed" and "the test passed and emitted zero errors."

How they fit together

          Playwright MCP (deterministic, cross-browser)
                │
                ├── Chrome DevTools MCP (why it broke)
                │
          Chrome MCP (real profile)  ←  Multi-Browser Proxy (Arc / Beta)
                │
          Puppeteer MCP (CI lean)      Chrome Fleet (shared login)
                │
          Browserbase MCP (cloud, stealth)
                │
          Chrome MCP Background Proxy (popup focus fix)
                │
          BrowserToolsMCP (log audit)

The spine is Playwright MCP + Chrome DevTools MCP + BrowserToolsMCP — that trio handles 80% of agent browser work for a CI-style developer. Chrome MCP / Chrome Fleet are the real-profile branch when your site is locked behind SSO. Browserbase MCP is the escape hatch.

Cookies, sessions, iframes — pick the right scope

• Per-context cookies (Playwright MCP, Puppeteer MCP, Browserbase MCP) — each session starts clean. Best for tests. Worst for sites with bot detection that flags first-visit fingerprints.
• Real-profile cookies (Chrome MCP extension) — agent reuses your logged-in Chrome profile. Best for SSO-gated dashboards. Worst for parallel agents (they fight over the same cookie jar).
• Fleet-shared cookies (Chrome Fleet) — agents share a warmed-up pool. Best for many agents on one tenant. Worst for tenant isolation; you would not run two customers' agents on the same fleet.
• Iframe handling — Playwright MCP exposes frame snapshots natively; Chrome DevTools MCP can navigate cross-origin frames via CDP; Chrome MCP extension is limited to same-origin frames unless you ship a content script. If your target embeds Stripe / Cloudflare Turnstile / Auth0, plan for Playwright MCP plus the Multi-Browser proxy.

Debug-to-CI path

1. Develop locally with Playwright MCP + Chrome DevTools MCP. Run headed, watch the agent drive the page, read DevTools panel in real time.
2. Switch to BrowserToolsMCP to catch silent errors you missed — console warnings, failed XHRs, hydration mismatches.
3. Move to CI by swapping Playwright MCP for Puppeteer MCP (lighter) and running headless. If anti-bot blocks the CI IP, swap again to Browserbase MCP and keep the same tool calls.
4. Production agent fleet — Chrome Fleet for shared login, Background Proxy enabled to handle OAuth popups, BrowserToolsMCP scraping logs for the post-mortem dashboard.

Common pitfalls

• Installing Chrome MCP extension and Playwright MCP at the same time — they race for the same DevTools port. Pick one as the primary; use the other for fallback only.
• Forgetting npx playwright install — the official Playwright MCP requires the browser binaries. The MCP server fails opaquely if they're missing.
• Cookie scope confusion — agents that worked in dev (real profile) silently break in CI (fresh context) because the dashboard requires SSO. Decide cookie scope on day one.
• iframe blindness — Stagehand / Browser-Use style agents that work on simple pages crash on embedded checkouts. If your target uses iframes, default to Playwright MCP plus the multi-browser proxy.
• OAuth popup focus theft — install the Background Proxy before the first login flow, not after the third flaky run.