What a stealth browser MCP server has to provide, and why an agent's browser gets spotted

You give an agent a browser through MCP, it handles a public page fine, and then the first site that matters answers with a challenge page or a quiet logout. The model did nothing unusual. The browser told the site what it was before the model clicked anything.

Wiring a browser into an MCP client and keeping a login across tool calls is covered in MCP browser automation. This post asks which signals identify an agent's browser, and what a "stealth browser MCP" setup has to change.

Four things that identify an agent's browser

1. The fingerprint is the host's, or a server's. A stock MCP browser server launches a stock Chromium or Chrome. On your laptop it honestly reports your hardware. Moved to a cloud VM or a container, the same server reports a software renderer (SwiftShader or llvmpipe in the WebGL renderer string), a Linux font set, and a screen size no consumer laptop has. Every agent on that host reports the same values, so ten "different users" share one device.

2. Headless and automation tells. Server deployments often run headless because there is no display, and headless has its own signature: missing plugins, inconsistent notification permissions, a screen with no taskbar, navigator.webdriver. The headless vs headful post goes through them.

3. A fresh identity on every run. An in-memory profile per session means a browser with no cookies and no history arriving at a login page with a valid password. That is what a credential-stuffing tool looks like.

4. A datacenter exit IP. An agent on a cloud host browses from that host's range, often with a UTC clock and en-US while the account belongs to someone in Lyon. IP reputation alone can trigger a challenge before any JavaScript runs.

None of these is about the model.

What a stealth MCP browser has to change

Each fix maps to one signal above.

• Signal 1: one plausible machine per identity. GPU, fonts, screen, platform and user agent must describe a single real device, and a different one for each identity on the host. How the values are applied matters as much as which values: overrides injected as JavaScript leave traces that tools like CreepJS look for specifically.
• Signal 2: a headed or properly hidden window, not a headless build.
• Signal 3: storage that outlives the session, one profile directory per account, with the browser kept alive across tool calls. The mechanics are in the MCP automation post linked above.
• Signal 4: a proxy bound to the identity, with timezone, locale and geolocation taken from the exit IP rather than from the host.

The tool loop has a shape of its own

A clean fingerprint does not hide how an agent drives the page. MCP tools are coarse: read a snapshot, think, click a reference, read again. Seen from the page, that loop looks like this:

• Long silences, then exact actions. Several seconds of no input while the model reasons, then a click preceded by a single pointer jump. Playwright moves the pointer straight to the element in one step and clicks, without the drift and overshoot of a hand on a mouse.
• Centre hits. Clicks land on the geometric centre of the target element, time after time.
• Text that appears at once. A fill action sets the field value directly, so the page sees no keydown and keyup per character unless the tool types key by key.

No browser fixes this on its own. Some sites weight it heavily, others ignore it, so watch a session before you scale it.

How the common approaches compare

Playwright MCP (Microsoft's server, @playwright/mcp). Its README, read on 2026-10-22 at github.com/microsoft/playwright-mcp, says it runs headed by default with a persistent profile on disk, offers --isolated for an in-memory profile, --proxy-server for a proxy, --user-data-dir for a chosen profile directory, and --cdp-endpoint to attach to an already running browser. Nothing in that list changes the fingerprint away from the host's, so several agents on one server look like one device.

An antidetect browser exposed over MCP. AntiBrow runs as an MCP server with npx anti-detect-browser --mcp. The browser process survives between MCP tool calls, the fingerprint is generated once per profile and applied in the browser engine rather than by an injected script. Whether that is enough for a particular site depends on the proxy and the account, which no browser controls.

When you do not need any of this

If your agent reads public docs, tests your own staging site, or logs into tools you own, a stock Playwright MCP server on your own machine is the right answer: free, and its persistent profile already keeps logins. A stealth setup earns its keep only when the site scores the browser and you run more than one identity from one host.

Check whether your agents look like one device

Signal 1 is the one teams miss, because each agent looks fine alone. Run the same snippet in every agent profile and compare:

const gl = document.createElement('canvas').getContext('webgl')
const ext = gl && gl.getExtension('WEBGL_debug_renderer_info')
console.log(JSON.stringify({
  gpu: ext && gl.getParameter(ext.UNMASKED_RENDERER_WEBGL),
  screen: [screen.width, screen.height, devicePixelRatio],
  cores: navigator.hardwareConcurrency,
  tz: Intl.DateTimeFormat().resolvedOptions().timeZone,
  webdriver: navigator.webdriver,
}))

Across identities, gpu, screen and cores should not all be identical, and tz should match each identity's exit IP. Within one identity, all five should be identical tomorrow. If every row is the same, the sites you visit are counting one machine. The consistency checklist lists more pairs, and the agent setup page has the MCP configuration.