What is an MCP browser? Giving Claude, Cursor and other agents a real browser

An MCP browser is a web browser that an AI agent controls through the Model Context Protocol. The agent does not see your screen or move your mouse: it calls tools such as "open this address", "read the page", "click that button" and "take a screenshot", and a browser MCP server carries each one out in a real browser and sends back the result.

This post explains MCP in plain terms, what a browser MCP server exposes, the difference between a local and a remote server, how a plain browser MCP differs from one built on separate browser profiles, and how to set one up in Claude Code, Claude Desktop and Cursor.

MCP in one paragraph

The Model Context Protocol is an open standard for connecting AI apps to outside tools. A tool provider runs an MCP server that lists its tools, each with a name, a description and a schema for its inputs. An MCP client, such as Claude Code, Claude Desktop or Cursor, reads that list and lets the model call the tools while it works. Because every client speaks the same protocol, one server works in many apps, and one app can use many servers.

What a browser MCP server exposes

Almost every browser MCP server offers the same core loop:

1. Navigate: open an address in a tab and wait for it to load.
2. Snapshot: read the page in a form the model can use.
3. Act: click, type, select or scroll on an element.
4. Wait: wait for some text to appear, or for the address to change.
5. Screenshot: a picture, for layout, images or anything the text misses.

The snapshot is the part that decides how well an agent copes. Raw HTML is long and full of markup the model does not need. A screenshot alone makes the model guess where to click. Most servers therefore read the page's accessibility tree, the structure a screen reader uses: roles, names, values and states, one element per line. Each interactive element gets a short reference, and the agent acts on that reference rather than on a fragile CSS selector.

In Browz, browz_snapshot returns that outline sized to a token budget, with refs like e12, and browz_act clicks, fills, types, selects or scrolls by ref with real input events, paced like a person. Neither runs a script in the page. The full list of tools is published as the MCP tool list.

Local or remote: stdio and HTTP

An MCP server reaches its client in one of two ways.

A local server is the simplest choice when the agent runs on your own computer. A remote one is for agents that live in the cloud and still need a browser somewhere.

Browz offers both. The local server ships inside the app and speaks stdio, or Streamable HTTP on your own computer behind a bearer file. The hosted server at mcp.gobrowz.com, a free public beta, relays a cloud agent's calls to the Browz app on your computer; the hosted MCP post covers it in detail.

A plain browser MCP vs a profile-based one

The most common way to give an agent a browser is a plain browser MCP: an open-source server that starts a standard browser, often a fresh, isolated context for each run. It works well on sites that rarely challenge automation. Three things show up once agents do real work:

• Every run is a stranger. A fresh context has no cookies, so every task starts signed out, and every context reports the same machine.
• Sessions do not carry over. The agent cannot return tomorrow to the account it used today without you signing it in again.
• It is your network and your device. Every task leaves from the same IP address with the same browser fingerprint (the set of values a site reads to recognise a browser; what browser fingerprinting is explains them).

A profile-based MCP browser starts each task in a browser profile: a complete, separate browser with its own cookies, storage, fingerprint and proxy. In Browz an agent can open a throwaway session for a one-off task (browz_session_open, wiped by browz_session_close), or a persistent one that returns to the same identity, with its cookies and proxy, every time. Parallel sessions never share storage. And driving a profile through MCP does not change the fingerprint it presents, because the fingerprint is set in the browser engine, not by a script injected into the page (engine-level vs injected scripts).

Set it up in Claude Code, Claude Desktop and Cursor

Install Browz from the download page and open it. The local server reads the app's own credentials, so there is no token to paste. These snippets use the macOS path to the server inside the app; the Windows and Linux paths are in the setup docs.

Claude Code

With Node.js installed, claude mcp add browz -- npx -y @browz/mcp does the same.

Claude Desktop

Double-click the Browz extension (browz.mcpb), or add this to claude_desktop_config.json (Settings, Developer, Edit Config) and restart Claude:

Cursor

Add the same mcpServers entry to ~/.cursor/mcp.json for every project, or .cursor/mcp.json for one. Then check that browz is listed and enabled under Settings, MCP. npx -y @browz/mcp setup cursor --write writes the entry for you and keeps your other servers.

Check it works

Ask the agent: "Using Browz: create a new profile called agent-check, start it, open https://example.com, tell me the page title, take a screenshot, then stop the session and delete the profile." It should answer "Example Domain" and leave no profile behind. Every other client, from VS Code to LangChain, is in the integration guides.

What to check before you choose one

An MCP browser is a powerful tool to hand to a model, so look past the tool list:

• Isolation. Does each task get its own browser, or does the agent share yours and every session in it?
• Persistence. Can a task return to a signed-in identity, and can a throwaway one be wiped completely?
• A key per agent. Can you give each agent its own key, limited to chosen profiles and sites, instead of a master token?
• Secrets. When the agent meets a login, does the password end up in the prompt?
• A person for the hard steps. Can the agent hand a sign-in, 2FA code or CAPTCHA to you and carry on afterwards?
• A record. Is every call logged, and can you stop every agent at once?
• Measured results. Has anyone published how often agents finish real tasks through it, with a harness you can rerun?

How Browz answers those checks

You decide exactly what each agent may do: its own key, its own profiles, only the sites you allow, sign-ins it can use on your computer but never read, and a person for the login.

Each agent key is limited to the profiles, sites and scopes you choose, capped at 60 calls a minute and 10,000 a day by default, and revocable; browz agent-token stop-all suspends every key at once, and every call is logged on your computer for 90 days without page content (agent keys). Stored sign-ins let the agent ask Browz to fill a password or authenticator code, and the agent gets back only "filled". When a page needs a person, browz_request_human brings the window to you.

We also measured it. On 2 November 2026 the same agent (Claude Sonnet) did the same 50 public web tasks through the Browz MCP server and through a plain browser MCP. It completed 46 of 50 through Browz and 38 of 50 through the plain browser; on sites that challenge automated browsers, 14 of 18 against 9 of 18. The method and the open harness are on the agent benchmark page.

The local server is on every plan, Free included, and is not metered. Free covers 5 profiles; paid plans start at $4.99 a month, with a 14-day refund on the first payment.

Frequently asked questions