Browser MCP: Connect Claude & Cursor to a Real Browser

What is a Browser MCP?

"Browser MCP" (or WebMCP) is emerging shorthand for a Model Context Protocol server that exposes a real web browser as tools to an AI model. Instead of giving Claude or Cursor a brittle HTTP scraper, you give them a persistent, controllable browser running in the cloud, reachable through MCP.

Practically, a browser MCP is an MCP server that offers tools like:

• browser.open(url) – launch a page in a headless or visible browser
• browser.click(selector) – click a button or link
• browser.type(selector, text) – fill forms
• browser.screenshot() – capture page state
• browser.evaluate(js) – run JavaScript in the page

Claude Code or Cursor call these tools through MCP; the MCP server translates tool calls into real browser actions via Playwright, Puppeteer, or similar. The main point: the model stops hallucinating what the DOM might look like and starts reacting to the actual, rendered page.

MCP is the cable. A2A is the network. Don't confuse the two.

MCP vs A2A: Two Ways to Wire a Real Browser

There are two patterns you should know:

• MCP (Model Context Protocol) – standard for plugging tools and data sources into models like Claude, mostly for IDEs and chat UIs.
• A2A (Agent-to-Agent) – HTTP-based control plane where one agent (e.g., Claude via a small MCP shim) calls a dedicated browser automation agent.

With a browser MCP you can either:

• Run the browser engine inside your MCP server (good for local experiments, bad for scale), or
• Use MCP as a thin adapter to an external browser automation service via an A2A endpoint.

Human Browser exposes a dedicated A2A endpoint at https://agent.humanbrowser.cloud/a2a. Your MCP server can forward tool calls to this agent, which runs the real browser, manages sessions, and returns structured results. That keeps your MCP process light while still giving Claude or Cursor a full-featured cloud browser.

Why Browser MCP Beats Raw HTTP Scraping

Most devs start with fetch tools: they work for static HTML but fall apart on modern web apps. A browser MCP solves several pain points:

• JavaScript-heavy pages: React, Vue, Next.js, and friends won’t render correctly via plain HTTP requests. A real browser executes the JS and exposes the final DOM.
• Complex auth: OAuth flows, SSO, and multi-step logins are much simpler to automate with real browser interactions and cookies, instead of manually reproducing every request header.
• Anti-bot defenses: Many sites use CAPTCHAs, browser fingerprinting, and behavior checks that straightforward scrapers fail. A good browser MCP, backed by a serious browser agent, can solve CAPTCHAs and behave like a real user.
• Stateful navigation: Multi-step workflows (search → filter → click → export) map naturally to browser sessions with history, cookies, and local storage.

This matters for AI coding assistants. If you want Claude or Cursor to automate a dashboard, scrape internal tools, or test an SPA end to end, you want them talking to something that looks like a real user browser, not just an HTTP client.

How Claude Code Uses a Browser MCP

Claude Code can talk to any MCP server that implements the protocol and exposes tools in a manifest. A browser MCP is just another tool provider, but its tools are stateful and typically tied to a session id.

The basic flow:

1. You configure Claude Code to load your MCP server (via mcp.config.json or GUI).
2. The MCP advertises tools like open_page, click, and extract_text.
3. Claude sees the tool descriptions and uses them as needed when you prompt it (e.g., “log into this internal tool and download today’s CSV”).
4. The MCP server talks to the real browser (either bundled or via A2A) and returns results.

The same pattern works in Cursor. Cursor has in-IDE support for MCP, so you can mount a browser MCP and then write prompts like: “Use the browser tools to open <URL>, log in, and screenshot the dashboard; then write Playwright tests that cover this flow.”

Architecture: MCP-Embedded vs A2A-Backed Browser

You have two main design options for implementing a browser MCP for Claude or Cursor.

For anything beyond trivial local experiments, an A2A-backed browser MCP is usually the right call. It lets you keep the MCP implementation thin and stateless while delegating browsers, proxies, geolocation, and CAPTCHAs to a dedicated system.

Giving Claude & Cursor a Real Cloud Browser via A2A

Human Browser provides that external agent, with:

• Real Chromium-based browsers in the cloud.
• 75 residential countries for IP geolocation.
• Automatic CAPTCHA solving when triggered.
• Persistent sessions so stateful flows survive multiple tool calls.

You interact with it via the A2A endpoint: https://agent.humanbrowser.cloud/a2a. Your MCP server just needs to translate a model tool call into an A2A JSON request, then relay the response back to Claude or Cursor.

If you want a broader view of how this fits into agent architectures, see the cluster article on AI agent browser automation, which walks through the agent patterns you can reuse on top of MCP.

Step-by-Step: Minimal Browser MCP Server (Node.js)

Below is a highly simplified MCP-style server that exposes two tools backed by the Human Browser A2A endpoint: open_page and get_text. In a real implementation you would conform exactly to the MCP spec for transport and tool schema, but the core wiring remains the same.

import express from "express";
import fetch from "node-fetch";

// Environment
const PORT = process.env.PORT || 4000;
const HUMAN_BROWSER_A2A = "https://agent.humanbrowser.cloud/a2a";
const HUMAN_BROWSER_API_KEY = process.env.HUMAN_BROWSER_API_KEY;

if (!HUMAN_BROWSER_API_KEY) {
  throw new Error("HUMAN_BROWSER_API_KEY is required");
}

// Very minimal MCP-like shape
// POST /tools/invoke { name: string, arguments: object }
const app = express();
app.use(express.json());

// Keep track of a session per conversation or user
// In real MCP you would attach this to the model conversation id.
const sessionStore = new Map();

async function callHumanBrowserAgent(sessionId, task) {
  const body = {
    sessionId,
    task, // free-form DSL understood by the browser agent
  };

  const res = await fetch(HUMAN_BROWSER_A2A, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "Authorization": `Bearer ${HUMAN_BROWSER_API_KEY}`,
    },
    body: JSON.stringify(body),
  });

  if (!res.ok) {
    const text = await res.text();
    throw new Error(`Human Browser error: ${res.status} ${text}`);
  }

  return res.json();
}

app.post("/tools/invoke", async (req, res) => {
  const { name, arguments: args, conversationId } = req.body;
  const sessionId = sessionStore.get(conversationId) || null;

  try {
    let agentTask;

    if (name === "open_page") {
      const { url } = args;
      agentTask = {
        steps: [
          { action: "open", url },
        ],
      };
    } else if (name === "get_text") {
      const { selector } = args;
      agentTask = {
        steps: [
          { action: "extractText", selector },
        ],
      };
    } else {
      return res.status(400).json({ error: "Unknown tool" });
    }

    const agentResponse = await callHumanBrowserAgent(sessionId, agentTask);

    // Persist session id returned by Human Browser
    if (agentResponse.sessionId && conversationId) {
      sessionStore.set(conversationId, agentResponse.sessionId);
    }

    return res.json({
      content: agentResponse.result,
      sessionId: agentResponse.sessionId,
    });
  } catch (err) {
    console.error(err);
    return res.status(500).json({ error: String(err.message || err) });
  }
});

app.listen(PORT, () => {
  console.log(`Browser MCP adapter listening on :${PORT}`);
});

This is not a full MCP server; it is the core of what your browser MCP does:

• Accepts a tool invocation with a tool name and args.
• Translates it into an A2A task for the browser agent.
• Maintains a sessionId so multiple calls share the same browser state.

From here, you’d flesh out:

• The official MCP protocol transport (usually stdio or WebSocket with JSON-RPC).
• Tool manifests that describe open_page, get_text, click, type, etc.
• More robust session management (expiry, cleanup).

Configuring Claude Code / Cursor to Use Your MCP

Once you have a browser MCP server running, you wire it into Claude Code or Cursor.

Claude Code

Claude Code supports MCP via configuration. You define your MCP servers with their transport (e.g., stdio or HTTP bridge) and tool configuration. Each workspace can load one or more MCP servers, so you can combine your browser MCP with other data sources (code search, docs, internal APIs).

When you open a Claude session in your editor, the model will discover the browser tools, and you can explicitly ask it to use them: “Use the browser tools to log in to our staging app, walk through the onboarding flow, and summarize any client-side errors in the console.”

Cursor

Cursor similarly lets you attach MCP providers that surface tools to the model. With a browser MCP configured, Cursor can:

• Inspect DOM structure live while generating test code.
• Re-run flows automatically to verify edits.
• Help you migrate flows by inspecting old and new versions of an app in real browsers.

The configuration steps depend on Cursor’s MCP UI at the time you read this, but the pattern is the same: point Cursor at your MCP endpoint, enable the tools, and then write prompts that invite the model to use those tools.

Residential IPs and Geo-Sensitive Flows

Real browsers are only half the story for serious automation. Many sites change behavior by country or aggressively block datacenter IPs. A browser MCP backed by residential proxies solves this without forcing you to own your own proxy fleet.

Human Browser offers residential IPs in 75 countries. From your MCP adapter you specify the desired location (e.g., country code or region) when creating or resuming a session. That unlocks use cases like:

• Testing localized UIs and flows that only appear in certain regions.
• Scraping geo-restricted price or inventory data.
• Debugging issues that only reproduce for users in specific countries.

Because the A2A browser agent handles the proxy routing, your MCP code remains simple: it asks for “US” or “DE” and lets the agent figure out exit IPs and rotations.

Pricing Model for a Browser MCP Backed by Human Browser

When you wire your browser MCP to Human Browser’s A2A endpoint, you keep a clear mental model of costs. The service is strictly pay-as-you-go:

• Browser time: $0.10 per hour of active browser use.
• Residential proxy data: $4 per GB when you need residential IPs.
• CAPTCHAs: $0.005 per CAPTCHA solved.
• AI orchestration: $0.02 per agent step, model included, when you use the built-in agent logic instead of writing your own.

There is no subscription, and unused balance never expires. You can try it for $1 (about 4 typical tasks), so you can benchmark how your browser MCP behaves under real usage before committing. Because you pay for actual agent steps, browser time and data, it fits nicely with MCP’s tool-call model: your cost is proportional to how often Claude or Cursor actually drive the browser.

You can always check the current details and quick-start path from Human Browser — pay as you go, no subscription, and if you want a one-command setup, there’s an install flow described at /install.

Operational Considerations

When you move from “demo” to “production-ish” with a browser MCP, you need to think like an SRE for AI tools.

Session Lifecycle

Models don’t understand cost, but your wallet does. Don’t keep sessions alive forever:

• Track last-activity timestamps per session.
• Auto-close browser sessions after a period of inactivity.
• Expose a close_session tool that models can invoke when they’re done, and occasionally nudge them in prompts to call it after long workflows.

Error Handling

Real websites are messy. Build resilience into your browser MCP:

• Retry transient issues (navigation timeouts, 5xx pages) with backoff.
• Surface structured errors to the model (“selector not found”, “login failed”) instead of generic stack traces; models handle structured feedback much better.
• Limit how many steps a single tool call can perform so the model doesn’t accidentally orchestrate a 10-minute click storm in one go.

Security and Data Boundaries

Because your browser MCP can see what the browser sees, treat it like you would any automation hitting internal or customer systems:

• Scope API keys and session tokens tightly.
• Run separate MCP instances or configurations for staging vs production.
• Log enough to debug but avoid storing full page contents or PII unless you absolutely need it.

Extending Beyond Basic Navigation

Once you have the basic browser MCP wired up, you can enrich the toolset to make Claude or Cursor more capable and less brittle.

Higher-Level Tools

Instead of exposing only atomic actions like click and type, provide composable, semantic tools:

• login_to_app(name) – encapsulate your login flow.
• download_report(kind, date) – implement the full navigation and export logic.
• capture_console_logs() – fetch console output to debug client-side errors.

Inside your MCP, these high-level tools still call the A2A browser agent, but they hide implementation details from the model. This produces more reliable behavior and simpler prompts.

Testing and CI

A browser MCP is also useful for non-interactive automation. Your CI pipeline can spawn a small MCP session that:

• Runs smoke tests through the same flows users follow.
• Captures screenshots for visual regression checks.
• Uses Claude or another model to summarize failures in human-readable form.

Because the plumbing is the same as what you use for in-IDE Claude or Cursor sessions, you avoid maintaining parallel stacks for “developer assistance” and “automated testing”.

Frequently asked questions

Related guides

• AI Agent Browser Automation (2026) — Pillar Guide
• Browserbase Alternative for AI Agents (2026) — Cloud Browser
• Best Residential Proxy for Web Scraping 2026 — Proxies