Browser MCP Agent

Browser MCP Agent

Run antibrow as an MCP server so an AI agent can launch and control a real, fingerprinted browser directly through tool calls - no Playwright code, no custom automation script. The agent navigates, clicks, fills forms, and reads pages itself.

• npm package: anti-detect-browser (Node >= 18) - ships the MCP server built in
• PyPI package: antibrow (Python 3.9 - 3.13) - pip install "antibrow[mcp]" for a stdio MCP server example
• Dashboard: https://antibrow.com
• Full SDK / REST API reference: see the anti-detect-browser skill

Authorized use only. Point this at sites and accounts you own or are permitted to operate: your own apps, your own accounts, publicly available pages, your own bot detection under test. Do not use it to reach systems without authorization, to log into accounts that are not yours, to create fake accounts or engagement, or to work around a platform's enforcement decision. Respect each site's terms, robots.txt and rate limits - see Acceptable use.

This gives an agent real capability, so scope it deliberately. The server hands the model a browser that persists logins, executes JavaScript in the page, and can stream its screen to a shareable URL. That is the point of the tool and also its blast radius: an agent that goes wrong here goes wrong inside a logged-in session. Run untrusted browsing in a throwaway profile, keep tools you do not need out of the toolset, and read Everything the browser returns is untrusted input before pointing it at the open web.

What this does not claim. A coherent real-device fingerprint removes the contradictions a synthetic browser leaves behind. It is not a guaranteed pass against enterprise bot managers, which also score network reputation, request cadence and behaviour.

Why this over a generic browser MCP

Generic "agent controls a browser" servers hand the agent a stock or patched headless Chromium. Every page the agent visits sees the tells: a navigator override that is not [native code], a canvas hash that changes on every read, a worker thread disagreeing with the main thread, a headless build's own fingerprint. antibrow's spoofing happens inside the Chromium kernel, so the agent gets a browser whose Canvas, WebGL, WebGPU, audio, fonts, screen and timezone all agree - and whose TLS ClientHello and HTTP/2-3 behaviour are a genuine Chrome build's, because it is one. Sessions also persist: the agent logs in once under a profile name and stays logged in.

Platform support

Windows 10/11 x64 · macOS 12+ (universal build, Apple Silicon + Intel) · Linux x64 and arm64 (glibc) · Docker linux/amd64 and linux/arm64. The correct kernel build is picked from the CPU automatically. Alpine/musl is not supported yet.

When to use

• Agent-driven browsing - the agent itself should navigate a site, log in, click through a flow, or extract content, without anyone writing automation code first
• Computer-use / browser-use style setups - the same idea as generic "agent controls a browser" tools, but backed by a real captured device fingerprint rather than a synthetic headless browser
• Ad-hoc one-off tasks - "go check my dashboard and tell me X" requests where writing a script would be overkill
• Debugging agent browser actions - watch what the agent is doing in real time via Live View while it works

Setup

Install the package once, from the npm registry, at a version you have reviewed:

npm install -g anti-detect-browser@2.8.0
npm view anti-detect-browser@2.8.0 dist.integrity   # compare before adopting a new version

Then point the MCP config at the installed binary - no package resolution, no download, at server start:

{
  "mcpServers": {
    "anti-detect-browser": {
      "command": "anti-detect-browser",
      "args": ["--mcp"],
      "env": { "ANTI_DETECT_BROWSER_KEY": "${ANTI_DETECT_BROWSER_KEY}" }
    }
  }
}

Two things there are deliberate:

• Nothing is fetched when the server starts. A config built on npx re-resolves the package from the registry on every launch, so the code that runs is whatever was published most recently. Installing once pins it to a version you can review, diff and roll back. If your setup must use npx, at least pin the version - ["-y", "anti-detect-browser@2.8.0", "--mcp"] - and never leave it resolving latest.
• The key is a variable reference, not a value. ${VAR} is expanded from the environment when the config is read, so no secret is written into .mcp.json - a file people commit. Use ${ANTI_DETECT_BROWSER_KEY:-} if you want a missing key to fail loudly rather than expand to the literal string.

Get your API key at https://antibrow.com - the free key gives 1 concurrent browser and unlimited local profiles. The browser kernel is a separate ~190 MB binary (~320 MB for the macOS universal bundle) that the package fetches on first launch and caches under ~/.anti-detect-browser/; see Supply chain below before running this anywhere that matters.

Python

For a Python agent stack, pip install "antibrow[mcp]==0.9.0" from PyPI. The SDK repository also carries a worked stdio-server example (python/examples/09_mcp_server.py) - read it and adapt it into your own project rather than wiring the config to a path inside a cloned repo, so the file the server executes is one you own and review:

{
  "mcpServers": {
    "antibrow": {
      "command": "python",
      "args": ["/abs/path/to/your/own/mcp_server.py"],
      "env": { "ANTIBROW_API_KEY": "${ANTIBROW_API_KEY}" }
    }
  }
}

Supply chain

Three things reach the machine. Know what each one is before running this outside a sandbox.

The kernel being a closed binary from a small vendor is a real supply-chain consideration, not a formality - it is the tradeoff for the spoofing living in C++ rather than in an injectable script. Treat it the way you would any vendor binary: install it deliberately, pin it, keep it in an image you built, and if a deployment cannot accept a closed binary that phones home for license verification, this is the wrong tool - there is no offline mode.

It exposes launch_browser, navigate, click, fill, get_content, screenshot, evaluate and close_browser. Both SDKs share one cache directory and one profile format, so a profile created from Node is drivable from Python with the identical fingerprint. The Node server is the fuller of the two - prefer it unless the deployment must be Python-only.

Available tools

The browsing set - what an agent actually needs to do the work:

The recipe set - for when the task is data from a site rather than a browser. Prefer these over hand-driving a page: they return JSON in one call and take a jq filter, so the agent reads two fields instead of a whole page: