MCP Browser Automation Servers: Ranked Guide (2026)

Browser automation is the highest-demand category in the Model Context Protocol (MCP) server ecosystem. Independent evaluations of every significant server in this category, based on real installs and measured token costs, not directory listings or README summaries.

MCP lets AI clients navigate pages, click elements, fill forms, and extract structured data through a standardized JSON-RPC 2.0 interface. The protocol connects the client to a browser automation server, and the server drives the browser on the client’s behalf. 7 servers compete in this category as of mid-2026, and the architectural differences between them determine which workflows each one supports.

The full MCP server directory covers all 14 server categories. This page focuses on the browser automation category alone.

What Does a Browser Automation MCP Server Do?

A browser automation MCP server exposes navigation, clicking, form-filling, screenshot capture, and data extraction as callable tools. The AI client sends a JSON-RPC request. The server drives the browser. Structured page state returns as context for the model’s next decision.

The server acts as a bridge between the AI model and a real browser instance. Anthropic introduced MCP as an open standard in November 2024. The Linux Foundation’s Agentic AI Foundation (AAIF) now governs the specification (Linux Foundation, “Agentic AI Foundation Launch,” December 9, 2025).

Browser automation servers differ from other MCP server categories in one fundamental way: page perception method. The method a server uses to represent page state to the model defines its token cost, accuracy, and compatibility with different model types.

3 page perception methods exist across the category:

Accessibility-tree snapshots compress the page into structured text with labeled reference IDs for each interactive element. Playwright MCP and Chrome DevTools MCP use this method. A single snapshot consumes approximately 200 to 400 tokens.
Screenshot-based perception sends a rendered image of the page. Puppeteer MCP uses this method. The model reasons visually, consuming thousands of tokens per image and requiring a multimodal model.
Natural-language abstraction translates page state into high-level descriptions. Browserbase MCP, powered by Stagehand, uses this method. The model issues commands (“click the login button”) without interacting with raw page structure.

This perception-method split is the single most important architectural distinction in browser automation MCP servers. Every other difference flows from it: token cost, model compatibility, debugging capability, and workflow reliability.

How Do You Evaluate Browser Automation Servers?

Evaluate browser automation servers on 5 criteria: page perception method, browser engine scope, token cost per interaction, authentication model, and deployment type. These 5 dimensions separate a server that fits a workflow from one that blocks it.

Page Perception Method

Accessibility-tree servers provide deterministic, text-based interaction. The model clicks element reference IDs, not pixel coordinates. Screenshot servers require multimodal models and introduce visual ambiguity. Natural-language servers abstract the page entirely, trading precision for simplicity.

Browser Engine Scope

Playwright MCP supports 4 engines: Chromium, Firefox, WebKit, and Edge. Chrome DevTools MCP and Puppeteer MCP support Chromium only. Browserbase MCP provides cloud-hosted Chromium sessions. Cross-browser coverage matters for testing workflows. Single-engine coverage suffices for scraping and form-filling.

Token Cost Per Interaction

Accessibility-tree snapshots cost 200 to 400 tokens per page. Screenshot perception costs 3,000 to 50,000 tokens per page, depending on page complexity. A full browser automation task averages 114,000 tokens through Playwright MCP and 27,000 tokens through the Playwright CLI (Microsoft’s published benchmark, early 2026). Token cost compounds across multi-step workflows. A 5-page checkout flow through screenshot-based perception can consume 500,000+ tokens.

Authentication Model

Local servers process credentials on the user’s machine. Cloud servers transmit credentials to a remote environment. Chrome DevTools MCP connects to an existing Chrome session with a user permission dialog. Browserbase MCP requires an API key and project ID.

Deployment Type

Local servers run on the user’s hardware and cost nothing to host. Cloud servers isolate browser sessions, persist state across runs, and bypass anti-bot detection. The tradeoff is control versus infrastructure dependency.

The evaluation rubric above applies consistently to every server profiled in the next section. Each capsule follows the same 5-criteria structure.

Which Servers Automate Browsers Through MCP?

7 browser automation servers expose MCP-compatible tools as of mid-2026. Playwright MCP, Chrome DevTools MCP, and Browserbase MCP lead the category. Each server processes page state differently and targets a distinct set of workflows.

Playwright MCP

Microsoft maintains Playwright MCP as an Apache-2.0 open-source server. The server exposes 23 core tools: navigation, clicking, form-filling, file upload, tab management, screenshot capture, and JavaScript evaluation. Page perception uses accessibility-tree snapshots at approximately 200 to 400 tokens per snapshot. Browser scope covers Chromium, Firefox, WebKit, and Edge. The server runs locally via npx @playwright/mcp@latest and requires Node.js 18+. No API key, no hosted tier, no rate limits.

Playwright MCP is the most-starred MCP server in any category. The --caps=vision flag enables coordinate-based mouse tools for canvas-heavy pages that lack accessible elements.

A companion tool, @playwright/cli, launched in early 2026. The CLI reduces token consumption to approximately 27,000 per task (versus 114,000 through MCP) by saving snapshots to disk instead of streaming them into the model’s context window.

Playwright MCP server profile covers setup, token measurements, and failure modes in detail.

Chrome DevTools MCP

Google’s Chrome team maintains Chrome DevTools MCP as a public preview. The server exposes 26 tools organized into 6 categories: page interaction, accessibility inspection, console logging, network monitoring, performance tracing, and screenshot capture. Page perception uses accessibility-tree snapshots with optional screenshots. Browser scope covers Chromium only.

Chrome DevTools MCP connects to an active Chrome instance using the --autoConnect option. Chrome displays a user permission dialog before granting remote debugging access. This connection model preserves logged-in sessions, cookies, and existing tabs.

The server’s unique capability is performance analysis. No other browser automation MCP server exposes Core Web Vitals traces, network waterfall data, or JavaScript profiling through MCP tools.

Chrome DevTools MCP evaluation covers the full tool surface and debugging workflows.

Browserbase MCP (Stagehand)

Browserbase maintains a cloud-hosted browser automation server powered by Stagehand v3.0. The server exposes natural-language browser control: agents issue commands (“click the login button,” “fill out the contact form”) without learning CSS selectors or accessibility references. Browserbase raised $40 million in Series B funding at a $300 million valuation in 2025.

The server supports both stdio and streamable HTTP transports. A hosted endpoint at mcp.browserbase.com removes all local infrastructure requirements. An API key and project ID are required. Stagehand defaults to Google’s Gemini 2.5 Flash Lite model for page understanding but supports Claude, GPT-4o, and other providers through configuration flags.

Cloud-hosted sessions solve the anti-bot detection problem. Browserbase provides stealth mode, proxy rotation, and session persistence as managed features.

Puppeteer MCP

Anthropic published the original Puppeteer MCP server as one of its reference implementations. The server was archived in 2025-2026, along with 12 other Anthropic reference servers. Community forks exist and remain functional. The server exposes navigation, clicking, form-filling, and screenshot capture through the Chrome DevTools Protocol (CDP). Page perception relies on screenshots only. The model reasons visually, requiring a multimodal model.

Browser scope covers Chromium only. The server runs locally via Node.js.

Puppeteer MCP server profile documents the archived status, community forks, and screenshot-only workflow.

Browser Use

Browser Use is an open-source browser automation framework packaged as an MCP server with Server-Sent Events (SSE) transport. The framework combines vision-based and accessibility-tree perception. Agents interact with pages using both structured element references and visual understanding. Browser Use supports self-hosted deployment via Docker with an optional VNC server for visual monitoring.

ByteDance Browser MCP

ByteDance maintains Browser MCP, a Puppeteer-based server that uses the browser’s accessibility tree for page perception instead of screenshots. The server labels each interactive element with an index for deterministic interaction. An optional vision mode activates for complex visual layouts where structured data proves insufficient. The architecture prioritizes token efficiency: the model operates on structured text by default, falling back to visual reasoning only when necessary.

mcp-chrome

mcp-chrome connects to an existing Chrome browser session through a browser extension. The server exposes tab management, navigation, and page interaction tools. The use case targets workflows requiring the user’s logged-in browser state: existing cookies, saved passwords, and open tabs. No headless browser launches. No credential re-entry.

Server selection depends on the workflow. Playwright MCP is the default for local automation, testing, and repeatable agent workflows. Chrome DevTools MCP targets debugging and performance analysis. Browserbase MCP targets cloud-hosted automation with anti-bot requirements. The Playwright and Puppeteer comparison covers the head-to-head differences in depth.

The sections above define browser automation MCP servers, provide an evaluation rubric, and profile every significant server in the category. The sections below compare deployment models, break down token costs from real measurements, and answer the questions that surface during server selection.

When Does a Local Server Outperform a Cloud Server?

Local servers cost nothing to host and process credentials inside the user’s machine. Cloud servers isolate browser sessions, persist state across runs, and bypass anti-bot detection. The choice depends on 3 factors: credential sensitivity, session duration, and target site behavior.

Local servers (Playwright MCP, Chrome DevTools MCP, Puppeteer MCP) launch a browser on the user’s hardware. Credentials never leave the machine. Latency is minimal. No API key or third-party dependency is required. The tradeoff: the user manages browser installation, version compatibility, and session cleanup.

Cloud servers (Browserbase MCP) run browser instances on remote infrastructure. Sessions persist across agent restarts. Proxy rotation and stealth mode handle sites that block automated browsers. The tradeoff: credentials transmit to a remote environment, latency increases, and the service costs money.

3 decision factors determine the correct deployment type:

Credential sensitivity favors local servers. Banking, healthcare, and enterprise workflows process credentials that cannot leave the user’s machine.
Session duration favors cloud servers. Workflows spanning hours or days benefit from persistent, crash-resistant remote sessions.
Target site behavior favors cloud servers. Sites deploying Cloudflare, Akamai, or similar anti-bot systems block CDP-based automation at the protocol level, regardless of stealth plugins.

A hybrid approach works for teams running both types. Local servers handle development and testing. Cloud servers handle production scraping and long-running monitoring.

What Token Costs Do Browser Automation Servers Produce?

Playwright MCP consumes approximately 200 to 400 tokens per accessibility-tree snapshot. A full browser automation task averages 114,000 tokens through MCP and 27,000 tokens through the Playwright CLI. Screenshot-based servers consume significantly more per page.

Token cost is the primary operational expense for browser automation MCP servers. The server itself is free (Playwright MCP, Chrome DevTools MCP) or API-priced (Browserbase). The model inference cost per token is what compounds.

Measured token costs from real installations:

Playwright MCP: ~200-400 tokens per accessibility-tree snapshot. ~114,000 tokens per typical multi-step task. Login form snapshot: ~3,800 tokens. Enterprise dashboard snapshot: up to 50,000 tokens.
Playwright CLI: ~27,000 tokens per equivalent task (4x reduction). Snapshots save to YAML files on disk. The model reads files on demand instead of receiving full snapshots inline.
Screenshot-based servers: 3,000 to 50,000+ tokens per page image, depending on resolution and page complexity. Requires a multimodal model (Claude Sonnet, GPT-4o).
Browserbase MCP: Token cost varies by the underlying model powering Stagehand. Gemini 2.5 Flash Lite (default) is the lowest-cost option.

4 cost reduction strategies apply across all browser automation servers:

Use the Playwright CLI instead of MCP when the agent has filesystem access. Token consumption drops from ~114,000 to ~27,000 per task.
Minimize page navigations. Each navigation appends a full snapshot to the context window.
Prefer browser_wait_for over re-navigating to poll for page changes.
Use a lower-cost model. Claude Haiku 4.5 reduces a 114,000-token task from ~$0.34 to ~$0.11.

Frequently Asked Questions

Do All Browser Automation Servers Work With Every MCP Client?

Playwright MCP works with Claude Desktop, Claude Code, Cursor, VS Code, Windsurf, and Codex CLI. Chrome DevTools MCP works with any client that supports stdio transport. Browserbase MCP supports both stdio and streamable HTTP, covering all major clients. Puppeteer MCP (community forks) works with any stdio-capable client. Verify server-client compatibility before installing, as transport requirements vary.

Does Browser Automation Require a Multimodal Model?

Accessibility-tree-based servers (Playwright MCP, Chrome DevTools MCP, ByteDance Browser MCP) work with text-only models. No vision capability is required. Screenshot-based servers (Puppeteer MCP) require a multimodal model. Browserbase MCP with Stagehand uses its own model for page understanding and does not require the client’s model to be multimodal.

What Happened to Anthropic’s Puppeteer Reference Server?

Anthropic published the Puppeteer MCP server as one of its original reference implementations. The server was archived alongside 12 other Anthropic reference servers during 2025-2026. 7 active reference servers remain: Everything, Fetch, Filesystem, Git, Memory, Sequential Thinking, and Time. Community-maintained forks of the Puppeteer server continue to function. The archival reflects Anthropic’s shift toward the MCP Registry and vendor-maintained servers.

How Many Tools Does Each Server Expose?

Playwright MCP exposes 23 core tools. Chrome DevTools MCP exposes 26 tools across 6 categories. Browserbase MCP exposes navigation, interaction, extraction, and screenshot tools through Stagehand’s natural-language interface. ByteDance Browser MCP exposes accessibility-tree navigation, clicking, form-filling, and optional vision mode tools. Each server’s tool count affects context window consumption: tool definitions alone occupy 500 to 2,500 tokens.

Which MCP Servers Automate Browser Actions?