The AgentDrives Standard.

74 things an AI agent needs from a software product to use it on its own, from reading the docs to deleting the account. Each says what good looks like and how to get there.

Draft v0.9Dated 25 Oct 202674 criteria22 measured in every driveCC BY 4.0MarkdownJSON

Classes

Core: An agent can't do the work without it.
Recommended: An agent works faster and makes fewer mistakes with it.
Advanced: Newer standards an agent uses where they exist.

Status

Measured in every drive: Every drive records it.
Partly measured: Drives record part of it.
Not measured yet: In the standard, not yet in our drives.

Find 6
Docs 10
Get in 10
API 9
MCP 11
CLI and SDKs 3
Errors 7
Limits 4
Pay 6
Leave 4
Agent protocols 4

Find.

An agent reads about your product before it uses it.

FIND-01

Agents may read docs, API and sign-up

CoreMeasured in every drive

robots.txt and bot rules let a declared agent read docs, the API reference and the sign-up page.

Why: An agent that robots.txt or a bot rule turns away never reads a page about your product.
To fix: Allow declared AI agents on your docs, API reference and sign-up page in robots.txt and your bot rules.

FIND-02

llms.txt that works

RecommendedPartly measured

Valid llms.txt (H1, summary, sections of links), links resolve, under 50k characters, linked from doc pages.

Why: One short file tells an agent where everything is, without crawling the site.
To fix: Publish /llms.txt with a title, a summary and sections of working links, under 50k characters.

FIND-03

Markdown twins of doc pages

RecommendedPartly measured

Each doc page has a Markdown version (.md URL or Accept: text/markdown with Vary: Accept) with the same content.

Why: An agent reads Markdown best. The same page as HTML costs it many times the tokens.
To fix: Serve each doc page as Markdown at a .md URL, or on Accept: text/markdown with Vary: Accept.

FIND-04

OpenAPI an agent can find

CorePartly measured

An OpenAPI document at a stable public URL, linked from the docs, or listed in /.well-known/api-catalog (RFC 9727).

Why: With the spec an agent knows every call without guessing from prose.
To fix: Put your OpenAPI file at a stable URL, link it from the docs and list it in /.well-known/api-catalog.

FIND-05

MCP server an agent can find

RecommendedPartly measured

The MCP URL, transport and sign-in are on one docs page and in a server card or the MCP registry.

Why: An agent can only connect to an MCP server when it knows the address and how to sign in.
To fix: Put the MCP URL, transport and sign-in on one docs page, and publish a server card or a registry entry.

FIND-06

Prices an agent can read

RecommendedMeasured in every drive

Plan names, prices, units, limits and overage are in page text (not images or script only), ideally also as JSON.

Why: An agent choosing a product for someone compares prices. A price inside an image is no price to it.
To fix: Write each plan's price, unit, limits and overage as page text, and offer the same as JSON.
How we grade it: The pricing page's text without script: pass when it names prices, what each is per and a plan (or the resource, for usage pricing); partly when one is missing; fail when no price is in the text. JSON pricing is noted.

Docs.

What an agent reads to make its first call, then real work.

DOCS-01

A quickstart that gets to the first call

CorePartly measured

One page from zero to a first working call: credential, one complete request, the expected answer.

Why: The first call is where agents give up most. One page that gets there saves the most attempts.
To fix: Write one page from no account to a first working call, with the full request and the answer.

DOCS-02

Sign-in documented for software

CorePartly measured

How to get a credential without a browser, its scopes, its lifetime and how to revoke it.

Why: Without it an agent tries a browser login it can't finish.
To fix: Document how software gets a credential, its scopes, how long it lasts and how to revoke it.

DOCS-03

Error reference

RecommendedPartly measured

Every error code listed with its meaning and the fix.

Why: An agent fixes an error fast when it can look the code up.
To fix: List every error code with what it means and how to fix it.

DOCS-04

A page for each core task

CoreMeasured in every drive

Each core capability has its own page or reference entry.

Why: An agent looks for the task it was given, not for how your docs are organised.
To fix: Give each core task its own page or reference entry.

DOCS-05

Examples that run as written

RecommendedPartly measured

Core pages carry complete examples (imports, auth, real field names) that run unchanged.

Why: Agents copy examples. One wrong field name costs a round of errors.
To fix: Make every example complete, with imports, auth and real field names, and test that it runs.

DOCS-06

Docs match what the product does

CorePartly measured

Documented calls behave as documented.

Why: An agent trusts the docs. When a call does something else, it's stuck.
To fix: Test the documented calls against the live product and fix whichever side is wrong.

DOCS-07

Docs cover the whole surface

RecommendedPartly measured

Everything the product does over API, MCP or CLI is documented. Nothing works only undocumented.

Why: An agent only uses what it can read about.
To fix: Document every call your API, MCP server and CLI accept.

DOCS-08

Pages fit one fetch

RecommendedPartly measured

Markdown under 50k characters. Content not hidden behind script, tabs or late in the page.

Why: Agents read a page in one fetch. What sits behind a tab or a script, they never see.
To fix: Keep each page's Markdown under 50k characters, with its content in the page itself.
How we grade it: Each docs page we read is sized as text: over 50,000 characters is too big for one fetch. A page with under 30 words before script runs and 150 or more after it hides its content. Pass: no page flagged; fail: more than half.

DOCS-09

Dated changes

RecommendedPartly measured

A dated changelog, the API version on each reference page, deprecations announced with dates.

Why: An agent working from older docs needs to see what changed and when.
To fix: Keep a dated changelog, show the API version on reference pages and date every deprecation.

DOCS-10

A path written for agents

AdvancedNot measured yet

A page or llms.txt section that tells an agent which way in, which surface, and which limits apply to it.

Why: An agent starts faster when the docs say which way in is meant for it.
To fix: Add a page or llms.txt section for agents: the way in, the surface to use and its limits.

Get in.

An account and a credential without a person.

IN-01

A way in with no person

CoreMeasured in every drive

At least one route gets an agent working without a person: key by API, pay per call, keyless, or a sign-up it can finish.

Why: If every way in needs a person, an agent working alone stops at the door.
To fix: Offer one way in an agent can finish on its own: a key by API, pay per call, no key, or a sign-up without a person.

IN-02

The best route exists and works

RecommendedPartly measured

The most agent-native route the product's model allows is offered: a key from one API call (limited until a person claims it) or a paid call. OAuth only where a person's data is at stake.

Why: The shorter the way in, the more agents reach the first call.
To fix: Offer a key from one API call, limited until a person claims it, or a paid call. Keep OAuth for a person's data.

IN-03

Fast to the first call

RecommendedPartly measured

First working call within minutes and a few calls.

Why: Every extra step is a place where an agent can stop.
To fix: Cut the path to a first call down to a few calls and a few minutes.

IN-04

Signed agents get past the bot check

CoreMeasured in every drive

A verified or signed agent (Web Bot Auth) is not challenged on sign-up, login and API paths.

Why: A signed agent has told you who it is. A challenge stops it anyway.
To fix: Let verified and signed agents (Web Bot Auth) through on sign-up, login and API paths.

IN-05

No phone, card or ID at step one

RecommendedPartly measured

Sign-up asks only for what an agent has: an inbox, or nothing.

Why: An agent has an inbox. It has no phone, card or passport.
To fix: Ask only for an email address at sign-up, or nothing.

IN-06

Keys an agent can manage

RecommendedPartly measured

Keys can be made, scoped, listed and revoked by API. They expire or rotate, and a prefix shows what they are.

Why: An agent that can't list or revoke its own keys leaves old ones behind.
To fix: Let keys be made, scoped, listed and revoked by API, with an expiry and a prefix that says what they are.

IN-07

MCP and OAuth sign-in set up to spec

RecommendedPartly measured

401 with WWW-Authenticate resource_metadata. RFC 9728 and RFC 8414 metadata valid. CIMD or DCR. PKCE S256. Consent finishes without a lost browser step.

Why: MCP clients sign in by the spec. A missing header or metadata file stops them.
To fix: Answer 401 with WWW-Authenticate resource_metadata, publish valid RFC 9728 and RFC 8414 metadata, and support PKCE S256 with CIMD or DCR.

IN-08

Sign-in for agents acting for a person

AdvancedNot measured yet

Where a person's data is at stake: device flow (RFC 8628) or a back-channel approval, so the agent never needs to drive a browser.

Why: An agent acting for a person needs that person's yes without driving a browser.
To fix: Support the device flow (RFC 8628) or a back-channel approval.

IN-09

A person can claim what the agent made

RecommendedNot measured yet

An agent-made account comes with a claim link for its person and clear limits until then.

Why: The person behind the agent must be able to take the account over.
To fix: Give every agent-made account a claim link for its person, and state its limits until then.

IN-10

Terms allow an agent's account

CoreMeasured in every drive

Terms don't ban accounts or sign-ups made by software.

Why: Terms that ban software sign-ups make every agent's account a breach.
To fix: Allow accounts made by software in your terms.

API.

Calls an agent can build from the spec and retry safely.

API-01

OpenAPI that lints clean

RecommendedPartly measured

OpenAPI 3.1 (or 3.0) that validates. Every operation has a unique operationId, a description, success and error responses, and examples.

Why: Tools and agents load a clean spec without errors.
To fix: Validate the OpenAPI file and give every operation an operationId, a description, responses and examples.

API-02

The spec matches the live API

CorePartly measured

Live calls match the spec: paths, fields, status codes.

Why: An agent builds its calls from the spec. A wrong field fails the call.
To fix: Test the live API against the spec and fix whichever side is wrong.

API-03

One way to page through lists

RecommendedPartly measured

Every list has a limit with a documented maximum and a cursor with an explicit next or has_more.

Why: One paging style lets an agent read every list the same way.
To fix: Give every list a limit with a documented maximum, a cursor and an explicit next or has_more.
How we grade it: Each list endpoint in the API spec (a GET that returns a list) takes a cursor, page or limit parameter. Every one passes, under half fails, anything between is partly. Whether answers say next or has_more isn't checked yet.

API-04

Answers sized for an agent

RecommendedPartly measured

Core reads return what the task needs. Fields can be chosen or expanded. No unbounded lists.

Why: Large answers fill an agent's context and push out the task.
To fix: Let callers choose or expand fields, and bound every list.
How we grade it: Each limit parameter on a list endpoint in the API spec has a maximum or a default. Every one passes, under half fails, anything between is partly. Field choice and real answer sizes aren't checked yet.

API-05

Writes answer with the object

RecommendedPartly measured

A create or update returns the stored object and its id, and it is readable at once.

Why: An agent needs the id to carry on, without a second read.
To fix: Return the stored object and its id from every create and update.

API-06

Retries are safe

CoreMeasured in every drive

Creates accept an Idempotency-Key: a retry replays the first answer and a changed body is refused.

Why: Agents retry after timeouts. Without a key, a retry makes a second order.
To fix: Accept an Idempotency-Key on creates: replay the first answer and refuse a changed body.

API-07

Versions an agent can pin

AdvancedPartly measured

A version can be pinned (header or path). Deprecations come with Deprecation and Sunset headers.

Why: A pinned version keeps an agent working while the API moves on.
To fix: Let callers pin a version by header or path, and send Deprecation and Sunset headers.
How we grade it: The API spec lets callers pin a version (in the path, the server URL or a header) and shows how changes are announced: deprecated marks, Deprecation or Sunset headers, or a changelog. Both pass, one is partly, neither fails. Headers on real answers aren't checked yet.

API-08

Long work has a status

RecommendedPartly measured

Long jobs return a status URL or id. Webhooks or events report the end.

Why: An agent can't hold a connection open for a long job.
To fix: Return a status URL or id for long jobs, and report the end by webhook or event.

API-09

A sandbox or test mode

RecommendedMeasured in every drive

The agent can try the core without real money or real messages.

Why: An agent learns by trying. A sandbox lets it try without spending money or messaging people.
To fix: Offer a test mode or sandbox that covers the core.

MCP.

A server an agent can connect to and pick the right tools from.

MCP-01

Remote MCP on the current spec

CorePartly measured

A remote Streamable HTTP endpoint on the current protocol version, where initialize works.

Why: Hosted agents connect over Streamable HTTP. A local-only or old server leaves them out.
To fix: Run a remote MCP endpoint on Streamable HTTP and the current protocol version.

MCP-02

The core is reachable over MCP

CorePartly measured

Each core capability has a tool.

Why: An agent on MCP can only do what there is a tool for.
To fix: Add a tool for each core capability.

MCP-03

Tool names that sort themselves

RecommendedMeasured in every drive

Names valid (1 to 128 characters of A-Z, a-z, 0-9, _, - and .), unique, in one consistent pattern (verb_noun or service_resource_verb).

Why: Clear names in one pattern help a model find the right tool in a long list.
To fix: Use valid, unique names in one pattern, such as verb_noun.
How we grade it: Each name is 1 to 128 of A-Z, a-z, 0-9, _, - and ., used once, and all names follow one pattern such as snake_case.

MCP-04

Descriptions that say when to use the tool

RecommendedMeasured in every drive

Each description states its purpose, when to use it and when not, key parameters and limits, at a sensible length.

Why: The model picks a tool from its description alone.
To fix: Say in each description what the tool does, when to use it and when not, its key parameters and its limits.
How we grade it: Each description is scored on four things: 40 to 1,500 characters, says what the tool does, says when to use it, names a parameter or limit. A tool meets it with three of the four.

MCP-05

Agents pick the right tool

RecommendedNot measured yet

Different models choose the right tool for plain-language tasks.

Why: A tool picked wrongly is a task done wrongly.
To fix: Test plain-language tasks on several models and rewrite the descriptions they get wrong.

MCP-06

Typed, tight input schemas

RecommendedMeasured in every drive

Every parameter typed and described, required ones listed, enums where values are fixed, and no-argument tools reject extra fields.

Why: Tight schemas stop bad calls before they run.
To fix: Type and describe every parameter, list the required ones, use enums and reject extra fields.
How we grade it: Every parameter has a type and a description, required ones are listed, fixed values are an enum, and a tool without arguments refuses extra fields.

MCP-07

Truthful annotations

RecommendedPartly measured

readOnlyHint, destructiveHint and idempotentHint set. A tool marked read-only changes nothing.

Why: Clients use these hints to decide what runs without asking.
To fix: Set readOnlyHint, destructiveHint and idempotentHint on every tool, and keep them true.
How we grade it: Every tool sets readOnlyHint, and a tool that changes data also sets destructiveHint and idempotentHint. Whether the hints are true isn't checked yet.

MCP-08

Structured results

RecommendedPartly measured

Data tools declare outputSchema and return structuredContent that matches it, with the same as text.

Why: Structured results let an agent use the data without parsing text.
To fix: Declare outputSchema on data tools and return matching structuredContent, with the same in text.
How we grade it: Each result the drive got back is structured (structuredContent that fits the tool's outputSchema), JSON text or plain prose. Every tool structured passes, more than half prose fails, anything between is partly. Whether the text repeats the same data isn't checked yet.

MCP-09

Results sized for a context window

RecommendedPartly measured

List and search tools take limit and cursor, and truncate with a hint on what to narrow. Tool results stay small.

Why: One huge result can fill an agent's whole context.
To fix: Give list and search tools a limit and a cursor, and truncate with a hint on how to narrow.
How we grade it: Each tool's biggest result in tokens (characters divided by 4): under 5,000 passes, 5,000 to 25,000 is partly, over 25,000 fails. We note whether a big result pages or says it was cut, but don't grade it yet.

MCP-10

Tool errors come back as results

CorePartly measured

Bad input and business errors return isError with what to fix. An unknown tool is a protocol error. One tool needing auth does not break the connection.

Why: An agent reads an error result and tries again. A broken connection ends its session.
To fix: Return bad input and business errors as isError results that say what to fix.

MCP-11

A tool list that fits

AdvancedMeasured in every drive

Tool definitions cost few tokens. Large servers load toolsets on demand.

Why: Every tool definition takes context before any work starts.
To fix: Keep tool definitions short, and load large toolsets on demand.
How we grade it: The whole tool list in tokens (characters divided by 4): under 10,000 passes, 10,000 to 30,000 is partly, over 30,000 fails.

CLI and SDKs.

Commands and libraries that run with nobody at the keyboard.

CLI-01

A CLI that never waits for a person

RecommendedPartly measured

Every command runs with flags or env, emits JSON on request and exits non-zero on failure.

Why: An agent can't answer a prompt in a terminal.
To fix: Make every command run from flags or env, print JSON on request and exit non-zero on failure.

CLI-02

CLI sign-in without a browser

RecommendedPartly measured

A token from env or a flag works. Browser login is optional.

Why: An agent on a server has no browser to log in with.
To fix: Accept a token from env or a flag, and keep browser login optional.

CLI-03

Official SDKs that match the API

AdvancedPartly measured

Typed SDKs in the main languages, current with the API version.

Why: Agents write code with your SDK. An old one writes wrong calls.
To fix: Publish typed SDKs in the main languages and release them with each API version.

Errors.

Errors an agent can read, fix and get past.

ERR-01

Real status codes

CorePartly measured

Errors use 4xx and 5xx codes, never a 200 with an error inside.

Why: An agent checks the status code first. A 200 with an error inside looks like success.
To fix: Answer every error with a 4xx or 5xx code.

ERR-02

Errors a program can read

CorePartly measured

A stable machine code plus a message in a documented shape (RFC 9457 or your own documented format).

Why: A stable code lets an agent handle an error without reading prose.
To fix: Return a stable error code and a message in one documented shape, such as RFC 9457.

ERR-03

Errors say what to do next

CorePartly measured

The error names the field, the allowed values or the next step (a fix or a docs link).

Why: An error that names the fix gets fixed on the next try.
To fix: Name the field, the allowed values or the next step in each error, with a docs link.

ERR-04

All validation problems at once

RecommendedNot measured yet

A bad request lists every invalid field, not only the first.

Why: One problem per answer turns one fix into many round trips.
To fix: Return every invalid field in one answer.

ERR-05

The agent recovers

CoreMeasured in every drive

After an error the corrected retry succeeds within a few attempts.

Why: Every agent makes mistakes. What counts is that it gets back on track.
To fix: Make errors precise enough that a corrected retry works within a few tries.

ERR-06

Auth errors that tell the cases apart

RecommendedPartly measured

Missing, invalid, expired and under-scoped credentials answer differently (401 or 403, WWW-Authenticate, the scope named).

Why: Each case has its own fix: a new key, a refresh or a wider scope.
To fix: Answer missing, invalid, expired and under-scoped credentials differently, and name the scope needed.

ERR-07

A request id on every answer

AdvancedPartly measured

Every response carries a request id the owner's support can trace.

Why: With an id, the person behind the agent can trace a call with your support.
To fix: Send a request id on every response.
How we grade it: Every error answer from the API the drive called carries a request or trace id, in a header or the body. Cloudflare's cf-ray doesn't count. Every error with one passes, none fails, some is partly. Successful answers aren't checked yet.

Limits.

Rate and plan limits an agent can see and keep to.

LIM-01

Rate limits an agent can obey

CoreMeasured in every drive

A limit answers 429 with Retry-After (and RateLimit and RateLimit-Policy headers), never 200 or 500.

Why: An agent that knows when to retry waits. One that doesn't keeps hitting you.
To fix: Answer 429 with Retry-After, and RateLimit and RateLimit-Policy headers.

LIM-02

Limits known before they hit

RecommendedPartly measured

Limits per plan are published and current usage is readable (headers or a usage route).

Why: An agent plans its work around limits it can see.
To fix: Publish the limits per plan and make current usage readable by header or route.
How we grade it: The API's answers to the drive's own calls carry rate-limit headers (RateLimit or X-RateLimit), and every 429 or 503 says when to retry. Headers on at least half the answers, with a retry time on every 429 or 503, passes. No header and no retry time fails. Anything between is partly. Published limits per plan and usage routes aren't checked yet.

LIM-03

Plan gates that explain themselves

RecommendedPartly measured

A plan-gated call says which plan unlocks it and how to buy it by API.

Why: An agent that hits a plan gate needs to know what unlocks it.
To fix: Say in the error which plan unlocks the call and how to buy it by API.

LIM-04

Holds up under repetition

CoreMeasured in every drive

Core tasks pass on every one of several runs.

Why: A task that works in one run of three can't be left to an agent.
To fix: Run the core tasks many times and fix what fails some of the time.

Pay.

Paying without a card form or a person.

PAY-01

Start without a card

RecommendedMeasured in every drive

A free plan or a trial without a card, with a key that works on it.

Why: An agent has no card of its own to start a trial with.
To fix: Offer a free plan or a trial without a card, with a key that works on it.

PAY-02

An agent payment rail on the core

AdvancedMeasured in every drive

x402 or MPP challenges that parse, name the right price and networks, settle, and cover the core work.

Why: With x402 or MPP an agent pays per call, with no account and no card form.
To fix: Answer core calls with x402 or MPP challenges that name the right price and networks, and settle them.

PAY-03

A plan an agent can buy by API

RecommendedMeasured in every drive

The plan the product sells can be bought by API, Stripe Projects or a 402, without a card form in a browser.

Why: An agent can't fill in a card form in a browser.
To fix: Sell your plans by API, through Stripe Projects or with a 402 payment.

PAY-04

Payments safe to retry, with a receipt

RecommendedNot measured yet

A retried payment never charges twice, and every payment returns a receipt.

Why: Agents retry. A payment that charges twice costs the person behind it.
To fix: Make payments idempotent and return a receipt for each one.

PAY-05

Spend an agent can see and cap

AdvancedNot measured yet

Balance, usage and a spend cap readable and settable by API.

Why: The person behind an agent wants a ceiling on what it spends.
To fix: Make balance and usage readable by API, and let callers set a spend cap.

PAY-06

No person in the buy path

CoreMeasured in every drive

No sales call, quote, captcha or phone check before paying.

Why: A sales call, a quote or a captcha before paying stops every agent.
To fix: Let a buyer pay without a call, a quote, a captcha or a phone check.

Leave.

Cancel, delete and export by API.

LEAVE-01

Cancel by API

CoreMeasured in every drive

Cancel by API or CLI. The answer states when access ends and what is still owed.

Why: An agent that started a plan must be able to stop it too.
To fix: Offer cancel by API or CLI, and say in the answer when access ends and what is still owed.

LEAVE-02

Delete by API, checked

RecommendedMeasured in every drive

The account and its data can be deleted by API, and a later login or key call fails.

Why: A deleted account has to stay deleted, with its data and its keys.
To fix: Delete the account and its data by API, and make old logins and keys fail.

LEAVE-03

Export before leaving

RecommendedNot measured yet

All of the account's data can be exported by API in a documented format (JSON or CSV with ids and relations).

Why: A person moving on needs their data, and an agent can do the export for them.
To fix: Export all of an account's data by API as JSON or CSV, with ids and relations.

LEAVE-04

Grants and keys end on request

RecommendedPartly measured

Keys and OAuth grants can be revoked by API and stop working at once.

Why: Revoking a key or a grant only helps when it takes effect at once.
To fix: Revoke keys and OAuth grants by API, and stop them working at once.

Agent protocols.

Newer ways for agents to find and call you.

PROTO-01

A2A agent card that works

AdvancedPartly measured

A valid A2A 1.0 card whose advertised interfaces answer, with skills, examples and auth stated.

Why: Other agents find and call yours through its card.
To fix: Publish a valid A2A 1.0 agent card whose interfaces answer, with skills, examples and auth.
How we grade it: The card at /.well-known/agent-card.json (or the older /.well-known/agent.json) must parse and state a name, skills with ids, its interfaces and its auth. Whether the interfaces answer isn't checked yet.

PROTO-02

WebMCP tools on the web app

AdvancedNot measured yet

Pages register user-level tools (document.modelContext) with schemas and honest hints.

Why: An agent in a browser can call your web app's tools instead of clicking through it.
To fix: Register your web app's actions as WebMCP tools with schemas and honest hints.

PROTO-03

Web Bot Auth as a receiver

AdvancedMeasured in every drive

Signed requests are verified and allowed, and the policy for signed agents is stated.

Why: A signed agent proves who it is. Your site can let it in on that.
To fix: Verify Web Bot Auth signatures, let signed agents through and state your policy for them.

PROTO-04

Agent Skills published

AdvancedPartly measured

An Agent Skills index (/.well-known/agent-skills/index.json) with digests, and skills that match the product.

Why: A skill teaches an agent how to use your product well.
To fix: Publish an Agent Skills index at /.well-known/agent-skills/index.json with digests.
How we grade it: The index at /.well-known/agent-skills/index.json must parse and list skills, each with a name, a url and a sha256 digest. Whether the skills match the product isn't checked yet.

See where your product stands.

Free: the check in front of your sign-up page, and how many things to fix.