What is a browser MCP server? Types, risks and how to choose one

A browser MCP server is a small program that lets an LLM client, such as Claude Code, Claude Desktop, Codex or Cursor, use a web browser through the Model Context Protocol. The client sees a list of tools like browser_navigate, browser_snapshot and browser_click; the server turns each call into a real action in a real browser and sends back what happened. The choice between servers mostly comes down to whose browser is driven, which profile it uses, and how much of the page the model is shown.

We make Kitsuvo, a desktop browser with an MCP server built in, so we are one of the options below. We have tried to describe the others by what their own documentation says, with links.

What does MCP add to a browser?

MCP is an open protocol for connecting AI clients to tools. Without it, each client would need its own plugin for each browser. With it, a client that speaks MCP can start a local server (usually as a command it runs over standard input and output) and call whatever tools that server lists. Claude Desktop, for example, reads local servers from a JSON file and starts them when it launches, as described in the MCP guide to local servers.

For a browser, the tools usually fall into four groups:

• Navigation: open an address, go back and forward, manage tabs.
• Observation: read the page as an accessibility tree (a text outline of headings, links, buttons and fields), as plain text, or as a screenshot.
• Action: click, type, select, hover and press keys, usually by pointing at an element reference from the last snapshot.
• Extras: JavaScript evaluation, network and console logs, performance traces, resizing, or, in Kitsuvo's case, a report on how the page was built.

What kinds of browser MCP server are there?

There are five broad designs. Each makes a different trade between control, realism and risk.

Type	Example	Browser it drives	Profile	Good for
Scripted automation	Playwright MCP	A browser Playwright launches (Chrome, Firefox, WebKit or Edge)	Persistent by default; --isolated for a throwaway one	Testing, cross-browser checks, Linux and CI
Developer tools	Chrome DevTools MCP	Chrome	Configurable	Debugging, network and performance traces
Extension bridge	Browser MCP, Playwright's --extension mode	Your everyday Chrome	Your own, signed in	Tasks on sites where you are already logged in
Vendor agent in your browser	Claude in Chrome	Your Chrome	Your own	Working alongside you in a side panel
Desktop browser with MCP built in	Kitsuvo	Kitsuvo (WKWebView on Mac, WebView2 on Windows)	Your normal profile by default on Mac 0.2.14; a separate one with --separate-profile	Watching an agent work in a real window, with page evidence

Hosted cloud browsers are a sixth option: the browser runs on someone else's servers and the MCP server talks to it over the network. They suit scale and scraping; the trade-off is that every page you visit goes through a third party.

Snapshots or screenshots: how does the model see the page?

Most modern servers send the model an accessibility snapshot rather than a picture. Playwright MCP's README says it "uses Playwright's accessibility tree, not pixel-based input", and that you can't act on a screenshot: you act on snapshot references. Snapshots are cheaper in tokens, work with text-only models and make clicks precise, because the model names an element instead of guessing coordinates.

Screenshots still matter for layout questions, images and canvas-heavy pages. Check which kind of capture a server supports on your platform before you rely on it. Kitsuvo, for example, takes viewport screenshots on Mac and Windows, but full-page capture is Windows-only, and its browser_status tool reports what your build supports.

Whose cookies does the agent get?

This is the question that matters most and gets asked least. An MCP server that drives your everyday browser profile hands the model everything that profile can reach: your email, your bank's open session, your company's admin pages. That is the point of extension bridges, and it is also the risk.

• Your own profile is convenient for sites you are signed in to. It is also where a confused or manipulated agent can do the most damage.
• A persistent separate profile keeps the agent's logins apart from yours and survives restarts, so you can sign the agent in to the few sites it needs.
• An isolated, throwaway profile forgets everything when it closes. Good for testing and public pages.

Kitsuvo lets you choose. On Mac 0.2.14, its MCP server (kitsuvo mcp) uses your normal browser profile by default, so the agent can use sites you are signed in to; add --separate-profile to give it a separate persistent profile instead. In either mode it refuses to read or script sign-in pages, and it never types into password fields unless you start it with --allow-sensitive. An Agent mode bar across the window shows that automation is on, with a Stop button.

What are the risks of letting an LLM drive a browser?

1. Prompt injection. Pages can contain text written for the model, not for you, telling it to do something else. Claude Code's own MCP documentation warns that "servers that fetch external content can expose you to prompt injection risk" (Claude Code MCP docs). Treat every page as untrusted input.
2. Data going to the client. Whatever a tool returns, page text, screenshots, form contents, goes to your AI client and its provider. Chrome DevTools MCP's README says plainly to avoid sharing sensitive information you don't want shared with MCP clients.
3. Irreversible actions. Purchases, deletions and sent messages can't be taken back. Keep approvals on for actions in your client, and say "do not submit anything" in prompts while testing.
4. Telemetry you didn't expect. Read each server's README for usage statistics and how to turn them off. Chrome DevTools MCP, for example, collects usage statistics by default and documents a --no-usage-statistics flag.

How do you choose one?

• You write tests or need Linux: Playwright MCP. It is cross-platform, cross-browser and scriptable. See our Playwright MCP comparison for when another option fits better.
• You debug performance or network issues: Chrome DevTools MCP, which exposes traces and request details.
• You need the agent inside sites you are already signed in to: an extension bridge or Claude in Chrome, with your eyes on it.
• You want to watch the agent in a real window on Mac or Windows, choose whether it gets your logins, and know how each page was built: a desktop browser with MCP built in, like Kitsuvo.

What does Kitsuvo's MCP server do differently?

Kitsuvo's tools follow Playwright MCP's naming, so prompts carry over: browser_snapshot returns an accessibility tree with element refs, and actions wait for any navigation they start and return the new snapshot. On top of that, kitsuvo_report returns Kitsuvo's local read of the page: a 0 to 100 score for how likely it was built with an AI app builder, the builder when a fingerprint names one, slop and impersonation findings, and the evidence for each. On a search results page it lists the results Kitsuvo hid or labelled. Scores are estimates, not proof, and the report says why when it has none.

That matters for agent work because an LLM researching the web picks up whatever it reads. Knowing that a source is a likely AI-built template, or a look-alike sign-in page, is useful context before the model quotes it. For the setup steps, read how to let Claude browse the web, or go straight to Connect your LLM.

Kitsuvo runs on macOS and Windows only. If your agent runs on a Linux server, use Playwright MCP or a cloud browser instead.