The API, and the same tools for an agent

Everything on this site is a plain HTTP call you can make yourself, and the same verbs are available to a coding agent through one MCP bridge command. Looking things up needs no account; acting on the network does.

Public reads, owned actions

Your own address and a DNS lookup are open, because they cost nothing and refusing them would only push people to a worse answer elsewhere. Scanning and scraping past the preview require a session or an API key, because those spend our egress and have to be attributable.

What a refusal looks like

A blocked target is a 403 naming the rule that blocked it. An exhausted quota is a 402 carrying the limit and the count. A bad argument is a 400 naming the field. None of them is a bare sentence, because a refusal a program cannot act on is a refusal that turns into a retry loop.

The rate limits are per account

Everything here sits behind a proxy the whole platform shares, so a per-address bound would be a platform-wide bound the first busy hour exhausts. Limits attach to your account and to the target, which is also the only shape that means anything for a tool like this.

Questions

Why do I have to sign in to run a scan?

Because an abuse report has to reach somebody. A scan that cannot be attributed to an account cannot be answered for, cannot be rate-limited meaningfully, and cannot be stopped by suspending anything. There is deliberately no anonymous allowance.

What will you refuse to scan?

Private, loopback and link-local ranges, the cloud metadata address, our own infrastructure, and anything on the denylist. Those refusals are not configurable by a customer, and a range larger than the per-scan cap is refused before any packet is sent.

Do you store what I look up?

A lookup is answered and not kept against you. A scan is kept — the account, the target, the time and the authorisation statement — because that record is what an abuse report is answered with, and keeping it is the condition of offering the feature at all.