There is a small industry forming around scoring whether an API is ready for AI agents, and I am glad it exists, because it means the question is finally being taken seriously. But most of the agent-readiness scores I see share the same two limits, and the API Evangelist Rating System was built to avoid both of them. The first limit is that they treat agent readiness as the whole question, when it is actually the last question. The second is that they are aimed inward–score the one API your team is shipping, from a checklist your team fills out–when the more useful and much harder job is reading the wider public API realm the way an agent actually encounters it. My system can be pointed at your internal APIs, and I do that work, but it was designed to read the public field, at scale, comparably, and that shapes everything about how it is built.
The first difference is that my rating does not start with agents at all. It starts with whether the API is any good. Agent readiness sitting on top of a hollow API is a number that means nothing–you can have a spotless MCP server in front of an undocumented, untyped, unversioned surface, and a checklist that only looks for agent affordances will happily call that “ready.” So the foundation of my system is a composite quality score that measures the API itself, as a weighted blend of six facets: contract quality carries the most weight at twenty-five percent, then developer ergonomics and commercial clarity at twenty percent each, operational transparency at thirteen, governance at twelve, and discoverability at ten. Dozens of individual checks feed those facets, seventy-four of them at last count, and every one is earned from an artifact the provider actually publishes–a real OpenAPI contract with descriptions and error responses, not a link to a docs page. That composite is deliberately blunt, because its job is comparability across thousands of providers, not a certificate for one.
The second difference is what I refuse to treat as optional: the operational and onboarding surface. A lot of agent-readiness scoring goes straight from “is there a spec” to “is there an MCP server” and skips the entire middle, which happens to be exactly where agents get stuck. Operational transparency–in my rubric that is documented rate limits, a status page, a change log, deprecation notices, a security disclosure path–is its own facet, because an agent that cannot see how an API behaves over time is an agent flying blind between calls. Onboarding is the other half, and I split it across developer ergonomics and commercial clarity: SDKs, a CLI, a portal, a getting-started, a sandbox or console, an MCP server, and unambiguous authentication on the ergonomics side; then machine-readable plans, pricing, sign-up, terms, and privacy on the commercial side. These are the parts of an API a human quietly powers through–they find the pricing page, they email support about the rate limit, they read the auth flow in prose. An agent cannot do any of that, which is why I score it as a first-class part of the API’s quality rather than folding it into a single “agent” checkbox at the end.
Only after all of that do I get to agent readiness–and here is the third and most important design decision–I keep it on a completely separate axis. It is a standalone zero-to-one-hundred score, not blended into the composite, built from twelve dimensions worth a hundred and four points and sorted into four honest bands from agent-native down to human-only. The dimensions are the specific things an autonomous agent needs and a human silently works around: a machine-readable contract, an explicit agentic-access classification, an MCP server, negotiable auth, idempotency so a retry does not double-charge a card, stable error semantics so it can branch instead of retrying blind, real examples, machine-readable rate-limit signaling, typed event surfaces, packaged agent skills, a well-known catalog, and forward-looking consent and bot-identity signals. I keep this separate on purpose because a provider can be thin for humans and ready for agents, or strong for humans and useless to their agents, and collapsing that into one number hides the exact gap the score exists to expose. Most other agent-readiness scores are a single blended number, and a single number cannot tell you which of those two situations you are in.
The fourth difference is scope, and it is the one that changes the character of the whole thing. Most agent-readiness assessments are self-scored against a checklist for one API. Mine runs across the entire public catalog–roughly nine thousand providers, re-scored on every rebuild–from machine-readable inputs the provider published, with no self-attestation, no panel, no vibes, and no pay-to-play tier that buys a better band. The bands are calibrated against the real distribution of the catalog rather than picked to flatter anyone, which is why they are uncomfortable: an exemplar composite is the top fraction of one percent, and only one and a half percent of providers clear the agent-native bar today. That honesty is only possible because the rubric is versioned and every check is enumerated with the points it awards–if you disagree with a weight, you can see the weight; if you think a check is wrong, you can see the check. A rating nobody can inspect is just an opinion with better production values.
So when someone asks how my rating differs from the other agent-readiness scores out there, the short version is this: theirs answers “have you bolted agent affordances onto your API,” and mine answers the larger question those affordances only matter inside of–“is this a good API, does it tell the truth about how it operates and how you onboard, and, separately and specifically, can an agent drive it without a human papering over the gaps.” It was built for the public realm, so it reads thousands of APIs the same way, from published evidence, with the methodology out in the open. You can point it at your internal APIs and I will, but the reason it is worth anything when I do is that it was forged against the whole field first. You can read every facet, every check, and both scoring axes on the rating page at APIs.io.
