Display a prepared Browserless replay, screenshot gallery, video, or human handoff inline. Pass the exact viewRef returned by its producer tool. Never repeats browser actions, downloads, or creates another handoff.

Widget-only reader for a prepared replay. Not a rendering tool. Use the original viewRef and opaque cursor; never fetch replay data into the conversation.

Export a webpage from a URL via the Browserless /export API. Fetches the URL and returns its content in the native format (HTML, PDF, image, etc.). Automatically detects the content type. Set includeResources=true to bundle all page assets (CSS, JS, images) into a ZIP archive for offline use.

Load a Browserless agent skill on demand, or discover site-specific recipes.

Two uses:

• { site: "" } — list any site-specific recipes tuned for that host (e.g. { site: "ebay.com" }), returned as pointers. Do this as soon as you know the host you're about to drive; if one matches your task, load it by id. Returns a "no recipe" note when there's none.

• { id: "" } — load a skill body: an in-house skill id (list below) OR a site recipe id host/slug from a site lookup.

Use the in-house skills below when you suspect the page exhibits a non-trivial mechanic but no SKILL block was auto-injected. The auto-injection heuristics are conservative; calling this tool is the explicit fallback.

Available in-house skills:

• shadow-dom — deep selectors, iframe URL-pattern syntax, what works through deep-ref

• cookie-consent — vendor-specific dismiss recipes (OneTrust, Cookiebot, Didomi, etc.)

• modals — close-button heuristics, ESC handling, alertdialog vs. dialog

• snapshot-misses — truncated/empty snapshots, image-rendered content

• dynamic-content — choosing the right wait* method after async triggers

• screenshots — when to screenshot vs. snapshot, scope and format choices

• vision-fallback — click by coordinate when a "< " deep selector still can't surface the element (shadow DOM, nested iframe, canvas)

• tabs — multi-tab workflows, peek-without-switching

• autonomous-login — load before authenticating: when the user asked you to log in, when a wall blocks the task, or as soon as a password input appears. Covers the don't-login-by-default posture, contextual credential matching, MFA/captcha branches, and how to report the outcome.

• autonomous-registration — load before creating an account: when the user asked you to sign up / register, or as soon as a Create-account form appears. Covers the don't-register-by-default posture, identity and credential-sink rules, save-first-then-loadSecret password handling, the emailed-code branch, and how to report the outcome.

• captchas — the solve command, response semantics, escalation path (Cloud-only)

• file-transfers — uploadFile / getDownloads, stdio-path vs. base64 content, size caps

• profile-import — import the user's local Chrome/Brave/Edge sign-ins as a profile with the Browserless CLI (consent-gated; only when running on the user's machine)

READ CAREFULLY: Execute browser commands in an agent session.

Core Loop (ReAct: Reason → Act → Observe)

1. Plan + check for a site recipe — restate the goal, decide the target host, then browserless_skill { site: "<host>" } (see above). Load and follow any matching recipe before writing your own plan. Never jump straight to goto.

2. goto — waits "domcontentloaded"

3. snapshot — returns interactive + informational elements (button, link, textbox, combobox, checkbox, heading, img+alt) with ref= selectors

4. Plan all actions from snapshot

5. Batch execute

6. Re-snapshot only if page changed

7. Repeat → close when done

Ending the session (REQUIRED)

One-shot vs. multi-step (session lifetime). Sessions are one-shot by default: when your commands batch and download drain finish, the browser closes and frees its slot. Decide on your FIRST call:

• One batch finishes the whole task (e.g. goto + text/html/evaluate to read something): leave it one-shot; it closes automatically.

• You must look, then act on what you see — any first batch that ends on a snapshot so you can plan later clicks/typing: set keepSessionAlive: true on that first call. The observe-then-act loop spans calls, so this covers most interactive work.

• Unsure? Set keepSessionAlive: true. A kept session still auto-reaps when idle; a wrongly-closed one loses your page, login and progress. After a keepSessionAlive: true call, pass the returned sessionId back on every later call — it stays alive, no need to repeat the flag. Set keepSessionAlive: false to force-close even when continuing. Profile creation and attached sessions manage their lifetimes separately.

When a step requires human input or you cannot safely proceed without help, stop browser actions and preserve that session. Use an available human-handoff capability to show the browser with specific instructions, then ask the person to finish the step and reply. Never ask them to paste passwords or verification codes into chat. Wait for confirmed completion before taking a fresh snapshot and continuing in the same browser; do not open a replacement or assume that opening a viewer completed the step.

An open session holds one of the account's concurrent browsers until it idles out — leaving it open is not free, and stacking them starves the next task. Report the outcome (only if you loaded a site recipe). Near the end of the run, send { method: "reportSkillOutcome", params: { domain: "<host>", task: "<slug>", success: <bool> } } inside commands — where domain/task are the loaded recipe's <host>/<slug> and success is false if a step in this recipe failed as written, even if you finished another way. Cosmetic differences that didn't break a step are still success: true. This refines shared recipes and retires ones that stop working. Send it once, and only when you loaded a recipe — never for a self-planned run. Send it before reportOutcome and any close (close ends the run and anything after it is dropped). When the loaded recipe's footer shows run_id, skill_use_id and loaded_version, include all three exactly as shown; never invent or alter them, and never send attribution_status. On failure, add one bounded failure_reason: authentication_required (login needed), site_changed (a URL or element no longer matches), blocked (access denied or challenge), timeout (operation timed out), missing_data (required output absent), incorrect_result (output present but wrong), or unknown (cause unclear). For example: { method: "reportSkillOutcome", params: { domain: "example.com", task: "search", success: false, failure_reason: "missing_data" } }. On success, omit failure_reason; success with a failure reason is invalid. Boolean-only legacy reports remain valid; failures default to unknown. These are agent-reported results, not independent validation. Never supply outcome_source: the server assigns provenance. Do not put URLs, secrets, prompts, copied content, or free-form explanations in outcome fields.

• Report the outcome after you've seen the results. Once the task is done or you are giving up, and you have seen the final results, send { "method": "reportOutcome", "params": { "success": <bool> } } once per task (it costs nothing and is not a page action). If success is false, add "reason": blocked_by_site, captcha, login_required, timeout, or other. Kept-alive session: include it in the batch before close, or send it alone before close. One-shot call: send it as its own call with the sessionId the one-shot reply gives you, which opens no browser.

• Kept-alive task complete? Close it. Send { "method": "close" } as its own call, as the last thing you do.

• Ask instead of guessing only when follow-up in the SAME browser is genuinely likely (the user said "then...", you're mid-flow on a logged-in site, or the result invites a next step). Say the browser is still open, ask whether to close it, and close it as soon as they're done.

• Never end your reply with a live session and no mention of it. Either it's closed, or you told the user it's open and why.

Site recipes (site-specific, NOT auto-injected) — CHECK FIRST

Many specific sites (marketplaces, gov portals, travel, real-estate, etc.) have a tuned recipe for a given task — proven selectors, API shortcuts, proxy needs, and known gotchas that a from-scratch plan will miss. These are not auto-injected; you must ask for them, and a recipe overrides any plan you'd build yourself (including "just use a prefiltered URL + evaluate"). This is step 0 of every task — do it before your first goto. The moment you know the target host (the user named the site, or you resolved which site to use), call browserless_skill { site: "<host>" } — e.g. { site: "airbnb.com" }. If it lists a recipe matching your task, load it with browserless_skill { id: "<host>/<slug>" } and follow it. Only when there's no match do you plan the steps yourself. Skipping this check on a supported site is a mistake — it's one cheap call.

Proxy (optional)

Proxy config is a top-level proxy object on the tool call — it is applied when the session is opened. NEVER call proxy as a method inside commands — a { method: "proxy", ... } JSON-RPC mutation does NOT change the upstream proxy on an already-open session and will silently no-op.

If there is credible evidence the task needs a proxy, you MUST pass proxy options on the very FIRST call (before any goto/snapshot), because the config is read once at session creation. Credible signals include: the user asks for a specific country/region/locale; the target site is known to geo-restrict or block datacenter IPs (streaming, ticketing, retail, banking, real-estate, news paywalls); a prior attempt returned 403/451/captcha/"unusual traffic"/"access denied"; the user explicitly mentions residential / sticky IP / proxy.

If you already opened a session without a proxy and now realize one is needed, you must close and start a new session with the proxy options set — there is no in-session switch.

• Use proxy: { proxy: "datacenter" } when a lower-cost IP is sufficient. Use proxy: { proxy: "residential" } when the target is known to block datacenter IPs or the cheaper tier still hits a challenge.

• Inside the object: proxyCountry: "us" — geo (ISO-2); proxyState / proxyCity (paid plans, 401 otherwise); proxySticky: true — stable IP; proxyLocaleMatch: true — match locale; proxyPreset — residential-only named config; externalProxyServer: "http://u:p@host:port" — bring your own (http(s) only)

• Geo/sticky/locale options require a built-in proxy tier or externalProxyServer; proxyPreset requires proxy: "residential"

OS persona (optional)

The top-level emulationOs, emulatedDevice, screen, deviceScaleFactor, and deviceSlot options are read once when the session opens. Put them on the very first call, before any goto, then keep using the returned sessionId; close and open a new session to change them.

Reach for emulationOs only when there is evidence of platform fingerprinting: a Cloudflare or similar interstitial that never resolves, a hard block on an otherwise healthy page, or a site known to inspect the operating system. Start with emulationOs: "windows" unless the task or site requires another OS. Use emulatedDevice only with Android; desktop screen, deviceScaleFactor, and deviceSlot refine a desktop persona.

Auth

For an existing-profile session, set keepSessionAlive: true on the initial call so the browser stays open for the required next-batch saved-login report.

Never log in or register by default. Never invent or assume credentials exist (no "test credentials", no "your account"). If the snapshot contains a sign-in link OR you're about to mention "sign in" / "log in" / "auth required" — even as a suggested option to the user — call browserless_skill { id: "autonomous-login" } first — or { id: "autonomous-registration" } when the task is to create an account / sign up / register —, then follow its gates. The skill decides whether login is appropriate and whether credentials are in scope; do not skip it just because no password field is on the page yet.

After a loadSecret login, screenshot, PDF, liveURL, and page-content reads (evaluate/html/text) stay blocked until the credential is cleared. A full-page (main-frame) navigation clears it automatically; a single-page app that logs in without one — or only changes route client-side — does not. Once the credential is no longer on screen, send { method: "clearSecrets" } before the first capture. A CaptureBlockedError after login means this step was skipped.

Saved-login check (only when the session was opened with profile). After the first batch that loads a page on each site — however you read it (snapshot, text, evaluate, or screenshot) — send { "method": "reportProfileAuthentication", "params": { "checkpointId": "<host>:first-page", "outcome": "<authenticated | login_required | challenge | unknown>", "newLoginActivity": false } } as the FIRST command of your NEXT commands batch, before any login actions; the rest of that batch can continue the task, but not with close. If login activity already occurred on this site, use newLoginActivity: true instead. It defaults to the last active-tab snapshot, so if you have not taken one yet, end that first page-load batch with snapshot; if you used snapshot { targetId } to peek at another tab, repeat that targetId in the report. Report authenticated only when the page shows a signed-in element (account menu, sign-out link, avatar); a 200 page, cookies, or a non-login URL alone is unknown. Report login_required for a sign-in form or wall, challenge for a captcha or verification wall. If you later log in on that site (typed credentials, loadSecret, or the autonomous-login skill), send one more report for that site with "newLoginActivity": true and a new checkpoint label such as "<host>:after-login". It is not a page action, costs nothing, and is allowed right after loadSecret. Never send it on sessions without profile.

Pass sessionId on every follow-up call, including reports and close; the session handle retains the profile, so repeating profile is optional.

Terminal-Goal Check

Before declaring done, restate the user's terminal deliverable in one line and verify your evidence directly supports it — not a sibling question. Empty-state substitution. An empty/zero/null result from a resource that normally requires auth, scope, or filter context is evidence the precondition wasn't met — not evidence the question is answered. Empty cart while logged out, zero results while geo-restricted, empty inbox while unauthenticated: precondition failure → fix the precondition (often: load autonomous-login), don't return the empty result as the answer. Multi-step preconditions. When the task names multiple steps ("go to X, then Y, report Z"), evaluate preconditions for the full chain before treating any step as optional. A blocker on step N blocks the whole task even if step 1 returned data.

Skills (auto-injected)

SKILL blocks auto-inject between --- SKILL: <id> --- markers when page/error needs special handling. Read carefully. Load manually via browserless_skill if suspected but not injected:

• autonomous-login — gates, credential rules, MFA/captcha, how to report the outcome (see ## Auth above for when to load)

• autonomous-registration — create-account flows: gates, identity and credential-sink rules, save-first-then-loadSecret password handling, emailed-code branch, how to report the outcome

• shadow-dom — deep selectors, iframe targeting

• cookie-consent — vendor-specific dismiss recipes

• modals — closing dialogs and alertdialogs

• captchas — the solve command (Cloud only)

• snapshot-misses — truncated/empty snapshots, image-rendered content

• dynamic-content — choosing the right wait* method

• screenshots — when to screenshot vs. snapshot, scope and format choices

• vision-fallback — click by coordinate when the snapshot can't surface an element

• tabs — multi-tab workflows, peek-without-switching

Snapshot Rules

• Until you snapshot a page, you CANNOT click/type/interact — snapshot first, no exceptions

• NEVER guess, assume, or infer selectors — CSS selectors from your training data are wrong. ONLY use ref= / deep-ref= from latest snapshot

• Snapshot STALE after: click, goto, select, navigation

• Snapshot VALID after: type, hover, scroll, evaluate

• Expect new content? → re-snapshot

• Element roles in snapshot (link, button, textbox, combobox, checkbox, heading) tell you what each does

• Snapshot lines may include desc="...", action=METHOD URL, autocomplete=..., and intent markers (⚠ destructive, ⚠ sign-out, sign-in, reset)

• Before activating or navigating to a control marked ⚠ destructive or ⚠ sign-out, confirm that the action is actually intended; an unlabeled destructive control is a common trap

• Snapshots after the first return a diff vs. your previous snapshot: only + new / ~ changed / - removed elements, plus a count of unchanged ones omitted. Unchanged elements stay valid — keep using their refs from the earlier snapshot. If that earlier snapshot is no longer in your context (summarized/trimmed away), request snapshot { full: true } to get the complete element list again.

Selectors

• Use ref= (CSS) or deep-ref= (starts < ) exactly as shown in snapshot

• Example: [3] button "Sign In" ref=button#submit → "button#submit"

• deep-ref for shadow DOM / iframes — see shadow-dom skill

Iframes

Snapshots include a Frames list (cross-origin iframes) when present. Elements inside a frame are tagged [frame#N] and carry a deep-ref=< *url* css selector that already pierces the frame — pass it as-is to click/type/hover/checkbox. No frame switching needed. captcha/payment widgets (reCAPTCHA, hCaptcha, Stripe, Turnstile) show up here. shadow-dom skill auto-loads when frames present.

Tabs

Snapshots include tabs + activeTargetId — no getTabs needed. Multi-tab / snapshot { targetId } in tabs skill (auto-loads when >1 tab).

Links

Prefer goto over click for links with href — immune to layout shifts, overlays, misclicks. Example: [5] a "About" ref=a[href='/about'] → goto { url: "https://ex.com/about" } Only click when href is javascript: / # / missing.

Content Extraction

1. Check in-memory snapshot (text/values already there)

2. text { selector } — from specific element

3. evaluate { content } — JS (IIFE): (() => { return ... })()

4. html { selector } — raw HTML

Files (upload / download)

To download a file, DRIVE THE BROWSER — do not curl/wget/fetch the file yourself as a first move. Many real downloads (login/cookie-gated, generated server-side on demand, or triggered by a click whose response headers force the download) have NO fetchable URL — a direct fetch silently gets the wrong bytes, an HTML error page, or 403. Click/goto in the agent and collect from the auto-surfaced ledger. The ONLY time a direct fetch is correct: the ledger hands you a URL to use — the single-use /download/<id> URL, or an over-cap sourceUrl. Reaching for curl first is a bug, not a shortcut. NEVER read a file's bytes or base64 into this conversation, and NEVER split/reassemble/inline base64 by hand. That is the wrong tool and will stall.

• Upload a local file (stdio): uploadFile { selector, files: [{ path }] } — the server reads + encodes it only inside the download directory or a directory explicitly allowed by the local operator through BROWSERLESS_UPLOAD_DIRS. Symlink targets must also be inside an allowed directory. Ask the operator about rejected paths; do not bypass the restriction by reading or moving the file yourself.

• Upload a local file (HTTP): the server can't read your disk. Stage it once over HTTP, then use the handle: curl -fsS -F file=@"/path/to/file" "<MCP_BASE_URL>/upload" -H "Authorization: Bearer ${BROWSERLESS_TOKEN:?Set BROWSERLESS_TOKEN locally to the MCP session token}" → returns { "handle": "browserless-download://…" } → uploadFile { files: [{ handle }] }. (The HTTP-mode local-path error supplies this staging command. Configure the same token used for this MCP session locally; never print its value.)

• Re-upload something from getDownloads: pass its handle (works in both modes).

• Download: just trigger it in the agent (click a download link, or goto the file URL). The captured file auto-surfaces as a notification on the agent response (filename/size/handle), never the bytes — the server waits for it to finish (bounded by size), so it usually lands on that same call. stdio: file already saved, you get its path. HTTP: a single-use /download/<id> URL with a curl command using Authorization: Bearer $BROWSERLESS_TOKEN — fetch only if you need it. Use the same token as this MCP session, configured locally; never print its value in the conversation. The command rejects missing tokens and fails on HTTP errors. Files over the cap aren't transferred — you get the source URL to fetch directly. Path/handle reuses in uploadFile. (No separate download tool — use the agent.)

• base64 content is a LAST RESORT — tiny inline data only.

• Full recipe: file-transfers skill.

Batching — Maximize Per Call

Plan ALL actions from snapshot before next snapshot.

Process:

1. Classify actions: safe (type, hover, scroll, evaluate, select, checkbox) vs. page-changing (click, goto)

2. Batch: safe FIRST → page-changing LAST

3. For forms: if submit button is in snapshot, batch type + click in one call

4. Don't batch across navigations

Example form:

{ "commands": [
  { "method": "type", "params": { "selector": "input#email", "text": "j@d.com" } },
  { "method": "click", "params": { "selector": "button#submit" } }
] }

Async

After async triggers (search, submit), use wait* before snapshot — waitForResponse best when API URL known. dynamic-content skill auto-loads on timeout. Never evaluate with setTimeout.

Error Recovery

Errors tagged Category: <NAME>:

• SELECTOR_MISS — re-snapshot; retry < selector if not already deep-ref

• SESSION_LOST — a fresh session was opened automatically; re-goto + snapshot (prior state gone)

• UNAUTHORIZED / FORBIDDEN — pick different path

• NOT_FOUND — different URL

• SERVER_ERROR — backoff, retry once

• NAVIGATION_FAILED — verify URL

• TIMEOUT — longer wait or different signal

• INVALID_PARAMS — fix params (schema authoritative)

• UNKNOWN_METHOD — no such method; pick one from the schema

• SCRIPT_ERROR — your evaluate script threw; page still alive, fix the script

• UNKNOWN — re-snapshot + re-plan

! NOTICE: URL changed cross-origin = prior plan/refs invalid, re-plan. Never retry same failed action without re-snapshot.

Methods (non-obvious)

• goto { url, waitUntil? } — default "domcontentloaded"; prefer over click for links

• snapshot { maxElements?, targetId? } — cap 500; targetId peeks non-active tab

• evaluate { content } — IIFE only

• waitForSelector { selector, timeout? } — set 5000-10000ms

• waitForResponse { url?, statuses?, timeout? } — url is glob "*api/results*"

• createTab { url?, activate?, waitUntil? } — default activate: true; false = background

• loadSecret { ref, selector? } — fills a vault secret server-side (op://<vault>/<item>/<field>, or mail://<vault>/<inbox item>/otp for an emailed code); you never see the value; arms capture protection. Completed top-frame navigation permits a snapshot; backend captures may still need clearSecrets

• saveSecret { title, username, password, website?, vault? } → { ok, ref } or { ok: false, error, vaults? } — needs integrationId on the FIRST call; omit vault unless the result lists several

• clearSecrets {} — lowers capture protection; use only after secret-filled fields are removed, never just after clicking submit. waitForNavigation/waitForResponse/waitForSelector are allowed while armed; response waits do not permit snapshots

• close — own call, NOT batched; only when task complete (premature close discards page state)

• liveURL { timeout?, instructions? } — defaults to 300000ms (five minutes); explicit timeout wins, capped by remaining browser session time. For a human handoff, pass instructions explaining what to do and when to click Done. Set keepSessionAlive: true on the handoff call, reuse the returned sessionId, and close the browser when the overall task finishes. Creating a link does not extend the browser deadline; keeping the browser open remains billed.

• See schema for: screenshot, solve, back, forward, reload, click, type, select, checkbox, hover, scroll, text, html, waitForNavigation, waitForTimeout, waitForRequest, liveURL, getTabs, switchTab, closeTab

Runtime: LOCAL (stdio)

Before any file transfer, know your mode: this server runs over stdio, on the same machine as your files. To UPLOAD a local file, pass its path to uploadFile (files: [{ path }]). The path and any symlink target must be inside the download directory or a directory the local operator explicitly allowed through BROWSERLESS_UPLOAD_DIRS. Ask the operator about rejected paths; do not read or move the file to bypass the restriction. Do NOT base64 the file or read its bytes into the conversation. DOWNLOADS are saved to local disk; the agent response gives you the path.

Repetition self-check

When a tool response contains REPETITION WARNING, re-read your plan and compare your completed steps with the intended progress. Do not repeat the same batch blindly: choose a materially different approach within the task's constraints, or stop and report what is blocked and what you tried. Repetition is a signal to check progress, not proof of failure; continue a repeated action only when you can identify concrete progress or a task-required reason.

Run a Lighthouse performance audit on any URL via the Browserless /performance API. Returns scores and metrics for accessibility, best practices, performance, PWA, and SEO. Optionally filter by category, emulate a mobile or desktop device, supply a custom Lighthouse config, or supply performance budgets. Returns category scores and available Lighthouse lab metrics inline: FCP, LCP, TBT, CLS, Speed Index, initial server response time, and total transfer size. Use these metrics to answer page-speed questions without writing timing scripts. INP is not measured by this navigation audit; TBT is a responsiveness proxy. Saves the full JSON report outside the conversation. Use the local path (stdio) or download URL (HTTP) to inspect only the audits you need. Note: audits can take 30s–120s depending on the site.

Read the Browserless account behind the current API token: plan, unit balance, billing period, and the names of the account API keys. Use it to answer "what plan am I on", "how many units are left", or "which keys exist". Read-only, and never returns API token values.

Read request and unit consumption for the Browserless account behind the current API token: successes, errors, timeouts, queueing, peak concurrency, captchas, proxy bytes and units. Use it to answer "how much have I used" or "why is my bill high". For per-request detail on failures, use browserless_logs instead. Read-only.

Inspect the sessions on the Browserless account behind the current API token: browsers running right now, persistent sessions saved on dedicated workers, recorded session replays, and 1Password credential integrations. Use it to answer "what is running", "did my session survive", or "what got recorded". Read-only — it never stops a session. Action replay downloads one recording and returns a fully self-contained playable rrweb page, needing no network to render: display it inline if you can render HTML, otherwise build an artifact from the returned instructions so the user can watch it. Always show the replay — never just summarise it in words. For MCP Apps clients, action replay returns a viewRef without rendering. Call browserless_show with that exact reference to display the recording; do not read or repeat the recording data.

Read Browserless's own record of the account's recent requests: what was attempted, whether it failed, why it stopped, how long it took and what it cost. This is the tool for diagnosing a run that failed on the Browserless side rather than in your own code. The window available depends on the account plan; the server reports the limit if a range is refused. Read-only.

Scrape a SINGLE webpage and return HTML, markdown, raw DOM text, links, screenshots, or PDFs plus page metadata. Handles JavaScript-heavy pages and anti-bot measures automatically. For content across MULTIPLE pages of a site, use browserless_crawl; to list a site's URLs, use browserless_map.

Execute custom Puppeteer JavaScript code on the Browserless cloud. Your function receives a Puppeteer page object and optional context data. Return { data, type } to control the response payload and Content-Type.

For binary outputs, set type to a real MIME so the bytes come back as a proper content block instead of base64 text:

• image/png / image/jpeg / image/webp → vision content block (~1.5K tokens)

• audio/mpeg / audio/wav → audio content block

• application/pdf and other binaries → resource content block (attachment)

Text responses are capped at 200,000 characters (~50K tokens). Larger text payloads will be rejected — filter or summarize inside your function, or switch to a binary type if you actually meant to return bytes.

Useful for complex scraping, form filling, or any browser automation that requires custom code.

Discover and map all URLs on a website using Browserless. Scans a site via sitemaps and link extraction to find all pages. Returns a list of URLs with optional titles and descriptions. Use the search parameter to order results by relevance to a query. Useful for site audits, content discovery, and building site maps.

Crawl a website and scrape every discovered page using Browserless. Starts from a seed URL and follows links up to a configurable depth. Supports sitemap discovery, path filtering, subdomain handling, and custom scrape options. Returns scraped content (markdown/HTML) for each page along with metadata. Useful for comprehensive site analysis, content extraction, and data gathering.

Create, inspect, or close a live viewer link for an existing browser through REST, without an agent connection. Create options default on the server: view-only, jpeg, quality 70, not resizable, browser interface shown. Link lifetime defaults to 15 minutes, capped by remaining browser session time; creating a link does not keep the browser alive. For a human handoff, pass instructions explaining what to do and when to click Done. Instructions accept a string or an object with layout, format, title, summary, steps, and currentStep. For string instructions use instructionsTitle, steps, currentStep, and instructionsFormat beside instructions. doneLabel, failLabel, and requesterName are always top-level options. Status returns status, reason, interactable, viewerCount, and expiresAt (epoch ms). Ended links remain inspectable until their browser closes; closing an ended link returns not found.

List the authentication profiles saved for the current token. A profile is a saved logged-in browser state (cookies + storage) that can be replayed by passing its name as profile to other tools. Call this before a task that needs the browser to start signed in, to discover which profiles already exist and pick one by name. Returns each profile name plus cookie/origin counts and last-used time.

Search the web using Browserless and optionally scrape each result. Performs web searches via SearXNG and can return results from web, news, or images. Optionally scrape each result URL to get markdown, HTML, links, or screenshots. Useful for research, gathering information, and finding relevant web pages.

Manage the Browserless Stripe Link wallet. Use action "status" to check availability; it never returns a URL. Use "connect" to mint a Stripe-owned authorization URL to give the user, or "disconnect" to remove the connection. When "status" is not_connected, call "connect" to obtain that URL — the status instruction alone has no link. Never ask the user for raw card details.

Create, resume, cancel, or report a Stripe Link checkout in the exact active browser session. Create requires the latest browserless_agent sessionId. Pass payment-field deep selectors whenever a card form is shown, including Stripe-hosted checkout; omit them only for a pure Link Pay Token handoff. Resume retrieves and fills only after Link approval; payment credentials never reach this tool.