MCP Servers for Browser Automation

Playwright is the strongest all-round choice among browser automation MCP servers today. It scores 100/100 in the CheckMCP audit, covers Chromium, Firefox and WebKit, and ships 7 tools for navigation, clicking, typing and screenshots. Puppeteer offers a lighter, Chrome-only alternative, while Browserbase, Hyperbrowser, CUA and Scrapybara move sessions to the cloud or add generic computer-use control for agents that need more than a browser tab. Which one fits depends on whether sessions run locally or at volume in the cloud.

Why Does an Agent Need to Control a Real Browser?

Most web pages an AI agent needs to read are rendered with JavaScript, gated behind logins, or built from forms that only reveal data after a click. A plain HTTP fetch returns raw HTML and misses anything the browser builds afterward, so an agent that only calls REST endpoints cannot fill a checkout form, wait for a dashboard to load, or read a table that appears after a search. Browser automation MCP servers solve this by handing the agent a real, controllable browser instead of a text snapshot.

Playwright's own documentation frames this directly: the project gives "one API to drive Chromium, Firefox, and WebKit — in your tests, your scripts, and your agent workflows," according to playwright.dev. The Playwright MCP server built on top of that engine works through accessibility snapshots rather than raw screenshots, which is how Playwright exposes tools like browser_navigate, browser_click and browser_fill_form to an agent without asking it to parse pixels.

The tradeoff is that a real browser is heavier than an API client: it needs a process to run, a place to run it, and a way to keep sessions isolated between tasks. That is why the servers in this list split into three groups — local browser drivers, hosted cloud browsers, and generic computer-use agents — each answering the "where does the browser actually run" question differently.

Playwright or Puppeteer for Multi-Browser Automation?

Playwright is built and maintained by Microsoft on top of the open-source Playwright engine. The CheckMCP audit of microsoft/playwright-mcp gives it 100/100 (grade A), with 36,404 stars, an Apache-2.0 licence, 4 open issues and a last commit 2 days ago at audit time. It exposes 7 tools, including browser_navigate, browser_snapshot, browser_click, browser_type, browser_take_screenshot, browser_evaluate and browser_fill_form. Install it with mcpizy install playwright, or run it directly with npx -y @playwright/mcp.

Puppeteer takes a narrower approach: it drives headless Chrome only, with 6 tools covering navigation, screenshots, clicks, form fills, dropdown selection and raw JavaScript evaluation through puppeteer_evaluate. Install it with mcpizy install puppeteer, or run npx -y @modelcontextprotocol/server-puppeteer directly. Configuration is identical across clients — Claude Code, Cursor and Windsurf all read the same command and args pair, only the config file path changes.

For teams already writing Playwright test suites, pairing the MCP server with the Visual Regression on PRs recipe keeps agent-driven checks and CI checks on the same engine. Anyone new to running Playwright MCP end to end can follow the How to Use Playwright MCP with Claude Code guide for the full client setup.

What Do Browserbase and Hyperbrowser Add as Hosted Browsers?

Browserbase runs the browser in the cloud instead of on the agent's own machine. Browserbase's own documentation describes the platform as giving an agent "cloud browsers, web search, page fetching, sandbox runtime, and access to every major LLM" behind one API key. The CheckMCP audit of browserbase/mcp-server-browserbase scores it 54/100 (grade F): the repository is archived, the last commit was 34 days before the audit, and it carries 51 open issues against 3,409 stars and an Apache-2.0 licence. Install with mcpizy install browserbase, or run npx -y @browserbasehq/mcp directly.

Hyperbrowser targets the same hosted use case — its own listing describes "headless browsing at scale" for AI agents. The CheckMCP audit of hyperbrowserai/mcp scores it 63/100 (grade D), with 790 stars, an MIT licence, 8 open issues and no commit for 9 months at audit time. Install with mcpizy install hyperbrowser, or run npx -y hyperbrowser-mcp directly.

Both servers remove the need to manage local browser binaries or worry about a laptop going to sleep mid-session, which matters for agents that run unattended. The CheckMCP scores are the main signal to weigh against that convenience: Browserbase's archived status and Hyperbrowser's 9-month gap between commits are both facts a team should check against their own uptime needs before depending on either for production workloads, alongside How to Audit an MCP Server Before Install.

What Is a Computer-Use Agent, and Where Do CUA and Scrapybara Fit?

CUA goes beyond a browser tab: the trycua/cua repository describes it as a "Computer-Use Agent — let LLMs control computers, click buttons, type text, navigate GUIs," which covers desktop applications as well as web pages. The CheckMCP audit of trycua/cua gives it 100/100 (grade A), with 21,828 stars, an MIT licence, 710 open issues and a last commit dated today. Install with mcpizy install cua, or run uvx cua-mcp-server directly.

Scrapybara stays closer to the browser case: it controls Scrapybara cloud browsers for agentic web automation and scraping. Unlike the other five servers here, MCPizy could not verify a published package or a reachable endpoint for Scrapybara as of the 2026-08-11 check, so no install command is shown for it — a gap worth confirming directly before planning around it.

The practical split is that CUA suits an agent that needs to operate an entire desktop session, not just a browser, while Scrapybara's own description keeps it scoped to browser-based scraping and automation in the cloud. Neither has the multi-browser reach that Playwright's Chromium, Firefox and WebKit support gives, so the choice comes down to whether the task is "control a browser" or "control a computer."

BrowserMCP and GoLogin: Why Persistent Profiles Matter

Two servers show up repeatedly in the "alternatives" lists next to Browserbase, Hyperbrowser and Scrapybara: BrowserMCP and GoLogin. BrowserMCP is described as a way to "control your local Chrome browser directly," which puts it in the same local-first category as Playwright and Puppeteer rather than the hosted-cloud category of Browserbase and Hyperbrowser. That distinction matters for any workflow where the agent needs to reuse a browser session — and its logged-in cookies — that a human already has open.

GoLogin is listed as a way to "manage GoLogin browser profiles for multi-account automation and anti-detect browsing." That framing points to a different problem than raw page control: keeping several distinct browser identities — cookies, fingerprints, extensions — separate and persistent across runs, something single-session servers like Puppeteer are not built for.

Both point to the same underlying need: an agent that has to come back to the same logged-in state tomorrow, or juggle several accounts today, needs session or profile persistence that a stateless headless browser does not provide by default. That is a separate requirement from raw automation speed, and it is worth checking before assuming any browser automation MCP server in this list handles it out of the box.

How to Choose Between Local and Cloud Browser Sessions

Local drivers — Playwright, Puppeteer and BrowserMCP — run the browser on the same machine as the agent. That keeps latency low and avoids sending credentials to a third-party session, but it also means the agent's own machine has to stay awake and has to have the right browser binaries installed. This fits coding agents like Claude Code or Cursor running on a developer's own laptop, where a single session at a time is normal.

Cloud drivers — Browserbase, Hyperbrowser and Scrapybara — move that browser process off the agent's machine entirely, which is the model to reach for once an agent needs to run many sessions in parallel, or needs to keep running after the developer's laptop is closed. The cost of that convenience shows up in the CheckMCP audit scores for two of the three: Browserbase at 54/100 with an archived repository, and Hyperbrowser at 63/100 with no commit for 9 months, both well below Playwright's and CUA's 100/100.

Volume is the deciding factor in practice: a handful of local test runs favor Playwright or Puppeteer, a fleet of unattended scraping agents favors a hosted option, and any task that spans more than a browser tab — clicking through a desktop installer, for instance — points toward CUA. Teams still deciding between running a server on their own infrastructure versus a hosted one can check Local vs Remote MCP Servers: What Changes for the tradeoffs that apply beyond browser automation specifically.

FAQ

Is Playwright or Puppeteer better for browser automation MCP work?

Playwright covers more ground: the CheckMCP audit gives microsoft/playwright-mcp 100/100 (grade A), and Playwright's own documentation credits it with driving Chromium, Firefox and WebKit from one API, plus 7 MCP tools including form filling. Puppeteer, by contrast, drives Chrome only and exposes 6 tools, with no CheckMCP score published for it. For a task that has to work identically across browser engines, or that benefits from a graded, actively maintained repository, Playwright is the safer default; Puppeteer remains a reasonable, lighter pick for Chrome-only scripting.

Does Puppeteer MCP have a published audit score?

No score has been published for Puppeteer in the CheckMCP audit at the time of writing, unlike Playwright, Browserbase, Hyperbrowser and CUA, which all carry a grade. That does not say anything about Puppeteer's quality on its own — it simply means the comparison points available for it are its tool count and install command rather than a maintenance grade. Anyone choosing between the two should weigh Playwright's documented 100/100 score against Puppeteer's narrower, Chrome-only feature set instead.

Can Scrapybara MCP be installed today?

As of the 2026-08-11 check referenced on its listing, no published package or reachable endpoint could be verified for Scrapybara, so no install command is shown. Its description still positions it as a server for controlling Scrapybara cloud browsers for agentic web automation and scraping, which puts it in the same hosted-cloud category as Browserbase and Hyperbrowser. Anyone planning around it should confirm current availability directly before committing a workflow to it, rather than assuming the description alone guarantees a working endpoint.