Choosing an MCP Server for Browser Automation: What Matters Behind the Tools

The short answer: most browser MCP servers expose much the same tools (navigate, click, type, read the page, screenshot), so compare the browser behind the tools. For anything past public pages, you want real headful Chrome on a residential connection, logins that survive between runs, and a way for a person to take over. For local experiments, a free local server such as Playwright's is the right choice. For agents that run without you, use a hosted one. Ours is at https://scrappy.gg/api/mcp, in the official MCP Registry as gg.scrappy/cloud-browser, with 62 browser tools.

Local or hosted

A local browser MCP server starts a browser on the machine where your MCP client runs.

• Free, quick to set up, and good for development and one-off tasks.
• It browses from your IP, so it can be signed in as you, which is sometimes exactly what you want.
• It stops when your laptop sleeps, cannot be shared with a teammate's agent, and moves to a datacenter IP once you deploy it to a server.

A hosted one runs the browser in the cloud and gives your agent the tools over HTTP.

• The agent can run anywhere, and the browser outlives the client.
• Sessions can be watched, recorded and handed to a person.
• You pay for it, and you have to trust the vendor with whatever the browser signs in to.

If you are unsure, start local. You will know when you have outgrown it: the first time a site blocks the server-side run that worked on your laptop.

Five things to check about the browser

1. Is it headful?

Headless Chrome differs from desktop Chrome in ways that no amount of fingerprint patching fully hides, and bot checks look for exactly those differences. We run headful Chrome on every session for that reason. Headless Chrome is why you're blocked has the details.

2. Which IP does it browse from?

Datacenter IP ranges are public and are the first thing a bot check scores. Ask whether the residential connection is included or billed per gigabyte, and whether a saved login always leaves from the same address. A login replayed from a new IP every run is how saved sessions get signed out. A hosted browser with the residential proxy included covers this.

3. Can it keep a login?

An agent that has to sign in on every run will meet two-factor prompts, CAPTCHAs and lockouts. Look for a way to capture a signed-in session once and start later sessions from it. Then check what happens when the site signs you out: does the server overwrite the good login with the signed-out one, and does anything tell you? We refuse to save a sign-in page over a working login, and we send a BROWSER_LOGIN_LOST webhook so you hear about it the day it happens rather than a week later.

4. Can a person take over?

Some steps only a person can do: a texted code, a press-and-hold challenge, a judgement call. The useful version of takeover is a link to the very session the agent is driving, that works on a phone, because the person with the code is rarely at a desk. Hand a stuck browser agent to a human shows the pattern.

5. Does it tell the agent what actually happened?

This is the one nobody lists, and it is where agents waste the most time. When a tab stops responding, a good server says why. Our first guess for a hung tab was a crashed renderer. It was a native confirm() dialog the page had opened, which blocks every command until someone answers it. A client that attaches after the dialog opened cannot even see it. Now a failure says when a dialog is open and how to answer it. The dialog that looks like a frozen tab tells that story. Other examples: a navigation that returns before the page's scripts have run, and a CAPTCHA script that loads on a page that shows no challenge. Read the error messages before you choose.

Setting ours up

In Claude Code:

claude mcp add --transport http scrappy https://scrappy.gg/api/mcp \
  --header "Authorization: Bearer sk_..."

For clients that take a JSON config:

{
  "mcpServers": {
    "scrappy": {
      "type": "http",
      "url": "https://scrappy.gg/api/mcp",
      "headers": { "Authorization": "Bearer sk_..." }
    }
  }
}

Create the key under Settings → API keys with the browser:read and browser:write scopes. A new account has 100 free credits. A session costs 5 credits to start and 1 per minute, with the residential connection included. Both configurations are also in examples/mcp.

The 62 browser_* tools cover:

• Sessions: create (optionally from a saved login), get, list, release, sleep and wake, keepalive
• Reading: browser_read_page (the accessibility tree, with refs to click), browser_find, browser_screenshot, DOM, console and network
• Acting: click, type, press, select, check, hover, drag and drop, scroll, fill a form, paste, upload, download, and browser_batch to run several steps in one call
• Waiting: for a selector, a JavaScript condition, or network quiet
• People: a viewer link for takeover, dialog handling, CAPTCHA detection and solving
• Logins: create, capture, update and delete saved logins
• Agents: start an agent run on a session and read the playbook it records

The server is stateless over Streamable HTTP and backed by the same REST API as everything else. A session an agent starts over MCP can be watched in the dashboard, or picked up by your own code by its id.

Where the others fit

Every hosted browser vendor we compared on 1 October 2026 documents an MCP server: Browserbase, Steel, Hyperbrowser, Anchor and Browserless. Their tools are similar. The browsers behind them differ on the points above, and the comparison table lists which we found documented. If you only need public pages and want the cheapest browser hour, some of them will cost you less than we do. Our Browserbase alternatives post is honest about where.

Next: the MCP integration page and the MCP guide.