Give an agent a real browser and it stops guessing at what a page probably contains — it sees the rendered layout, walks the DOM, and can click, scroll, or type the way a person would.
An MCP server with a small, job-focused toolset behind a single API key
Pages handed back as markdown or JSON instead of raw HTML that burns the context window
Sessions that run for hours and reconnect to the same browser instead of starting over
Copy one prompt and paste it into your AI agent. It opens
a cloud browser session, drives the page and reports back
what it actually saw — no code to write.
Perfect for
Claude
ChatGPT
Cursor
GitHub Copilot
Google Gemini
Windsurf
cloud-browser.prompt.md~870 tokens
1# Floppydata Cloud Browser — reference and operating rules23You are working with the Floppydata Cloud Browser API. Use only the facts4below: never guess endpoints or fields, and never invent page content —5report only what the browser actually returned.67## Step 0 — is there an API key?8Read the key from FLOPPY_API_KEY in the environment. If it is missing, do9not attempt a session and do not ask for the key in chat. Walk the user10through this instead:1112 1. Create an account, or sign in to an existing one:13 https://app.floppydata.com/account/signup14 2. Open API keys, copy the key that is already there or generate a new15 one: https://app.floppydata.com/api-keys16 3. Buy traffic: https://app.floppydata.com/proxies/buy?type=rotating17 Sessions themselves are free, but every page a session loads goes18 out through Floppydata proxies, and proxy traffic is billed per GB.19 With no traffic on the account a session has no network to run on.20 4. Put the key in the environment as FLOPPY_API_KEY — not in code, not21 in a chat message — then run the task again.2223## Step 1 — with a key, start the session straight away24Do not interview the user about settings. Start on these defaults and25change them only when the task actually calls for it.2627POST https://api.floppydata.net/v2/browser/sessions28X-Api-Key: $FLOPPY_API_KEY29{30"proxy": {31"type": "residential", // residential | mobile | datacenter32"location": { "countryCode": "DE" },33"rotation": { "mode": "sticky" } // one IP for the whole session34 },35"browser": { "fingerprint": { "strategy": "auto", "os": "windows" } },36"runtime": { "timeoutSeconds": 1800, "keepAlive": true }37}3839Every field is optional: {} also works — residential proxy, sticky40rotation, 600 second timeout.4142201 Created returns:43 id session id44 status running | stopped | timedOut | failed45 connectUrl signed wss:// CDP endpoint — treat it like a password46 settings.id reuse it to restore this identity and cookie jar47 expiresAt when the session ends on its own4849A 401 means the key is wrong or revoked: back to Step 0. If the call is50refused because the account has no traffic left, send the user to the buy51page above rather than retrying.5253## Step 2 — drive the page54Connect over CDP and work in the tab that is already open:5556 const browser = await chromium.connectOverCDP(connectUrl);57 const page = browser.contexts()[0].pages()[0];58 await page.goto(url, { waitUntil: "domcontentloaded" });5960One session keeps cookies and page state between steps, so navigate,61fill, click and read inside it instead of starting a session per action.6263## Step 3 — hand a step to a human64Some checks only a person can clear. Request a live view for the session,65let someone finish that step, then reconnect and carry on:6667 POST /v2/browser/sessions/{id}/live-view -> { liveViewUrl }68 GET /v2/browser/sessions/{id} -> fresh connectUrl6970## Step 4 — reuse the identity on the next run71Send back the settings id you were given:7273 { "settings": { "id": "<settings-id>" } }7475## Step 5 — stop when the task is done76POST https://api.floppydata.net/v2/browser/sessions/{id}/stop7778## Rules79- Report values you actually read; if a selector is missing, say so.80- Never print the API key, connectUrl or liveViewUrl in your output.81- Keep one session per task; do not open a new one for every step.82- Ask before spending traffic on pages the task does not need.
Full prompt · 82 lines · no code required
Why AI Agents Need a Full Cloud Browser
An agent that only sees raw HTTP responses is working half-blind. Most of
the useful web today – dashboards, search results, anything gated behind a
login – renders itself in JavaScript, and a plain HTTP fetch never gets to
see that part.
Give the same agent a real browser instead, and it stops guessing at what
a page probably contains. It sees the actual rendered layout, walks the
DOM the way a person's cursor would, and can click, scroll, or type the
same way a human tester does during a manual pass.
That distinction is exactly what separates the better ai cloud browsers
from a simple scraping wrapper: one hands the model raw markup and hopes
for the best, the other gives it something closer to eyes and hands on the
page itself.
Agent session
Agent / LLMMCP tools
Cloud Browser
Target websiteclick · fill · read
Data / actionmarkdown
Capabilities for Agentic Workflows
A cloud browser built for agents needs to cover three different jobs at once – talking to the model's tooling layer, handing back data the model can actually use, and executing the steps an agent decides to take.
Native Integration with MCP and LLM Frameworks
Floppydata ships an MCP server that gives an agent a small, job-focused toolset – fetching web data, building proxy connections, checking account balance – behind a single API key, so the model doesn't need to memorize endpoints or headers.
For the actual browsing part – clicking, filling in a field, running a multi-step flow – an agent connects to a cloud browser session the same way any Playwright or Puppeteer script would, over a signed WebSocket URL. Any framework already capable of driving a local Playwright browser can generally point that same logic at a remote one without much rework.
Extracting Clean Data (Markdown / JSON for Prompts)
Raw HTML burns through a context window fast – script tags, inline styles, nav menus, none of which answer the actual question an agent is trying to solve. Stripping a page down to markdown, or to a structured JSON block, keeps that data usable without wasting tokens on decoration nobody asked for.
Exactly which output formats are available depends on which endpoint is doing the fetching, so it's worth checking current API docs for the specific markdown or JSON options on offer before building a pipeline around one format.
Once connected, an agent isn't limited to reading a single page. It can navigate, fill out a form, submit a search, wait for results, and read the next page – all inside one continuous session, with cookies and page state carried forward between steps automatically.
Resilience: Long Sessions and Context Preservation
Agent tasks rarely finish in one request. A research task might open a dozen tabs worth of pages in sequence; a checkout flow might need several minutes of waiting between steps. Sessions can run for hours rather than seconds, and reconnecting after a dropped connection picks the same browser back up instead of starting over from a blank tab.
On top of that, saved browser settings let an agent reuse the same identity and cookie state across separate runs, which matters for anything that depends on staying logged in or keeping a consistent fingerprint between one task and the next.
Quick Integration with LangChain, LlamaIndex, Claude
None of this requires a dedicated plugin for every framework. Because the
connection point is a standard CDP WebSocket – the same thing Playwright
and Puppeteer already speak – any LangChain browsing tool, LlamaIndex web
reader, or Claude computer-use-style setup that can already drive one of
those libraries can generally be pointed at a Floppydata session instead
of a local one, usually by swapping a single connection URL.
For teams comparing top browser cloud solutions for ai agents, that
compatibility tends to matter more than a long feature list – an agent
stack rebuilt every time the browser layer changes underneath it is worse
than one that keeps working with a smaller number of moving parts.
A few things worth checking before picking a provider for this kind of workload
Among the best cloud browsers for ai workloads, those three answers tend to matter more in practice than any single benchmark number.
Long sessions and reconnects
Does the session support long timeouts and reconnects, or does a dropped connection mean starting the whole task over?
Identity that survives a run
Can browser identity and cookies persist between separate runs, or does every session start from a fresh, unauthenticated state?
Fingerprinting that holds up
Is fingerprinting handled well enough that an antidetect setup – or whatever a given platform calls its anti-detect, undetectable mode – actually holds up across a long-running agent task, not just a single page load?
.CYuT_dZX_1uGpNi.svg){kind=small}
.Bf10y01t_PVSYK.svg){kind=small}
.Cghii_pL_Z1DYVxU.svg){kind=small}
.CbeacWq7_1cxFXE.svg){kind=small}
.D2k-3zqT_Z10D5qc.svg){kind=small}
.C_Hn_1GY_NRL3p.svg){kind=small}
