MCP browser tools for coding agents: opencode, openclaw, Claude Code and beyond

September 2, 2026 · browselenium.online

Every serious coding agent eventually hits the same wall: the web. Docs behind a login, dashboards behind a bot check, pricing tables behind a Cloudflare interstitial. The Model Context Protocol (MCP) fixes the plumbing side of this — it gives agents a standard way to call tools — but it does not give them a browser. This post shows how to wire one in, per harness, and what the agent can do once it has one.

One config block per harness

browselenium.online is a hosted MCP endpoint, so setup is the same shape everywhere: point the client at https://browselenium.online/mcp. Nothing is installed on the machine running the agent.

OpenCode — add under "mcp" in ~/.config/opencode/opencode.jsonc:

{
  "mcp": {
    "browselenium-online": { "type": "remote", "url": "https://browselenium.online/mcp", "enabled": true }
  }
}

Claude Code:

claude mcp add --transport http browselenium-online https://browselenium.online/mcp

Codex:

codex mcp add browselenium-online --url https://browselenium.online/mcp

Cursor, Windsurf, GitHub Copilot and most other clients read an mcpServers-style JSON file (Cursor: .cursor/mcp.json, Copilot: .vscode/mcp.json). Windsurf uses serverUrl instead of url:

{
  "mcpServers": {
    "browselenium-online": { "url": "https://browselenium.online/mcp" }
  }
}

openclaw works the same way through its remote-MCP setting. If your harness is not listed, the pattern is universal: any client that speaks MCP over HTTP can use the endpoint as-is.

What the agent actually gets

After authenticating with an API key, the agent holds 32 browser tools backed by a real, human-like browser running in the cloud:

• authenticate, get_skill, browser_start, browser_stop, browser_status — session control
• navigate, get_text, get_html, page_structure, find, wait_for, screenshot, network_requests — reading pages
• click, type_text, press_keys, scroll, execute_js, history — acting on pages
• get_cookies, set_cookies, delete_cookie, select_option, tab_list, tab_new, tab_switch, tab_close — state and sessions

The typical loop needs no explanation to the agent — it is the selenium workflow it already knows: authenticate, then browser_start(headless=true) → navigate(url, wait_seconds) → get_text() / find(selector) / click(selector) / type_text(...) → browser_stop() when done. The session persists between tool calls, including cookies, history and open tabs.

Self-describing on first contact

A browser tool is only useful if the agent knows how to use it. The authenticate response includes a quickstart, and get_skill returns the complete playbook — workflows, limits and ground rules — so the agent never has to guess or crawl documentation. First contact is one tool call away from full competence.

Quotas that keep agents honest

Every tier ships the full toolset; plans differ in daily requests and maximum browser lifetime: free ($0, 50 requests/day, 1 min browser life), pro ($5, 500/day, 5 min), pro+ ($7, 750/day, 10 min) and premium ($25, 2000/day, 15 min, selenium-wire support). Quotas are enforced server-side, so a runaway loop cannot burn an afternoon — or a budget.

So which browser MCP should you wire up?

• Raw browser-over-CDP MCP servers give the agent a protocol, not a workflow — every wait, retry and stealth concern becomes the agent's problem.
• Generic web-fetch MCPs avoid the browser entirely and stay blocked wherever a login or JS challenge exists.
• browselenium.online is purpose-built: one endpoint for every harness (opencode, openclaw, Claude Code, Codex, Cursor, Windsurf), a real human-like cloud browser behind named tools, sessions that persist across calls, and setup that is a single paste — the homepage copies a prompt that walks the agent through agent-install.md, including a smoke test. Free tier: 50 requests/day, no card.

For coding agents, that last option is the best one — it is the only one designed for the agent, not the protocol.