browser-rs-mcp: Share Chrome with AI Agents

Overview

browser-rs-mcp exposes a real Chrome or Chromium browser to MCP-compatible AI agents through browser automation tools. Agents can share one browser process and persistent profile while working in separate owner-scoped tab groups, reducing the need to launch a separate browser for each agent.

It is aimed at developers and teams building agent workflows that need logged-in browsing, scraping, or QA. Its default headful setup avoids injecting page-level patches, but the project explicitly does not guarantee that sites will accept or evade detection of automation.

Key Features

• Provides browser navigation, snapshots, interaction, screenshots, and page inspection through MCP tools.
• Lets multiple agents use one Chrome process and persistent profile with owner-scoped tabs.
• Uses raw Chrome DevTools Protocol over a multiplexed WebSocket and ships as a Rust server without a Node.js runtime.
• Supports stdio and HTTP transports for MCP clients.
• Includes optional managed hosting controls such as per-owner capability tokens, a tool allowlist, and a secret broker.
• Supports iframe interaction, browser storage and cookies, network tools, and opt-in WebAuthn handling.
• Includes detector runners for regression testing, without promising bot-detection bypass.

Use Cases

• Agent platform developers can let several workers browse with one shared login while keeping their tabs separate.
• Researchers can run parallel web research or scraping tasks using a persistent Chrome profile.
• QA teams can automate browser checks through MCP-compatible clients without building Playwright or Puppeteer glue code.
• Self-hosters can provide browser access to multiple tenants when they can configure the managed-mode authentication and isolation requirements.

Getting Started

Install the server and connect it to an MCP client:

curl -fsSL https://raw.githubusercontent.com/maestrojeong/browser-rs-mcp/main/install.sh | sh
browser-rs

A locally installed Google Chrome or Chromium is required. See the repository README for client configuration, HTTP setup, and installation details.

Alternatives

• brightdata-mcp: Bright Data MCP provides managed remote browser automation and web data services, rather than controlling separate tabs in a shared local Chrome profile.
• BrowserOS: BrowserOS is a Chromium-based desktop browser for agent automation and browsing, rather than a standalone Rust MCP server for shared-profile tab control.
• CloakBrowser: CloakBrowser offers Playwright- and Puppeteer-compatible automation on a fingerprint-modified Chromium build, rather than MCP-based control of shared Chrome tabs.

Considerations

• Requires locally installed Chrome or Chromium. The README lists prebuilt installers for macOS arm64, Linux x64, and Windows x64; its release workflow describes published binaries for macOS arm64 and Linux x64.
• Shared tabs are scoped by owner, but owner isolation alone is not an authentication boundary. Keep unauthenticated HTTP endpoints on loopback or place them behind a trusted authenticated proxy.
• Managed mode requires host configuration and is intended for multi-tenant deployments. Secret values pass through the server's memory when used, even with the optional broker.
• Stealth-oriented defaults reduce some common automation signals but do not guarantee bot-detection bypass.
• Features and behavior depend on Chrome and CDP. The README calls out some limitations, including incomplete keyboard-side native-modal checks for out-of-process iframes.