MCP browsers
When a routine needs a real browser, which options a cloud run can reach, which only work on your own machine, and what RoutineOS has and has not tested.
What it is
Some sources need a browser: pages built by JavaScript, sites that block plain fetches, pages behind a login. An MCP browser is a browser exposed to Claude through an MCP server, so a run can open a page, read it and act on it.
Why it exists
A routine that only fetches HTML misses what a browser would see, and a routine that drives your own logged-in browser cannot run in the cloud. Choosing the browser is a design decision with security and cost consequences, so RoutineOS makes it explicit.
How it works
Local or hosted
The deciding question for a routine is where the browser runs.
- Local browsers run on your machine. A cloud scheduled task cannot reach them: local MCP servers are not available to a cloud task unless added as a connector or declared in a committed
.mcp.json(docs, fetched 2026-10-30), and a browser on your laptop is not on the run’s network either way. This is an inference from the docs, not a tested result. - Hosted browsers run in a provider’s cloud and are reached as a remote MCP server or an HTTP API. A run can reach one through a connector, or directly if the host is on the environment’s allowlist. RoutineOS has not run a call from a routine to any of them.
The options
Figures below are each vendor’s own headline at fetch time (2026-10-30) and change often. None is a RoutineOS recommendation.
| Option | Where it runs | MCP | Pricing headline | Source |
|---|---|---|---|---|
| Claude in Chrome | Your own Chrome, through an extension | Built-in claude-in-chrome server for Claude Code |
Needs a direct Anthropic plan; no separate fee found | docs |
| Playwright MCP | Local (npx, Docker, standalone HTTP) | Yes, by Microsoft | Free, open source | repo |
| Chrome DevTools MCP | Local, launches Chrome | Yes, by the ChromeDevTools org | Free | repo |
| Browserbase | Hosted | Hosted Streamable HTTP, built on Stagehand | Free tier; Developer $20/mo; Startup $99/mo | docs, pricing |
| Steel | Hosted or self-hosted | steel-mcp-server |
Launch $0/mo plus usage; Scale $250/mo | repo, pricing |
| Hyperbrowser | Hosted API; the MCP server runs locally via npx with an API key | Yes | Free 5,000 credits; paid from $30/mo | repo, pricing |
| Cloudflare Browser Run (formerly Browser Rendering) | Hosted | https://browser.mcp.cloudflare.com/mcp |
Free 10 min/day; Paid 10 hr/mo then $0.09/hr | docs, pricing |
| browser-use | Python library, local or its hosted cloud | Unverified | Library free | repo |
| Anchor Browser | Hosted | Has an MCP integration page | Not on the page fetched | docs |
Two notes from the sources: the Playwright MCP README says it “is not a security boundary”, and Chrome DevTools MCP collects usage statistics by default (opt out with --no-usage-statistics). The Steel README says its hosted mcp.steel.dev is not live yet.
What RoutineOS has seen
- A pilot fetched SEEK pages through the Cloudflare Browser connector’s
get_url_markdownand was served a bot challenge instead of results (seek-bot-challenge-via-browser-connector, pilot-verified). A hosted browser is not a way past a site’s bot protection, and a routine should not try to make it one. - A run’s direct network access behaves like an allowlist, and
api.cloudflare.comwas blocked in a pilot (sandbox-allowlist). Reaching a hosted browser as a connector avoids that, because connector traffic goes through Anthropic’s servers.
Declaring a browser
A hosted browser is an [[integration]] like any other: kind = "connector" if added on claude.ai, kind = "mcp" if declared in .mcp.json, with direction = "read" unless it fills forms or clicks buttons that change something. A browser that submits anything is a write and needs a gate. Any API key is a network secret, never an environment variable.
Worked example
Hiring Signals does not need a browser. Its prompt asks for facts read from job pages, and a plain fetch or web search covers public postings. If a board renders listings only in JavaScript, the design would add a hosted browser as a read connector, probe one board page from a report-only run, and record the result in risks.md. If the probe returns a bot challenge, as SEEK did, the board is dropped from the design, not worked around.
Common pitfalls
- Designing a cloud routine around Claude in Chrome. It is your own browser on your own machine.
- Treating a hosted browser as a scraper licence. Respect each site’s terms and bot protection.
- A browser with write access and no gate. Clicking “submit” is a send.
- Quoting vendor prices as fixed. They are snapshots.