Which specifications does Agent Ready check?
An AI agent discovers and uses a site through a growing stack of conventions — readability files, discovery manifests, and protocol endpoints — and no single standard covers all of it. Agent Ready grades a site against every one of them, the same way a Lighthouse audit spans performance, accessibility, and SEO rather than a single metric. The methodology explains how the checks are scored; this page is the map from each check to the spec it implements.
Entries marked pre-standard are drafts or emerging conventions, and behaviouralentries have no published document at all — we flag both rather than present them as ratified. Protocol (C) checks are reported but unscored for this reason.
Readability
| Specification | Canonical reference | Checks |
|---|---|---|
| Vercel Agent Readability SpecThe core spec for exposing a site to AI agents — discovery files, structured data, clean HTML, and markdown mirrors. Drives most site (S) and every page (P) check. | Canonical specOn agent-ready.dev | S5–S15, P1–P23 |
| llmstxt.orgThe /llms.txt curated-context file (and optional llms-full.txt companion). Structural checks carry 3× weight in the llms.txt sub-score. | Canonical specOn agent-ready.dev | S1–S4, L1–L10 |
Agent protocols
| Specification | Canonical reference | Checks |
|---|---|---|
| MCP Server Cards (SEP-1649)The Model Context Protocol discovery card at /.well-known/mcp.json — its presence (C1) and required fields (C2). | Canonical specOn agent-ready.dev | C1, C2 |
| OAuth Protected Resource Metadata (RFC 9728)Protected-resource metadata an MCP server advertises so agents can locate its authorization server. | Canonical spec | C3 |
| A2A Protocol — Agent CardsThe agent card at /.well-known/agent-card.json that lets agents discover and call other agents — existence with correct Content-Type (C4) and required fields (C5). | Canonical spec | C4, C5 |
| Wildcard agents.jsonpre-standardAn OpenAPI extension declaring which existing REST endpoints agents should call. Pre-standard (v0.1.0). | Canonical specOn agent-ready.dev | C6 |
| agent-permissions.jsonpre-standardA manifest declaring per-path agent access policies, served at /.well-known/agent-permissions.json. No canonical spec document yet — defined by the discovery path. | No published specOn agent-ready.dev | C7 |
| UCP — Unified Capability ProfileA composite profile at /.well-known/ucp bundling OAuth authorization-server metadata with capability declarations. | Canonical specOn agent-ready.dev | C8 |
| OAuth Authorization Server Metadata (RFC 8414)The authorization-server metadata a UCP profile references so agents can complete an OAuth flow. Gated on C8. | Canonical spec | C9 |
Payments
| Specification | Canonical reference | Checks |
|---|---|---|
| x402 — HTTP 402 Payment RequiredA behavioural payments scheme: a paid endpoint answers with HTTP 402 and a JSON body carrying an accepts array — the 402 response (C10) and valid accepts entries (C11). | Canonical specOn agent-ready.dev | C10, C11 |
| MPP — Machine Payments Protocolpre-standardThe Stripe- and Tempo-authored "Payment" HTTP auth scheme on the IETF standards track — the WWW-Authenticate: Payment challenge (C18) and its required params (C19). | Canonical specOn agent-ready.dev | C18, C19 |
Discovery & integrity
| Specification | Canonical reference | Checks |
|---|---|---|
| NLWebAn open natural-language query protocol: a site exposes POST /ask returning Schema.org-typed JSON. Detection is heuristic and informational. | Canonical specOn agent-ready.dev | C12 |
| API Catalog (RFC 9727)A /.well-known/api-catalog linkset advertising a site's APIs so agents can enumerate them from one well-known entry point. | Canonical spec | C13 |
| Web Bot Authpre-standardAn HTTP message-signatures directory at /.well-known/http-message-signatures-directory letting well-behaved bots prove their identity. IETF draft. | Canonical spec | C14 |
| Agent Skills Discoverypre-standardA /.well-known/agent-skills/index.json manifest advertising installable agent skills. Pre-standard (Cloudflare RFC v0.2.0). | Canonical spec | C15 |
| Content parity (anti-cloaking)behaviouralNot a published spec — a behavioural check comparing the AI-bot response to the baseline to detect cloaking (serving agents different content than humans). | No published spec | C16 |
| Agent-driven UI (A2UI)pre-standardMCP-Apps / OpenAI Apps SDK UI surfaces declared on an MCP Server Card, letting agents render interactive widgets inline. Emerging. | Canonical specOn agent-ready.dev | C17 |
Frequently asked questions
- Which specifications does Agent Ready check?
- Agent Ready validates against the Vercel Agent Readability Spec and the llmstxt.org standard (the readability core), plus a layer of agent-protocol specs: MCP Server Cards, A2A agent cards, Wildcard agents.json, agent-permissions.json, UCP, the underlying OAuth metadata RFCs (9728 and 8414), x402 and MPP for payments, and NLWeb, API Catalog (RFC 9727), Web Bot Auth, Agent Skills Discovery, content parity, and Agent-driven UI for discovery and integrity. The 67 checks across the Site, Page, llms.txt, and Protocol series each map to one of these.
- How do checks map to specs?
- Every check is a single function under src/lib/checks/{site,page,llmstxt,protocol}/. Site (S) and Page (P) checks implement the Vercel Agent Readability Spec; the llms.txt (L) series implements llmstxt.org; and each Protocol (C) check implements one agent-protocol spec — for example C1 and C2 cover MCP Server Cards, C10 and C11 cover x402, and C18 and C19 cover MPP. The mapping on this page is generated from the same source the checks are, so it stays in sync.
- Which of these specs are still drafts?
- Several. agents.json (v0.1.0), agent-permissions.json, Web Bot Auth, Agent Skills Discovery, MPP, and Agent-driven UI (A2UI) are pre-standard or emerging — we mark each as such rather than presenting it as ratified. agent-permissions.json and content parity have no published spec document at all: the former is defined by its discovery path, and content parity is a behavioural anti-cloaking check, not a standard. Protocol checks are reported but unscored for this reason.
- Why validate against so many specs?
- AI agents discover and use sites through a growing stack of conventions, and no single standard covers all of it. A site might publish a perfect llms.txt yet expose no MCP card, or ship an agents.json with no payment terms. Checking the full set tells you exactly which agent-facing surfaces are present and which are missing — the same way a Lighthouse audit spans performance, accessibility, and SEO rather than one metric.
- Are the spec links kept up to date?
- Yes. Canonical URLs come from the same data module that drives the scanner's check registry, and a test fails the build if a protocol check exists without a corresponding spec entry. When a spec ratifies or moves, we update one place and the page, its markdown mirror, and the MCP resource all follow.