Cloudflare runs a scanner that grades a domain on how ready it is for AI agents. We went through all twenty one of its checks in July: which four were worth implementing, and why eight of the failures were the right answer.
You point it at your site, get a number, and fix what it flags. Then you try to check the version that actually matters — the staging build with the change in it, the site that has not launched, the pages behind a login — and there is nothing to point the scanner at.
That is not a bug in the scanner. It runs in somebody else’s datacenter, so it can only answer
for origins that datacenter can reach. Both failure modes are one curl away, checked
4 August 2026:
$ curl -sS -X POST https://isitagentready.com/api/scan \
-H 'content-type: application/json' -d '{"url":"http://localhost:3000"}'
{"error":"Invalid URL provided"}
$ curl -sS -X POST https://isitagentready.com/api/scan \
-H 'content-type: application/json' -d '{"url":"https://staging.301.sh"}'
{"url":"https://staging.301.sh","scannedAt":"2026-08-04T18:31:38.462Z",
"siteError":{"httpStatus":530,"statusText":"","bodyPreview":null,
"retryAfter":null,"server":"cloudflare"}}A local address is rejected outright. A host the scanner cannot resolve returns a site error instead of a scorecard. Not a low score: no score.
This matters more than it sounds, because of when you want the answer. Taking this site from
Level 1 to Level 5 meant a batch of static files, then a /mcp server, then DNS records, and
every one of those steps was a deploy to production first and a scan second. Publish, then find
out. For a redirect you would never accept that loop.
The other place to run the checks is the browser, which reaches whatever you can reach. This article is about what that changes, what it costs, and the one rule that decides whether the result is worth anything.
What the browser has that the datacenter does not
Three things, and only the first one is obvious.
Reachability. localhost:5173, a staging host behind a VPN, an internal tool, a domain
whose DNS is not public yet. If the tab loads, the audit runs.
A session. Your cookies are attached to the page request, so a site that shows an anonymous visitor a login wall gets graded on what a logged-in client actually receives.
An in-page runtime. Some of what an agent consumes is not an HTTP response at all. WebMCP
exposes tools through document.modelContext inside the page, after scripts run. An HTTP probe
from outside cannot see it; a script in the page can.
The rule that keeps a browser audit honest
The session is also the trap, and it is worth understanding before you write your own script, never mind which tool you use.
An agent readiness audit fetches two very different classes of thing. There is the page, which
may legitimately live behind a login. And there are the machine files — robots.txt, the
sitemap, llms.txt, everything under /.well-known/ — which are public by definition, because
the client reading them has no account and never will.
Send your session to both and you grade a site that nobody but you can see. A /.well-known/
document that only answers for authenticated requests is a document an agent gets a 401 or a
login page from. Passing it in your browser tells you nothing true.
So the split is per request, not per scan:
| What is fetched | Credentials | Why |
|---|---|---|
| The page itself | include |
It may be behind a login, and that is the case the external scanner cannot cover |
Accept: text/markdown on the page |
include |
Same URL, same session, a different representation |
robots.txt, sitemap.xml |
omit |
Public machine files — judge them as a crawler receives them |
llms.txt, llms-full.txt |
omit |
Same |
Everything under /.well-known/ |
omit |
Discovery documents are read by clients with no account |
Redirects follow the same logic. The probe follows hops the way a navigation does, each hop attaching its own cookies, and the response records the final URL. A check that passed on a URL you did not request is a check you want to see the address for.
Two checks that do not survive the trip, and one that only works here
Moving the audit into the browser is not a free upgrade. It trades one set of blind spots for another, and a tool that hides the trade is worse than the gap.
DNS-AID cannot be checked from an extension at all. There is no DNS resolver in the
extension APIs. The _agents SVCB records either exist or they do not, and a browser cannot
ask. Honest output there is “not applicable, run an external scan”, not a guessed fail. This is
the one check where the datacenter scanner is strictly better, and on this site it was
the last one to pass — the resolver cache in front of it took about
forty minutes of rescans after the records were already live.
WebMCP only works here. In-page detection returns one of three answers, and the third one is the point: detected, confirmed absent, or detection unavailable. A browser without the API, or a page where the injected script could not run, produces “unavailable” — not a failure. Not detectable is not the same as not present, and a check that scores those the same way manufactures a defect.
The MCP Server Card needs five addresses. The audit already flagged this, and it has not improved: the draft-canonical path, the IETF one, the two Cloudflare probes and the de-facto legacy file are all in play because the specification moved and the scanners did not move with it. A checker that probes one of them reports the state of that address, not the state of your server.
Where it breaks: the number is not one number
Three separate reasons a score you read today will not match a score somewhere else.
Not-applicable checks leave the denominator. The composite is passing checks over applicable ones, and a check that cannot apply is excluded rather than failed. DNS-AID is always not-applicable in a browser, so the same site is scored against one fewer check there than from outside. Same site, same day, different arithmetic.
Cloudflare’s own two surfaces disagree. On 30 July 2026 this site read 79 of 100 and
Level 5 “Agent-Native” in the web interface, while /api/scan reported Level 4 for the same
domain in the same hour. That is stable, not a glitch we caught mid-deploy, and it means “what
level are we” has two correct answers depending on which endpoint you ask.
The check matrix itself moves. The MCP Server Card above is one example; DNS-AID is
another, resting on an individual Internet-Draft that expires on 28 November 2026, probed
through labels that draft does not define. And llms.txt is not a scored check in either tool:
the audit measures content negotiation, so a site can publish a complete llms.txt surface and
score zero on content accessibility, which is exactly how the July audit opened. What counts as
readiness is being decided while you measure it.
The conclusion is not that the score is worthless. It is that the score is only meaningful against itself. What did this origin do yesterday, and what changed after the last deploy. Comparing your number to another site’s number compares two arithmetics.
The extension
That is what Agent Readiness Inspector does, and shipping it is the occasion for this article. It is our own extension, it runs 22 checks in the browser against whatever origin the current tab is on, and it is free. Firefox and Edge builds are with the stores for review; today the link above is the one that works.
- 22 checks, versioned as data. Robots and AI crawler rules, sitemaps,
Linkheaders, Markdown negotiation, Content Signals, Agent Skills, API Catalog, MCP Server Card, OAuth discovery, Web Bot Auth, WebMCP, plus the agentic commerce protocols as an unscored preview. The matrix carries a version and a CI job watches the upstream one for drift, because the section above is a permanent condition rather than a bad month. - Evidence per check. The response that produced the verdict, including the final URL after redirects, and a copy-ready prompt for the fix.
- Saved sites and regressions. Scheduled rescans, history, and an alert when a check that used to pass stops passing. Alerts land in a local inbox first; the notification permission is optional and asked for only if you turn it on.
- Local-first. Scans, history, settings and alerts live in browser storage. The optional outside comparison uses your own Cloudflare URL Scanner credentials and is off by default.
It is an independent implementation of open web standards, not affiliated with or endorsed by Cloudflare.
Which tool to use
| You need | isitagentready.com | Agent Readiness Inspector |
|---|---|---|
| A public production site | yes | yes |
| Staging, localhost, pre-launch, VPN | no, site error or invalid URL | yes, if the tab loads |
| Pages behind a login | anonymous view only | your session, on the page probes |
| WebMCP in the page | no | yes, in-page detection |
| DNS-AID | yes | no, always not-applicable |
| The score Cloudflare will quote at you | yes, this is the source | no, a second opinion |
| Rescan on a schedule, alert on regression | no | yes, on the machine it is installed on |
Where the extension stops
It audits the origin of the tab you have open, on the machine it is installed on, while the browser is running. Scheduled rescans go through a bounded batch per cycle, so a watch list is a handful of sites you care about, not an inventory. And it cannot answer the DNS question at all.
For getting a site agent-ready before you publish it, that is the whole job, and it costs nothing. The point where it stops is the point where the question changes from “is this site ready” to “are all of them still ready” — every domain in a portfolio, checked on a schedule that does not depend on someone’s laptop being awake, with the alert going to whoever is on call. That is the same boundary the redirect chain recorder runs into, for the same reason, and it is what 301.st does across a portfolio. For the site in front of you, install the extension and read the evidence.