What is the difference between a score wall and a challenge wall?

A challenge wall shows you something to solve — a Cloudflare interstitial, a reCAPTCHA v2 checkbox, an hCaptcha, an Arkose puzzle — and can sometimes be cleared in-session. A score wall never shows you anything: reCAPTCHA Enterprise and v3, DataDome, PerimeterX, Kasada, Akamai and Imperva silently judge the session and refuse. No client-side lever reliably passes a score wall, which is why the recommendation for one is a human, not a heavier browser.

Why does it report `withoutAttestation`?

Escalating a run to the stealth fleet spends real money and carries a terms-of-service assertion, so the platform will not do it on its own — it needs `authorized: true`, which is the user’s statement, not the agent’s. `withoutAttestation` shows what this same call resolves to if that attestation is absent, so the difference the attestation makes is stated rather than discovered.

An empty wall means the site is safe to automate?

No — it means no run of yours has been blocked there yet. It is the absence of evidence. Run it and find out; whatever happens is recorded and the next inspect_site knows more than this one did.

Core tool

Ask what a site did last time, before you pay to find out again

The anti-bot wall recorded from your previous runs against a host, whether you already hold a session or a login for it, and the run configuration that history implies — read-only, no browser, no credits.

Get an API key MCP setup

inspect_site

What it is

The job: Decide how to run against a host before the run, using evidence the platform already has.

Every blocked run writes back what blocked it: the anti-bot vendor the engine fingerprinted, the outcome, and a running count, keyed by host. That memory already steered the run route automatically. What it could not do was answer a question asked in advance — so an agent, or a person, rediscovered a known wall by paying for a run that was never going to finish.

inspect_site is that question. It returns `wall` — { class: score | challenge | passive | none, vendor, hits } — plus `auth` (do you hold a session or a stored login for this host?) and a `recommend` block whose `body` field is a fragment you merge straight into your next run_goal call.

The three answers that matter. `connect: true` means the host repeatedly defeats automation with a score-based wall and you have nothing stored — the honest next step is connect_account and a human, not another attempt. `stealth: true` means the wall is the kind the stealth fleet has a real chance against. `proxyType: "mobile"` means the wall weighs IP reputation and carrier egress is the better exit. An empty wall (`class: "none"`) means nothing has been blocked there yet: just run it.

The call

Call it exactly like this.

Copied from the tool's registration and the route handler — not paraphrased.

MCPinspect_site.mcp.jsonjson

// MCP tool call — server "twin-browser"
{
  "tool": "inspect_site",
  "arguments": {
    "host": "app.example.com"
  }
}

GET /api/v1/siterequest.shbash

curl -X GET "https://twin-browser.com/api/v1/site?host=app.example.com" \
  -H "Authorization: Bearer $TWIN_API_KEY"

The wall history is fleet-global and comes from runs that were actually blocked — it is evidence, not prediction. A host with no history is unknown, not safe, and a host that blocked you last month may have changed. `hits` is how much the answer is worth trusting.

Parameters accepted by inspect_site
Parameter	Type	What it does
host*	string	Host or full URL to inspect, e.g. app.example.com or https://app.example.com/login.
account	string	Optional account label — scopes the stored-session and stored-credential answer to one login of several on the host.

Returns

response.jsonjson

{
  "host": "app.example.com",
  "wall": { "class": "score", "vendor": "recaptcha-enterprise:score", "hits": 4, "lastOutcome": "challenged" },
  "auth": { "session": false, "account": true },
  "plan": { "premium": true, "stealthFleet": true },
  "recommend": {
    "stealth": true, "autoStealth": false, "proxyType": "mobile",
    "connect": true, "connectEndpoint": "/api/v1/connect/sessions",
    "withoutAttestation": { "stealth": false, "connect": true },
    "body": { "stealth": true, "authorized": true, "proxyType": "mobile" }
  },
  "reason": "score wall (recaptcha-enterprise:score) on 4 prior runs and no stored session — hand off to a human"
}

What it costs

Free

One indexed read against memory the platform already holds. No browser, no reservation, no charge — it is meant to be callable before every unfamiliar host.

See the full rate card

Which one

When a different tool is the right call.

The honest answer is often the neighbouring tool. These are the trades.

list_catalog

list_catalog answers “can I run this SKILL here?” from the credential side. inspect_site answers “will this HOST let a browser in at all?” from the anti-bot side. They are the two halves of the same pre-flight.

list_catalog

connect_account

inspect_site tells you a connect link is the right move; connect_account mints it. When a run already came back with code:"connect_required", the link is in that response and you need neither call.

connect_account

list_warnings

Warnings are about your own broken logins — a missing credential, a stale session. inspect_site is about the site’s defences, which are not your fault and not yours to fix.

list_warnings

Questions

inspect_site, answered.

What is the difference between a score wall and a challenge wall?: A challenge wall shows you something to solve — a Cloudflare interstitial, a reCAPTCHA v2 checkbox, an hCaptcha, an Arkose puzzle — and can sometimes be cleared in-session. A score wall never shows you anything: reCAPTCHA Enterprise and v3, DataDome, PerimeterX, Kasada, Akamai and Imperva silently judge the session and refuse. No client-side lever reliably passes a score wall, which is why the recommendation for one is a human, not a heavier browser.
Why does it report `withoutAttestation`?: Escalating a run to the stealth fleet spends real money and carries a terms-of-service assertion, so the platform will not do it on its own — it needs `authorized: true`, which is the user’s statement, not the agent’s. `withoutAttestation` shows what this same call resolves to if that attestation is absent, so the difference the attestation makes is stated rather than discovered.
An empty wall means the site is safe to automate?: No — it means no run of yours has been blocked there yet. It is the absence of evidence. Run it and find out; whatever happens is recorded and the next inspect_site knows more than this one did.

Keep going

The rest of the tool set.

run_goal

Do one thing on one site, right now, and block until you know whether it worked.

connect_account

Get logged into a site that an agent is not going to be allowed to log into.

list_catalog

Let an agent plan: pick a skill it can actually run, with values it can actually supply.

list_accounts

Answer “can I get into this site, and as whom?” before starting a run.

The mechanism behind it:Proxy & egress Human-in-the-loop handoff Credential vault

Get an API key All tools