Skip to main content
Model Context Protocol Anchor’s hosted MCP servers give an agent a real browser in the cloud. Each session is an isolated VM destroyed when it ends, there is no concurrency limit, and the tools cover what agents actually struggle with on the web:
  • Sites that block bots: residential and mobile proxies by country, extra-stealth fingerprinting, automatic captcha solving.
  • Scale at low cost: saved tasks and the action index run deterministic code and fall back to an AI step only where a page changed, so repeat work does not pay LLM cost.
  • Digital coworkers: long-lived signed-in sessions, a live view the user can watch or take over, and sign-in links so a person never hands an agent a password.
  • Authentication: identities are managed logins; Anchor signs in, handles MFA, and keeps credentials in its vault. No tool returns them.
  • Security: ephemeral VMs, Zero Data Retention mode, SOC 2 Type II, ISO 27001, HIPAA, and GDPR.
Nothing to install. Paste a URL into your client and sign in, or add an API key header. The dashboard’s MCP page builds the config for you.

Servers

Three servers over the same account. Start with Anchor; add Anchor Browser to drive a live browser and Anchor Actions for verified site actions.

Anchor

https://api.anchorbrowser.io/v1/mcp — start here. Web tasks, site actions, saved automations, managed logins, browser sessions, and call_endpoint for everything else.

Anchor Browser

https://api.anchorbrowser.io/v1/mcp/browser — step-by-step control of a live browser.

Anchor Actions

https://api.anchorbrowser.io/v1/mcp/actions — find and run deterministic recipes for any site. Add /{domain} for one site’s recipes as typed tools.

Anchor

https://api.anchorbrowser.io/v1/mcp Add to Cursor, or from a CLI:
The headline set for agents that should get work done on the web: Long operations are asynchronous so tool calls return within a minute: perform_web_task returns a workflow_id to poll with get_web_task_status, reauthenticate_identity returns pending to poll with get_identity, and run_task returns an execution to poll with get_execution.
https://api.anchorbrowser.io/v1/mcp/all serves every route tagged for agents as its own typed tool, Anchor tools first, for integrations whose client can hold a large tool list. Use it instead of Anchor, not alongside it; the tool names overlap.

Anchor Browser

https://api.anchorbrowser.io/v1/mcp/browser Add to Cursor, or from a CLI:
Step-by-step anchor_* tools over a live Anchor session: navigate, snapshot, click, type, screenshot, network and console logs, and Playwright code generation. Element references come from accessibility snapshots instead of selectors, so no vision model is needed. Add an anchor-session-id header to attach to a session you created on the Anchor server; without it the first tool call opens a new session. Every result echoes the session id so perform_web_task and actions can continue in the same browser.
https://api.anchorbrowser.io/mcp is the legacy address of this server and keeps working with an anchor-api-key header.

Anchor Actions

https://api.anchorbrowser.io/v1/mcp/actions One server for every site, with two tools. find_actions takes a site (a URL or bare domain) and/or a short goal and returns matching actions with their input schemas, outputs, and run records. run_action runs one by name. Actions run server-side in an Anchor browser with no LLM steps, and neither tool returns the action’s code.

One site as typed tools

https://api.anchorbrowser.io/v1/mcp/actions/{domain}, for example /v1/mcp/actions/amazon.com The domain is part of the URL, so each site is its own server. For amazon.com: Add to Cursor, or from a CLI:
Several sites run in parallel: repeat with a different name and domain for each (anchor-linkedin, anchor-github, …). They share one sign-in and tool names are prefixed with the site, so they do not collide. The anchor-actions plugin holds one domain per install; use these per-site entries for anything beyond that. Every active action index item for the site becomes a tool with the action’s own parameter schema. Actions that require a signed-in session say so; pass the sessionId of a session created with an identity on the Anchor server. Each run is deterministic code in an Anchor browser, with no LLM steps.

Authentication

Sign in (OAuth). Give the client only the URL. On first use it opens the Anchor sign-in and connects to your default project. Cursor, Claude, ChatGPT, Grok, and VS Code all support this. API key. Add an anchor-api-key header from API Keys. Use this for CI, non-interactive runtimes, or a project other than your default.

Connect a client

Each server above has its own Add to Cursor link and CLI commands. The snippets here use the Anchor server and cover the remaining clients; swap the URL for any server.
One click: Add to Cursor, or add to .cursor/mcp.json:
With an API key instead of sign-in:

Examples

Install as a plugin

The anchor-mcp-plugin repository lists anchor, anchor-browser, and anchor-actions as separate plugins for Cursor, Claude Code, and Grok, using sign-in for authentication. anchor-actions asks for the site domain.
In Cursor, install Anchor from the marketplace; Anchor Browser and Anchor Actions are listed alongside it. For Grok, copy the repository’s .grok/config.toml into your project or run the grok mcp add commands from its README.

Self-hosting

For custom tools or running inside your own infrastructure, see the open source MCP server.

Getting help

  1. Check the API key or re-run the sign-in from your client.
  2. Disable and re-enable the server in the client.
  3. Reach out at support@anchorbrowser.io.