What MCP Servers Are Available for Browser Automation?

Short answer: Microsoft Playwright MCP and Chrome DevTools MCP are the strongest starting points for local browser automation. Playwright MCP focuses on cross-browser interaction through accessibility snapshots; Chrome DevTools MCP connects an agent to a live Chrome browser for inspection, debugging and performance work. Browserbase provides a hosted-browser route, while SeleniumBase documents a CDP-oriented MCP server.

This guide explains what each server does, how to install the documented options, how to choose between them, and how to handle browser profiles and authentication safely. The list reflects the maintained options identified in the research sources; it is not an exhaustive registry.

1. At-a-glance comparison

Server	Best fit	Browser or runtime model	Check before adoption
Microsoft Playwright MCP	General browser automation across engines	Structured accessibility snapshots; Chrome, Firefox, WebKit and Microsoft Edge	Node.js version, browser channel and optional capability groups
Chrome DevTools MCP	Chrome inspection, debugging and performance workflows	Agent connects to a live Chrome browser	Current Chrome, Node.js/npm requirements and profile access
Browserbase MCP	Hosted browser infrastructure	Remote browser sessions described in Browserbase’s comparison	Current availability, session model, pricing, regions and security controls
SeleniumBase MCP	Selenium users who want a CDP-oriented server	SeleniumBase Pure CDP Mode	Current installation steps and browser compatibility

Use Playwright MCP as the initial comparison point when cross-browser coverage and accessibility-oriented interaction matter. Choose Chrome DevTools MCP when the task is specifically Chrome and DevTools. Consider a hosted service when you need remote browser infrastructure rather than a local process.

2. Microsoft Playwright MCP

Playwright MCP exposes browser automation through structured accessibility snapshots. The official documentation covers Chrome, Firefox, WebKit and Microsoft Edge, plus connections to launched browsers, existing Chrome or Edge instances, Chromium CDP endpoints, Playwright servers and existing tabs through an extension. Optional capability groups include network, storage, testing, vision, PDF and DevTools.

Install and start

The getting-started guide lists Node.js 20 or newer and an MCP-compatible client as prerequisites. A typical server command is:

npx @playwright/mcp@latest

In an MCP client configuration, the command usually appears as a stdio server. Adapt the JSON shape to your client’s configuration format:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest"]
    }
  }
}

Select a browser

npx @playwright/mcp@latest --browser chromium
npx @playwright/mcp@latest --browser firefox
npx @playwright/mcp@latest --browser webkit
npx @playwright/mcp@latest --browser msedge

Use the browser selection that matches the behavior you need to reproduce. Keep the selected channel explicit in shared agent configuration so a teammate does not silently run the workflow in a different engine.

When to enable optional capabilities

Network: inspect or control requests when the workflow requires request-level visibility.
Storage: work with cookies or other browser storage deliberately.
Testing: expose testing-oriented interactions.
Vision: use visual interaction where accessibility structure is insufficient.
PDF: include document-generation workflows.
DevTools: add browser debugging-oriented operations.

Enable only the groups your agent needs. More capabilities increase what the agent can do and can make tool selection harder to reason about.

3. Chrome DevTools MCP

Chrome DevTools MCP connects an MCP-compatible client to a live Chrome browser for inspection, debugging and performance analysis. The official setup guide requires current stable Chrome plus Node.js (latest LTS) and npm.

Install and configure

npx chrome-devtools-mcp@latest

An MCP client entry commonly looks like this:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["chrome-devtools-mcp@latest"]
    }
  }
}

Use this server for tasks such as examining a page while it is open in Chrome, investigating console or network behavior, and carrying out DevTools-centered performance work. Recheck the official installation page before rollout because Node.js, Chrome and package requirements can change.

4. Browserbase MCP

Browserbase is the hosted-browser option in this comparison. Its vendor-authored overview describes remote browser infrastructure accessed through MCP. This is a deployment choice: the browser runs in a hosted environment instead of on the developer’s workstation.

Before selecting it, verify the current service availability, session lifecycle, pricing, geographic availability and security controls in the provider’s documentation. The comparison source does not establish a universal performance or reliability ranking.

5. SeleniumBase MCP

SeleniumBase’s MCP documentation describes a server built around SeleniumBase Pure CDP Mode. It is a sensible candidate when an existing SeleniumBase codebase or team workflow is the main constraint.

Follow the current maintainer instructions for installation and browser compatibility. The researched material does not provide a stable command that should be copied here, so avoid pinning an unverified invocation in automation.

6. How to choose a server

Define the browser requirement. Choose Playwright when you need Chrome, Firefox, WebKit or Edge coverage. Choose Chrome DevTools MCP when Chrome itself is the target.
Define the interaction model. Playwright’s accessibility snapshots are useful for structured page interaction. DevTools MCP is oriented around a live Chrome inspection workflow.
Choose local or hosted execution. Local servers keep the browser on your machine. A hosted option can provide remote browser infrastructure but adds provider, region and session-policy decisions.
List required capabilities. Decide whether the agent needs network, storage, testing, vision, PDF or DevTools operations.
Set the session boundary. Use a dedicated browser profile for automation and decide which cookies, extensions and accounts it may access.
Validate the workflow. Test the exact browser channel, login flow, downloads, popups and timing behavior your production task uses.

There is no source-backed speed or reliability winner among these servers. Compare them with the same page, browser version, network conditions and task script if those characteristics matter to your decision.

7. Security and authenticated sessions

Chrome for Developers warns: “Because your agent will be able to view and interact with the pages it accesses, it can effectively act on your behalf if you connect it to a browser with an active, authenticated session.” Treat an MCP connection to a logged-in browser as access to that account.

Playwright’s extension mode can reuse existing tabs, logged-in sessions, cookies and installed extensions. That is useful for SSO and existing-tab tasks, but it also makes the browser profile part of the agent’s security boundary.

Create a separate browser profile for automation.
Log in only to accounts required for the task.
Do not reuse a personal profile containing unrelated mail, billing or administration sessions.
Review extensions installed in the profile before attaching an agent.
Limit the MCP client’s filesystem, network and secret access where your client supports it.
Rotate credentials if a profile or session is shared more broadly than intended.

8. A practical first workflow

Install Node.js 20 or newer for Playwright MCP, or the latest LTS for Chrome DevTools MCP.
Install the server with the documented npx command.
Add the server to your MCP client configuration.
Start with a public, non-sensitive page.
Ask the agent to navigate, inspect the page and perform one small action.
Confirm which browser profile and account were used.
Add optional capability groups only after the core flow works.
Record the browser version, server package version and client configuration with the workflow.

9. Troubleshooting

The client cannot start the server

Cause: Node.js is missing, too old, npm is unavailable, or the client configuration uses the wrong command shape.

Fix: Check node --version and npm --version, install the required Node.js release, run the npx command manually, then copy the working command and arguments into the MCP client.

The requested browser is unavailable

Cause: The selected browser channel is not installed or the server is using a different channel than expected.

Fix: Install or select the documented browser, then make the browser argument explicit. Confirm whether the workflow is targeting Chromium, Firefox, WebKit, Edge or Chrome.

The agent cannot see the page structure

Cause: The page may be heavily canvas-based, still loading, or exposing little useful accessibility structure.

Fix: Wait for the page to settle, inspect the rendered state, and enable a visual capability only when the task truly needs it. For Chrome-specific diagnosis, try Chrome DevTools MCP.

Cause: The server launched a clean profile instead of the profile containing the session, or the extension was not attached to the intended tab.

Fix: Use a dedicated profile and the documented connection method for the workflow. Verify the profile and tab before exposing credentials to the agent.

Actions affect the wrong account

Cause: An active authenticated profile contains multiple accounts or unrelated tabs.

Fix: Stop the run, close unrelated tabs, use a task-specific profile and sign in only to the required account.

The workflow is flaky

Cause: Timing, browser version, network state, popups or page changes differ between runs.

Fix: Add explicit waits around meaningful page states, pin the browser and package versions where practical, remove unrelated extensions, and capture logs or DevTools evidence for failed runs.

10. Performance, reliability and cost considerations

Performance: Browser startup, page load, network requests and rendering dominate most runs. Reusing a controlled browser session can avoid startup work, but it also increases session-management responsibility.
Reliability: Keep browser and package versions known, use deterministic test pages where possible, and record failures with enough context to reproduce them.
Cross-browser coverage: Test each engine you claim to support. A workflow that passes in Chrome may expose different behavior in Firefox, WebKit or Edge.
Hosted execution: For Browserbase or another hosted provider, account for session limits, region selection, network policy and current pricing.
Agent permissions: The cost of a mistake is not only compute. An authenticated browser can expose data or perform account actions, so minimize the profile and capabilities.

11. Or skip the browser setup

If your goal is a clean screenshot rather than interactive browser control, ScreenshotNeo provides a single HTTP request that returns a PNG, JPEG, WebP or PDF. Before capture it accepts cookie or consent banners and removes more than 60 known consent platforms, newsletter popups and chat widgets. Bot checks, blank pages, timeouts, failed loads and cache hits are not billed, and each response identifies the result with X-Page-Verdict and X-Billed headers. It also has an MCP server with take_screenshot, get_page_info and capture_pdf tools for Claude, Cursor and other MCP clients.

See the ScreenshotNeo API documentation for the full option list. The basic request is:

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo includes full-page capture with lazy images loaded, element capture by CSS selector, dark mode, 12 device presets and custom viewports, retina scale, PDF paper sizes and page ranges, HTML/CSS to image, custom CSS and JavaScript, clicks, waits, request blocking, headers, cookies, user agents, authorization, timezone, geolocation, transparent backgrounds, resizing, TTL caching, signed links, asynchronous jobs with signed webhooks, bulk capture for 100 URLs per call, a usage API and an OpenAPI specification. Its parameter names also match those used by other screenshot APIs, which simplifies migration.

Plans include 1,000 screenshots per month free with no card; paid plans start at $5 for 3,000 screenshots. Create a free ScreenshotNeo account.

12. FAQ

Which MCP server should I try first?

Try Playwright MCP for general cross-browser automation. Try Chrome DevTools MCP when the task is specifically Chrome inspection or debugging.

Can these servers automate an already-open tab?

Playwright documents an extension mode for connecting to existing tabs. Review the profile and session access before enabling it.

Is Browserbase faster than local Playwright?

The researched sources do not provide a comparable benchmark. Measure your own workflow with matching pages and conditions.

Do I need an MCP server to capture screenshots?

No. For direct image or PDF output, ScreenshotNeo can return the capture from one HTTP request and also offers MCP tools when an agent workflow is useful.

Are these options an exhaustive list?

No. They are the practical, documented options identified in the research dossier. Package names and service terms can change, so check the primary documentation before installation.