Drive GodBrowser Cortex from your AI client

Connect

A remote, streamable-HTTP MCP server — zero install, no local process. Add it to Claude Code with one command:

claude mcp add --transport http godbrowser-mcp \
  https://mcp.godbrowser.io

Or drop this into any MCP client's mcpServers config:

{
  "mcpServers": {
    "godbrowser-mcp": {
      "type": "http",
      "url": "https://mcp.godbrowser.io"
    }
  }
}

No key to paste. The first time your client connects it opens the GodBrowser consent screen in your browser — approve it and a per-device token is minted automatically under your account. Revoke any device from the dashboard → API Keys.

Tools

Each tool scopes to your account via your authorized session — submit, poll, fetch. The surface never exposes a node, our internals, or a browser-control url; it's strictly your workflows.

Access tiers. The reading surface — navigate, read_page, extract (including extractSchema), click, type, the asserts, tabs and frames — is available on every tier. Interactive live sessions are their own tier, and it is off by default. When it is not enabled for your account, godbrowser_launch, godbrowser_scrape_templates, godbrowser_session, godbrowser_set_persona answers external_tier_not_enabled — the batch surface (godbrowser_submit, godbrowser_run_recipe, godbrowser_status, godbrowser_results) stays available to you. A few DRIVE verbs stay first-party/operator-only in v1 — godbrowser_eval, godbrowser_protections, godbrowser_recipe_from_recording, godbrowser_save_recipe, godbrowser_wait_for_function answer first_party_only. godbrowser_login, godbrowser_register are operator-only in v1 and answer operator_only_v1. Each of these is a clean, named error rather than a silent failure, so a client can tell "not enabled for you" apart from "that call went wrong".

Saved logins, and what a restore actually restores. When the machine running GodBrowser is signed in to an account, godbrowser_launch now persists by default — the session banks its logins into a stable default profile, so the same session can be brought back from any other computer. Pass persist:false for a throwaway run that leaves nothing in your account. A godbrowser_session restore then reproduces the whole identity rather than just the cookies: the device it was banked on (OS/browser/persona), its locale, and the egress country it was created from — it tries the same exit, then any exit in that country, then falls back to the local machine and says so, in egress_continuity. That matters because a returning session whose device or country changed is a stronger signal than a fresh login would be. Do not pass os or browser to a restore unless you deliberately intend to override the banked device — the response reports persona_restored, persona_banked and egress_continuity so you can check what you actually got.

Choosing your egress. godbrowser_proxy reports what you have — providers, the exit country of each, sticky vs rotating and how often, and which lines are pool sources rather than direct exits — and parses any proxy string you paste, in any provider format. It never returns a password. Then launch through it with proxy (an explicit string) or proxy_provider / proxy_country (pick out of your configured pool). An exit whose provider string states no country is excluded rather than assumed to match, so you never silently egress from somewhere else, and the launch reports the exit it actually chose instead of a bare success.

Launching from a link. The same launch options travel in a gb://open?… URL, so a portal button or a runbook can open GodBrowser on the right saved session, device, locale and egress country. It is argv-only by design — a page cannot trigger one without the operating system's own open-in prompt — and it refuses a proxy credential or a non-http(s) landing page outright. godbrowser_link builds one for you (and does the percent-encoding in code, which is the part that goes wrong by hand). The keys, the encoding rule and the full refusal contract are on the parameter reference. Registration and parsing are verified; end-to-end delivery from a real click is still being confirmed per platform, so treat the scheme itself as arriving in an upcoming build.

Recipes — record, then replay. Drive a flow once, save it with godbrowser_save_recipe, then replay it deterministically at scale with godbrowser_run_recipe (no AI in the replay path). A recipe is data, not code — an ordered list of recorded steps (navigate/click/type/select/press/scroll/wait/extract/screenshot) with their recorded arguments; page-script evaluation steps are never recorded into a recipe, and a recipe containing one is rejected before replay begins. Recipes are scoped to your account: you list, replay and delete only your own. recipe-replay is also a named built-in code_ref alongside flagship-scrape-quotes, books-catalog, books-detail and custom-scrape — it is the deterministic replay walker that godbrowser_run_recipe submits for you.

From your AI client, a full run is three calls — submit, poll, pull:

godbrowser_submit({ code_ref: "flagship-scrape-quotes", os: "windows", seed: "run-1", count: 10 })  → { job_id, task_ids }
godbrowser_status({ job_id })   → status: succeeded, result_count: 300
godbrowser_results({ job_id })  → rows (10 coherent per-seed shards, one job)

Run your OWN target at scale — not bounded to the demo code_refs: pass url + a fields CSS-selector map (and optional item_selector for a repeating list/table) to godbrowser_submit, and it fans the vetted custom-scrape builtin (deterministic CSS extract, no code upload) across the fleet:

godbrowser_submit({ url: "https://example.com/products", item_selector: ".product",
                    fields: { title: ".name", price: ".price", "tags[]": ".tag" }, count: 3 })
  → runs the custom-scrape builtin on your own URL, fanned 3 ways

Playbook — record → analyze → optimize

When a browser-driven automation is slow or brittle, reduce it to a direct requests-only path:

1. Run a session with a BusyMate capture device (--bm-device-name=<label> + --bm-auth-file=<account busymate_auth>).
2. Perform the action — navigate / filter / submit.
3. If the busymate-net MCP is connected, summarize_device_traffic(<device>) then inspect_requests(host, path_contains, method=POST) the captured traffic.
4. Identify the data endpoint — the XHR / GraphQL / REST op returning the records.
5. Reconstruct a direct requests-only call → instant data.

Worked example: investigating 999.md this way surfaced POST /graphql (op SearchAds); replaying it directly returned the full ~88,793-car dataset. The native capture_network verb (roadmap) will make this in-browser.

Why MCP