Giving an MCP agent a browser that keeps its session

An agent that can browse but cannot stay logged in is limited to the public web. Most of what people actually want automated is behind a sign-in.

The obstacle is structural. MCP tool calls are discrete: the model calls a tool, gets a result, thinks, calls another. If each call starts a fresh browser context, the login you performed in call three is gone by call five. The agent can see a login form, fill it, and then discover on the next turn that it is logged out again.

The setup

{
  "mcpServers": {
    "anti-detect-browser": {
      "command": "npx",
      "args": ["anti-detect-browser", "--mcp"],
      "env": { "ANTI_DETECT_BROWSER_KEY": "your-api-key" }
    }
  }
}

That is the whole configuration. The agent gets launch, navigate, click, type, read and screenshot tools.

What makes it work across calls

Two things, and both are about state outliving the call.

The browser process survives. On launch the server binds a debugging port, waits for the browser to answer, and records the session so a later tool call reconnects to the same running browser rather than starting a new one. The tab you left open is the tab the next call finds.

The profile survives the process. Cookies, localStorage, IndexedDB and passkeys are written to a directory on disk. Even if the process is restarted, relaunching the same profile restores the same logged-in identity, with the same fingerprint it had before.

That second part is what makes an agent able to act on an account over days rather than minutes. The identity is a file, not a session.

Passkeys, because this is about to bite everyone

Sites are moving passwordless sign-in from optional to default. A passkey is bound to an authenticator, and a scripted browser typically has none, so it cannot enrol one and cannot use one later. The agent gets locked out of an account it registered itself.

Each AntiBrow profile carries its own virtual authenticator. A passkey enrolled during one session is captured and replayed at the next sign-in, on by default for every new profile. It is one of the few places where the automation story and the fingerprint story are the same story.

Give each agent its own identity

If you run several agents, give each its own profile. They get separate cookies, separate storage, separate fingerprints, and separate passkeys. Bind a different proxy per profile and timezone, locale and geolocation follow the exit IP automatically, so the agent in Frankfurt does not report a New York clock.

How many run at once is what a paid plan buys: one concurrent browser on the free tier, then 5, 20 or 100. The number of profiles is never the meter.

Where this goes wrong

Say the parts that are not marketing.

• A confused agent is still confused. A real browser makes the model's mistakes real too. Watch a session before trusting it with anything that spends money. Live View exists for exactly this and it is not decoration.
• Context is finite. Feeding whole pages back to a model burns context fast. Prefer targeted reads over dumping the DOM.
• Detection still depends on things a browser does not control. Proxy quality, click cadence, and the history of the account you brought. A clean fingerprint on a burnt IP behaving like a robot still gets flagged.
• Credentials are real credentials. An agent driving a logged-in browser can do anything that account can do. Scope it accordingly.

Try it for nothing

The free tier is unlimited local profiles with one concurrent browser, no card. Point the agent at a site you already have an account on and see whether it is still logged in three tool calls later.

Full setup or SDK reference.