The open standard for agent readiness

Agents are a new class of user. A growing set of protocols has emerged to serve them (MCP, A2A, x402, llms.txt, Web Bot Auth, and more). What has not emerged is a shared definition of what being ready for them means. Scanners, badges, and readiness grades are already everywhere, and none of them agree.

AgentReady is the first community-driven standard for the agentic web. It is an open specification of the protocols, standards, and conventions a product should implement to be usable by AI agents, from discovery to completion. It does not promote any specific protocol or vendor, and it does not prescribe how builders should score compliance.

The agentic web moves faster than any traditional standards process. AgentReady is designed to keep up: new protocols join the spec as they emerge, tagged emerging while the ecosystem adopts them.

§ conformance

What it means to be AgentReady

A product conforms to AgentReady v1.0.0 when it implements every MUST requirement that applies to its surfaces. It should implement every SHOULD requirement unless it documents a reason not to, and may implement MAY requirements as appropriate.

Each requirement carries two qualifiers. Applicability determines whether the requirement binds the product at all: baseline requirements apply to every agent-addressable product, while conditional requirements apply only when the product exposes their stated surface. Strength then says how firmly the requirement binds within that scope. A conditional MUST requirement has no force for products outside its condition; a docs site is never asked to implement commerce, and a payments API is never asked to publish voice markup.

Commerce is the one section where multiple requirements address the same underlying need through competing protocols. A product that accepts agent payment conforms by implementing at least one applicable Commerce requirement; it is not required to implement them all.

The keywords MUST, SHOULD, and MAY in this document are to be interpreted as described in BCP 14 (RFC 2119, RFC 8174) when, and only when, they appear in all capitals.

§ the spec

Each requirement below points to a published protocol, standard, or convention a product implements directly. Every requirement carries a stable identifier (for example AR-DISC-01) preserved across revisions, an applicability scope, and a normative strength. A machine-readable version of the spec is available at /spec.json.

Discoverability

Help agents find the product and the files they need to read.

AR-DISC-01·MUST

robots.txt with AI policyRFC 9309

Declare which AI crawlers are allowed. A robots.txt that distinguishes GPTBot, ClaudeBot, Google-Extended, PerplexityBot, and other identified agents from broad training crawlers gives agents a clear signal about intent.

AR-DISC-02·SHOULD

Sitemapsitemaps.org

A /sitemap.xml lets agents list the site's main URLs without crawling every page.

AR-DISC-03·SHOULD

llms.txtllmstxt.org

A markdown index at the site root that summarizes the product and links to the documents agents should read first.

AR-DISC-04·MAY

llms-full.txtllmstxt.org

A single-file, ingestible version of the product documentation that fits into an agent context window in one request.

AR-DISC-06·MAY

NLWeb schema feedsemergingnlweb.ai

A schemamap directive in robots.txt pointing to a structured feed that describes site content in schema.org vocabulary for natural-language retrieval.

applies to: Products that offer search or natural-language retrieval

Content for agents

Expose content in a form models can parse without running JavaScript.

AR-CONT-01·SHOULD

JSON-LD structured dataschema.org

Embed schema.org types such as Product, Organization, Offer, SoftwareApplication, and FAQPage as JSON-LD so models can read entity and product facts directly.

AR-CONT-02·MAY

Markdown content negotiationemerging

Respond to Accept: text/markdown with a markdown representation of the page, giving agents a cleaner and more token-efficient view of the same content.

AR-CONT-03·MAY

/index.md fallbackemerging

A markdown version of the homepage served at /index.md, so the primary product page is directly fetchable as plain text.

AR-CONT-04·MAY

Speakable content markupschema.org

Mark portions of a page as suitable to be read aloud by voice agents using schema.org/SpeakableSpecification.

applies to: Products with content meant to be consumed by voice agents

Capabilities

Declare what the product can do for agents and how to call it.

AR-CAPA-01·MUST

Model Context Protocol (MCP)modelcontextprotocol.io

An open JSON-RPC protocol for exposing tools, resources, and prompts to agents over Streamable HTTP or stdio.

applies to: Products that expose tools or resources to agents

AR-CAPA-04·MUST

A2A Agent CardA2A v1.0

A /.well-known/agent-card.json descriptor used for agent-to-agent discovery under the A2A protocol. The Agent Card declares identity, service endpoints, supported interfaces, skills, and security schemes.

applies to: Products that expose an agent-to-agent surface

AR-CAPA-08·MUST

OpenAPIOpenAPI 3.1

A machine-readable description of HTTP APIs. Function-calling agents use OpenAPI to understand paths, parameters, schemas, and errors.

applies to: Products that expose an HTTP API

AR-CAPA-02·SHOULD

MCP Server CardemergingSEP-2127

A /.well-known/mcp/server-card.json document describing a server's name, version, transport, capabilities, authentication, and tool surface for pre-connection discovery.

applies to: Products that expose an MCP server over HTTP

AR-CAPA-03·MAY

MCP Appsmodelcontextprotocol/ext-apps

The MCP extension for ui:// resources (io.modelcontextprotocol/ui), letting servers return renderable HTML that hosts can embed in sandboxed iframes for confirmation, payment, or generative-UI handoffs.

applies to: MCP servers that return renderable UI

AR-CAPA-05·MAY

WebMCPemergingW3C WICG

A browser API (navigator.modelContext) and HTML-native tool metadata that let pages expose actions as MCP-style tools to in-page agents.

applies to: Products whose pages expose in-page actions to agents

AR-CAPA-06·MAY

NLWeb /ask endpointemergingnlweb.ai

A natural-language query endpoint that returns structured schema.org responses, designed to make any site conversational. NLWeb instances also act as MCP servers.

applies to: Products that offer natural-language retrieval

AR-CAPA-07·MAY

Agent Skillsagentskills.io

SKILL.md files packaging discrete, portable agent capabilities as YAML frontmatter plus markdown instructions, with optional scripts, references, and assets.

applies to: Products that ship agent-invokable skills

AR-CAPA-09·MAY

ai-plugin.jsonemerging

A /.well-known/ai-plugin.json manifest originally introduced for ChatGPT plugins and still used as a lightweight capability descriptor.

applies to: Products that expose a plugin-style capability

Identity & Access

Prove who the agent is and give it scoped, revocable access.

AR-IDEN-02·MUST

OAuth 2.0RFC 6749

The foundation for delegated, scoped access. Publish authorization and token endpoints agents can discover.

applies to: Products with user-owned resources or delegated access

AR-IDEN-03·MUST

OAuth Authorization Server MetadataRFC 8414

A /.well-known/oauth-authorization-server or /.well-known/openid-configuration document exposing issuer, endpoints, and supported scopes.

applies to: Products that run an OAuth authorization server

AR-IDEN-05·MUST

PKCERFC 7636

Proof Key for Code Exchange with S256. The secure pattern for native and agent OAuth flows that cannot hold a client secret.

applies to: Products that accept public or agent OAuth clients

AR-IDEN-01·SHOULD

Web Bot Authemergingdraft-meunier-web-bot-auth / RFC 9421

HTTP message signatures over agent requests, with a /.well-known/http-message-signatures-directory publishing the public keys an agent operator signs with. Servers verify signatures to distinguish identified agents from unattributed traffic.

AR-IDEN-04·SHOULD

OAuth Protected ResourceRFC 9728

A /.well-known/oauth-protected-resource document declaring which authorization servers a resource trusts, plus supported scopes and bearer methods.

applies to: Products that expose OAuth-protected resources

AR-IDEN-06·MAY

API CatalogRFC 9727

A /.well-known/api-catalog linkset describing a site's public APIs and pointing agents to OpenAPI, AsyncAPI, or other descriptors.

applies to: Products that expose one or more public APIs

Commerce

Let agents pay, initiate checkouts, and complete purchases on behalf of their users. The requirements in this section are alternative, interoperating approaches; a conformant commerce product implements at least one.

AR-COMM-01·MAY

x402x402.org

An HTTP-native payment protocol built on the 402 Payment Required status code for inline stablecoin settlement of API calls.

applies to: Products that charge for API calls or resources

AR-COMM-02·MAY

Agentic Commerce Protocol (ACP)emergingagentic-commerce-protocol

OpenAPI-backed checkout sessions that let agents drive standard e-commerce flows end to end. Maintained by OpenAI and Stripe, used by ChatGPT Instant Checkout.

applies to: Products that accept agent-driven checkout

AR-COMM-03·MAY

ACP Delegate Paymentemergingagentic-commerce-protocol

A companion flow for shared payment tokens, letting an agent pay on a user's behalf with a short-lived, cart-scoped token.

applies to: Payment providers that issue delegated tokens to agents

AR-COMM-04·MAY

Universal Commerce Protocol (UCP)emergingucp.dev

A /.well-known/ucp profile declaring services, capabilities, and payment handlers, plus an agent profile URL for two-sided capability negotiation. Co-developed by Shopify and Google.

applies to: Products that expose agent-driven commerce

AR-COMM-05·MAY

Machine Payments Protocol (MPP)emergingmpp.dev

An HTTP 402 + Payment authentication scheme with an OpenAPI x-payment-info extension for per-call API monetization. Submitted to the IETF as draft-httpauth-payment.

applies to: Products that monetize APIs at the call level

§ official deep scan

Check your readiness

Deep Scan by Ora is the official AgentReady scanner. It is a free, public implementation that evaluates any site against the current spec and reports per-requirement results using the stable identifiers above.

The spec defines what agent readiness means; Deep Scan provides the canonical way to measure it. Other implementations are welcome and encouraged.

§ versioning

How the spec changes

AgentReady follows semantic versioning applied to normative commitments, not to editorial text. A MAJOR bump happens when an existing requirement changes its strength to a stricter level, when a requirement is removed, or when a stable ID is reassigned. A MINOR bump happens when a requirement is added, when a strength becomes looser, or when a reference is updated. A PATCH bump covers clarifications and link fixes.

Stable identifiers (AR-SECT-NN) are preserved across versions and are the canonical way to cite a requirement. The machine-readable form of the current version is available at /spec.json.

§ provenance

Where this comes from

AgentReady is currently maintained by a small group of contributors and is not ratified by a standards body. It is an open, MIT-licensed working specification — anyone can read, fork, implement, or propose changes to it.

The intent is for governance to broaden as the spec matures. As independent implementations and contributors accumulate, the project will move toward a documented multi-maintainer governance model. Until then, treat AgentReady as an opinionated community specification with the structural shape of a standard.

contribute

AgentReady is developed in the open. The spec and this site live on GitHub. Discussion, proposals, and builder conversations happen on Discord. New requirements join the spec as emerging so adoption can be observed before they stabilize.

MIT · revised as protocols emerge