In the space of a week, "agent-ready" got three new public definitions:
- AgentReady.org, launched on 19 October by Ora and Vercel with a committee that includes Mintlify, Auth0, Stripe, Tavily and Elementor. It is a list of requirements with stable IDs and MUST / SHOULD / MAY strengths, and it deliberately has no score.
- Ora's scoring methodology, which turns 126 checks into a 0–100 score across four weighted layers.
- draft-shah-agent-readiness-evaluation-00, an individual Internet-Draft published on 17 October. It proposes four weighted pillars built on existing RFCs. It has no IETF standing.
People now ask us how the Agent Readiness Score (ARS) relates to each of them. This post answers that. It maps all of ARS's checks against the three, explains where our weights come from, and says plainly what we borrowed, what we added and what we haven't proved.
The short version: ARS's layer structure and grade bands come from Ora. What's ours is how a check earns points: only for evidence the scanner observed, with unknowns excluded rather than counted as failures. ARS checks three of AgentReady's four MUSTs and partly checks the fourth, but scores them as ordinary checks rather than gates, and it still gives llms.txt more weight than the evidence supports. We plan to fix both in the next release.
Where Our Weights Come From
When we rebuilt ARS as version 3.0 in September, we took the structure Ora publishes on its methodology page: four layers called Discovery, Access, Usability and Payments, weighted 20 / 30 / 40 / 10, and the same grade cut-offs (A+ from 95, A from 86, B from 70, C from 48, D from 28). We should have said so on our methodology page from the start. As of today, it does.
What ARS changed on top of that structure:
| Ora (as published) | ARS 3.2 |
|---|---|
| One set of weights: 20 / 30 / 40 / 10 | Weights by site type. API, devtool and docs sites: 20 / 30 / 35 / 0 (no Payments layer). E-commerce: 20 / 30 / 40 / 10. Content and media: 20 / 30, with no Usability or Payments layer. |
| Layer score from checks passed | Evidence-only. A check passes only if the scanner observed the evidence. Checks it couldn't verify are left out of the denominator instead of counting as failures. No partial credit. |
| — | Evidence coverage on every scan. Each report shows how many checks were measured, and flags a layer as low-evidence when under half its points could be verified. |
| — | Emerging standards as bonus only. auth.md, WebMCP, legacy SSE and agent payment protocols can raise a score but their absence never lowers it. |
| Grades A+ to F | Same cut-offs |
Ora's page says its checks were derived from runs of real agents, and that only checks agents were seen to rely on count. It doesn't publish the evidence behind each check. ARS doesn't make a comparable claim: our methodology says ARS has not been validated as a predictor of agent task success, and that applies to the weights too. They are a starting point we chose, not a finding.
Conflict of interest. Glintbase sells ARS audits, and Ora is a competitor. Ora's own site also topped our leaderboard (89) when we rescanned it under ARS 3.2 on 13 October.
The Crosswalk: AgentReady.org
AgentReady's v2.0 spec has 24 active requirements across three stages: FIND, READ and ACT. Four are MUSTs, and AgentReady backs the three reading ones with a controlled experiment. They served one docs site in 19 configurations. Only an answer that needs JavaScript (0 of 5 retrievals with a plain fetch) and a 403 to agent user-agents stopped retrieval. Adding llms.txt, JSON-LD, sitemaps or a Markdown mirror made no difference. The experiment measures whether a planted answer was retrieved, not whether a task succeeded, and it covers one site. Its data is published under CC BY 4.0.
The four MUSTs
| AgentReady requirement | What ARS checks | How it's scored |
|---|---|---|
| AR-FIND-01 Agents allowed by robots.txt and bot protection | robots-ai-policy-quality, anti-crawler-challenge-free (challenge markers, cf-mitigated, re-read 403/429/503 bodies) | Weighted, not a gate |
| AR-READ-01 Answer present in the initial HTML | content-no-js | Weighted, not a gate |
| AR-READ-02 Accurate status codes, no soft-404s, 429 rather than a challenge | anti-spa-404 (random-path canary), status-code-accuracy | Weighted, not a gate |
| AR-ACT-10 An MCP server or a CLI | Live MCP probe (handshake, tools/list, schemas, error canary) | MCP only; we don't detect a CLI |
Together, the first three rows carry about 10 of the 85 points an API or docs site can earn, if every check in their layers is verified. So a site that blocks agents or hides its content behind JavaScript can still score well elsewhere. AgentReady's experiment suggests those failures should cap the score, not just cost a few points.
SHOULD and MAY
| Requirement | Strength | ARS |
|---|---|---|
| AR-FIND-02 Answer published as first-party docs | SHOULD | Not checked |
| AR-FIND-03 sitemap.xml referenced from robots.txt | SHOULD | Partly: sitemap present at the root, not whether robots.txt references it |
AR-FIND-04 AI Catalog at /.well-known/ai-catalog.json | MAY | Checked (bonus) |
| AR-READ-03 Homepage as raw HTML with real links | SHOULD | Partly: no-JS content and semantic HTML, not the links |
| AR-READ-04 Docs answer the tasks users bring | SHOULD | Not checked (needs real tasks) |
| AR-READ-05 Code fenced and language-tagged | SHOULD | Partly: balanced fences, not language tags |
| AR-READ-06 Discovery files linked from content | SHOULD | Partly: llms.txt links are fetched; OpenAPI is only found at standard paths |
| AR-READ-07 Ship an llms.txt | SHOULD | Checked: exists, formatting, linked resources resolve |
| AR-READ-08 JSON-LD, with critical facts also in visible text | SHOULD | Partly: JSON-LD presence |
| AR-READ-09 Markdown mirror advertised | MAY | Checked: Accept: text/markdown, .md twins (bonus), Link header |
| AR-READ-11 Pricing on a first-party HTML page | SHOULD | Not checked |
| AR-ACT-01 Auth an agent can complete (RFC 8414 / 9728) | SHOULD | Checked: bearer, scopes, OAuth metadata, WWW-Authenticate |
| AR-ACT-02 OpenAPI contract | SHOULD | Checked: spec found and parsed (JSON; YAML is detected but skipped) |
| AR-ACT-03 MCP over Streamable HTTP | SHOULD | Checked: live probe |
| AR-ACT-04 MCP server card | MAY | Partly: we probe the old /.well-known/mcp/server-card.json path |
| AR-ACT-05 MCP Apps view | MAY | Checked (bonus) |
| AR-ACT-06 SDKs and a CLI | SHOULD | Partly: npm package and SDK docs, no CLI |
| AR-ACT-07 WebMCP tools | SHOULD | Checked (bonus, keyword-based) |
| AR-ACT-08 Agent payments | MAY | Checked: Payments layer, e-commerce only |
AR-ACT-09 NLWeb /ask endpoint | MAY | Not checked |
Overall, ARS checks 12 of the 24 requirements, partly checks 8 and doesn't check 4. The gaps are mostly things a static scan can't judge, such as whether docs actually answer users' tasks.
The Crosswalk: The IETF Draft
The draft scores four pillars with fixed weights, and leaves the per-check weights, bonus sizes and grade bands undefined. Here is how much of an ARS score the nearest equivalent checks carry, for an API or docs site, if every check in their layer is verified:
| Draft pillar | Weight | What it tests | Nearest ARS checks | Share of an ARS score |
|---|---|---|---|---|
| Agent Discoverability | 30% | robots.txt (RFC 9309), describedby Link, RFC 9727 api-catalog | robots policy; api-catalog (bonus). No describedby check. | about 6% |
| Semantic Entity Grounding | 30% | JSON-LD parses, schema.org context, @type, sameAs | JSON-LD presence (1 point); Wikidata claim (bonus) | under 1% |
| Content Efficiency | 25% | text/markdown served, Markdown alternate link | Markdown negotiation, page token budget, text density, Link header | about 3% |
| Transport | 15% | TLS 1.3, Cache-Control, time to first byte | TLS, compression, ETag, Cache-Control, latency | about 3% |
| — | 0% | — | Usability: MCP and OpenAPI, inspected live | 41% |
The biggest difference is what each counts as readiness. The draft scores only what a site serves to a single request. ARS puts 41% of an API site's score on whether an agent can actually operate the product through MCP or an API. AgentReady makes "an MCP server or a CLI" a MUST, which is closer to our view.
On JSON-LD we side with AgentReady's data over the draft's weighting: adding JSON-LD made no difference to retrieval in their experiment, so we keep it at one point.
One thing we're adopting from the draft is its wording. A site whose firewall blocks the scanner is "not observed", not a zero, and must be visibly distinguished from a reachable site. ARS already refuses to score unreachable sites and skips checks behind an unreadable homepage. We'll use the draft's term so reports mean the same thing across tools.
The Crosswalk: Ora
Because ARS inherited Ora's structure, the layers line up one to one:
| Layer | Ora weight (checks) | ARS weight for API / docs (checks) |
|---|---|---|
| Discovery | 20 (16) | 20 (17) |
| Access | 30 (42) | 30 (45) |
| Usability | 40 (62) | 35 (61) |
| Payments | 10 (6) | 0; 10 for e-commerce (6) |
The scores still aren't interchangeable. Ora doesn't say on its methodology page how it treats checks it can't verify, whether it gives partial credit, or whether anything caps a score. ARS excludes unknowns, gives no partial credit, and reports coverage, so the same site can get different numbers from the two tools. When you quote a readiness score, name the tool, version and date it came from.
What the Evidence Says We Got Wrong
Lining ARS up against three other definitions, and against the experiments behind AgentReady, shows three problems with our current weights:
- Blocking failures should be gates. An agent that's blocked, or that gets an answer only after running JavaScript, can't use the rest of a site. Today these failures cost about 10 points of 85. In the next ARS release they will cap the score or appear as blockers.
- llms.txt is overweighted. Its three base checks are worth about 3 of 85 points, more than JSON-LD and nearly as much as all of the draft's Transport pillar. In AgentReady's experiment, adding the file made no difference to retrieval. AgentReady's agent traces show that 86% of llms.txt fetches came from a page that linked to it. We'll stop giving credit for the file merely existing and score whether it's linked and resolves.
- Our server card check looks in the wrong place. The MCP Server Card extension was finalized on 6 October. It puts the card at the MCP endpoint's
/server-cardpath and lists it in/.well-known/ai-catalog.json. The/.well-known/mcp/server-card.jsonpath we probe comes from an earlier draft that the spec now advises against.
We're also adding RFC 9727 api-catalog and describedby discovery for OpenAPI, so specs are found the way the IETF draft and AgentReady expect, not only at fixed paths.
What we're not changing yet is the layer weights. Swapping Ora's 20 / 30 / 40 / 10 for a different set we haven't tested either would be no more defensible. The next step is to test them. Our pre-registered study, State of Agent Readiness Edition 2, will check whether ARS's measured runtime checks predict agent task success better than static discovery signals. We'll publish the result even if it goes against ARS.
Read More
- ARS methodology, with the full check catalog
- AgentReady.org spec and data
- Ora's scoring methodology
- draft-shah-agent-readiness-evaluation-00
- Why we rebuilt ARS around evidence
Figures for AgentReady, Ora and the IETF draft are taken from their published pages and data as read on 22–23 October 2026. The ARS shares assume every check in a layer is verified on the scan. Real scans verify fewer checks, which changes each check's effective weight.
Run a Free AI Readiness Audit
Identify broken parameter signatures, missing Model Context Protocol schemas, and sitemap issues in your developer documentation.
