How the Agent Readiness Index scores an organization
The Index runs 23 checks on an organization's public website and published technical files, and places six test calls to its phone line. The result is a score out of 100 across six areas, and a readiness level from 0 to 5. This page lists every area, check, level gate and call test.
Six areas, 100 points
| Area | Points | Question | What it covers |
|---|
| Discoverability | 15 | Can an agent find and read your pages? | Robots rules for agents, llms.txt, structured data, text that loads without scripts, and sitemaps. |
|---|
| Protocol access | 20 | Can an agent connect to you through MCP or an API? | MCP servers, agent cards, API documentation, data sharing programs and browser tools. |
|---|
| Identity and delegation | 20 | Can a customer give an agent limited access without sharing a password? | OAuth and OpenID metadata, PKCE, client registration, passkeys and delegate access. |
|---|
| Web experience | 15 | Does your site work when an agent uses it? | The sign in page as a declared agent sees it, bot defenses, form labels and page markup. |
|---|
| Voice and IVR | 20 | What happens when an agent calls your phone line? | Six recorded calls to your published number: menus, speech, how it treats an agent, reaching a person and verification. |
|---|
| Policy and governance | 10 | Do your terms allow agents that act for customers? | What your terms say about automated access, third parties, delegates and AI agents. |
|---|
How the score is worked out
Each website area is scored from the points its checks earn, then calibrated with one published curve. The curve keeps zero at zero and 100 at 100, keeps the order of every organization, lifts the middle of the scale and leaves the weakest scores low, so a typical large organization lands near 50 instead of near 30. The voice area is not calibrated. It is scored from the recorded calls only.
A check can pass, partly pass, fail or be unknown. An unknown result, for example when a site blocks the scanner, is left out of the score instead of counted as a failure.
Checks
Discoverability, 15 points
| Check | Points | Why it matters | How to fix it |
|---|
| Robots policy for user triggered agents | 4 | When a customer asks an agent to look something up, it fetches the page as a user triggered agent. A site that blocks those agents cannot be consulted. | Allow the ChatGPT User, Claude User and Perplexity User agents in robots.txt for public product, pricing and help pages. |
|---|
| llms.txt guide for agents | 3 | An llms.txt file gives an agent a short map of what you offer and where the authoritative pages are. | Publish /llms.txt with links to product, pricing, support and location pages. |
|---|
| Structured data on the home page | 3 | Schema.org markup lets an agent read products, prices and questions as data instead of guessing from the layout. | Add JSON LD for your organization type, Product or Service, Offer and FAQPage on the pages customers ask about most. |
|---|
| Content available without running scripts | 3 | Many agents read raw HTML and do not run scripts. Text that appears only after scripts run is invisible to them. | Render product, pricing and help content on the server so the first response contains the text. |
|---|
| Sitemap that includes help and pricing pages | 2 | A sitemap tells an agent where answers live. That cuts wrong guesses and stale pages. | Publish a sitemap that includes help center, pricing and product pages. |
|---|
Protocol access, 20 points
| Check | Points | Why it matters | How to fix it |
|---|
| MCP server | 8 | An MCP server is the native way for an agent to use your services with the customer's approval. It replaces screen scraping and password sharing. | Publish a remote MCP server with OAuth. Start with read only tools such as account status, orders or location search, and publish a server card at /.well known/mcp/server card. |
|---|
| Agent card for agent to agent calls | 2 | An agent card lets other agents discover what your own agent can do and how to authenticate. | Publish /.well known/agent card.json describing skills and authentication. |
|---|
| Public API documentation | 3 | A published OpenAPI document lets developers and agents build against stable, described endpoints. | Publish an OpenAPI document for customer facing APIs on a developer portal. |
|---|
| Developer and data sharing program | 4 | A data sharing program with a developer portal and standard APIs gives agents a consented path to customer data. Open banking is the best known example. | Document the program, the standard in use (for example FDX in US banking), the supported partners and a sandbox. |
|---|
| Browser tools exposed to agents | 3 | WebMCP lets a page register tools that a browser agent can call directly instead of clicking through the interface. | Register tools for safe tasks such as location search and price lookup with navigator.modelContext. |
|---|
| Poppy file for personal agents | Bonus of up to 3 | Poppy is an open draft standard from Sierra and Meta. A company publishes one small file that tells a customer's personal agent how to find it, how the customer signs in and which route to use: the company's own agent, an API or the website. Eight launch partners and dozens of design partners back it. | Publish a poppy.json file in the well known folder of your website. It names your organization, your sign in server and at least one route. Then make your sign in server list your domain in poppy_domains. The standard is a draft, so treat this as early work. |
|---|
Identity and delegation, 20 points
| Check | Points | Why it matters | How to fix it |
|---|
| OAuth and OpenID metadata | 5 | Published authorization server metadata tells a client where to send a customer to approve access. | Publish /.well known/oauth authorization server and /.well known/oauth protected resource for the customer facing APIs. |
|---|
| PKCE and client registration | 4 | PKCE protects the approval step. Dynamic registration or client metadata documents let a new agent onboard without a manual review each time. | Require PKCE with S256 and support client ID metadata documents or dynamic client registration for approved agent clients. |
|---|
| Passkeys at sign in | 4 | A passkey lets a customer approve an agent action with a device gesture. It removes the passwords and one time codes that agents cannot handle. | Offer passkeys with conditional UI on the sign in page and for step up approvals. |
|---|
| High assurance authorization profile | 3 | Pushed authorization requests, sender constrained tokens and rich authorization requests let a provider approve one specific action instead of a blanket login. | Support PAR with DPoP or mutual TLS, and rich authorization requests for payments and account changes. |
|---|
| Documented delegate and data sharing controls | 4 | Customers need a place to see and revoke what an agent can do. Organizations need a documented route for authorized agents. | Publish a help page on delegate access and add a connected apps screen where customers revoke access. |
|---|
Web experience, 15 points
| Check | Points | Why it matters | How to fix it |
|---|
| Home page for a declared agent | 3 | A declared agent that is challenged or blocked at the first step cannot help the customer at all. | Allow declared agents through bot management on public pages, and verify them with signed requests. |
|---|
| Sign in page loads for a declared agent in a browser | 4 | Where a customer must use the website, a browser agent has to reach the sign in page so it can hand control back to the customer. | Serve the sign in page to verified agent browsers, and use signed agent identity to separate them from attackers. |
|---|
| Same behavior for a declared agent and a standard browser | 2 | If a declared agent is treated worse than an anonymous browser, honesty is penalized and agents will hide what they are. | Do not rank declared agents below anonymous browsers in bot management policy. |
|---|
| Sign in form structure and autofill hints | 4 | Labels and autocomplete hints let an agent and a password manager find the right field and hand over to the customer at the right moment. | Label every field and set autocomplete values for the username, the current password and the one time code. |
|---|
| Semantic page structure | 2 | Landmarks, headings and named controls let an agent read the page the way a screen reader does. | Use landmark elements, headings in order, accessible names on buttons and alt text on images. |
|---|
Policy and governance, 10 points
| Check | Points | Why it matters | How to fix it |
|---|
| Terms on automated access | 4 | Terms that prohibit all automated access with no exception make every agent a violation, even when the customer authorized it. | Add an exception for authorized agents acting for the customer through approved interfaces. |
|---|
| Third party access and data sharing rules | 3 | Published rules tell customers and developers what is allowed. That keeps agents on approved paths. | Publish a third party access policy that names the approved interfaces and the consent model. |
|---|
| Published position on AI agents | 3 | A public position tells customers whether an agent acting for them is welcome, and under what conditions. | Publish a page that states how customer agents are handled and where to connect them. |
|---|
Levels
- Level 0, Closed. Declared agents are blocked from the public website. This is the starting point.
- Level 1, Tolerated. Pages load for an agent. Nothing is built for one. To reach it: The home page loads for a declared agent, and robots.txt does not block every agent.
- Level 2, Legible. An agent can read and cite your content. To reach it: One machine readable layer: llms.txt, structured data or content rendered on the server.
- Level 3, Connectable. An agent can connect through an MCP server or a public API program. To reach it: A live MCP server, or a data sharing program with OAuth metadata.
- Level 4, Trusted. A customer can authorize an agent with limited, revocable access. To reach it: OAuth with PKCE, a way to register clients, and documented delegate controls.
- Level 5, Native. Agents are a supported channel on web, API and voice. To reach it: Passkeys, a high assurance profile, and a voice line that scores 70 or more.
Phone call tests
The Voice and IVR area comes from six recorded calls to the number the organization publishes for customer service. Every test stops before any authentication step. The caller always says it is an AI agent when a person answers, and says the call is recorded.
| Test | Group | When | It passes when |
|---|
| V01 Greeting and menu | Reach and understand | Business hours | The line answers within 20 seconds, the menu has six options or fewer, and it finishes in a minute or less. |
|---|
| V02 Plain request | Reach and understand | Business hours | The request is understood on the first or second try. |
|---|
| V03 Assistant framing | Treat an assistant | Business hours | The system continues without error or treats the statement as a valid request. |
|---|
| V04 After hours urgent problem | Treat an assistant | After hours | The line answers, a security or fraud path is reached in under 45 seconds, and a person or a callback is offered. |
|---|
| V05 Reach a person | People and identity | Business hours | A person answers within three minutes and states a process for authorized assistants. |
|---|
| V06 Verification step | People and identity | Business hours | The requirements are clear, no voiceprint is required, and there is another way to verify. |
|---|
What the scan does not see
- Pages behind sign in: The scan never signs in. It cannot judge what a customer sees afterward.
- Private programs: Partner APIs and agreements that are not on public pages are invisible.
- Mobile apps: Only the website and the phone line are tested.
- One moment: A report is a snapshot. Bot defenses and phone menus change.
- One phone number: The calls use the number you publish for customer service. Other lines may behave differently.
- English only: The calls are made in English.
- Documents read: The policy area reads the terms and security pages the scan can reach. Pages that need scripts or sign in are not read.
- Phone variation: Menus, waits and staffing change through the day. One set of calls shows one set of conditions.
- Logos: When a site hides its logo from automated visitors, we ask Wikidata or a public icon service, sending only the public web address or name. A logo can be out of date.