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 one site’s verified 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/{domain} — deterministic recipes for one site as typed tools. Always pass a domain from an IDE or chat client.

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/{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. Without a domain, /v1/mcp/actions lists every active action across all sites, currently thousands of tools. That form is for programmatic consumers that index tools themselves; IDE and chat clients should always use the domain form.

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, a project other than your default, or an Agent Access key. Teams using Agent Access identity enforcement also send anchor-identity-token.

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.