Measure How Far A Standards Body Actually Got And What Nobody Measured

When someone asks me whether a specification is “real,” they are usually asking about adoption, and they usually get an answer made of vibes: a logo wall, a star count, a conference keynote. If you are choosing which specification to bet a platform on, or you are an agent trying to decide which format to emit, you want numbers, and you want to know where each number came from. That is the job of standard_adoption, the MCP tool behind GET /standards/{slug}/adoption on the API Evangelist API. You give it a standards body, and it tells you how many repositories it has published, how many of them graduated past “unclassified,” the release count, the human contributor count, the provenance of every figure, and an explicit list of what it does not measure.

What I gave it

First I asked find_measured_standards which bodies are measured at all. It came back with 14, from the Agentic Resource Discovery draft through to the bigger foundation-hosted ones. Then I called standard_adoption twice, on two specifications most of you have touched, both hosted at the Linux Foundation:

• {"slug": "asyncapi"}, the AsyncAPI Initiative
• {"slug": "openapi-initiative"}, the OpenAPI Initiative

What came back

Here is the core of each response, trimmed to the figures:

{"slug": "asyncapi", "governance_model": "Open source, TSC-governed",
 "repositories": {"total": 36, "archived": 0, "stars": 9690,
   "by_maturity": {"unclassified": 35, "governance": 1},
   "graduated": 1, "graduated_share_pct": 2.8},
 "releases": {"count": 28, "latest": null},
 "contributors": 100,
 "caveats": [{"part": "contributors", "detail": "Bots excluded from every
   human figure ... (asyncapi-bot, asyncapi-bot-eve, tim48-robot)."}]}

{"slug": "openapi-initiative", "governance_model": "Membership",
 "repositories": {"total": 29, "archived": 3, "stars": null,
   "by_maturity": {"unclassified": 26, "working-group": 2, "governance": 1},
   "graduated": 3, "graduated_share_pct": 10.3},
 "releases": {"count": 3, "latest": null},
 "contributors": 726,
 "measurement_gaps": ["conformance — whether shipped implementations
   actually match the specification", "test-suite coverage published by the body"]}

Put side by side, the two bodies look like different kinds of organization. AsyncAPI ships constantly, with 28 releases across 36 repositories, and almost none of those repositories carry a maturity label: 35 of 36 are unclassified, a graduated share of 2.8%. OpenAPI publishes far fewer releases, 3, but has seven times the human contributors, 726 against 100, and a slightly more structured repository estate, with two working-group repos and one governance repo for a 10.3% graduated share. One is a tooling community that also writes a specification. The other is a specification community whose tooling mostly lives elsewhere.

The part I trust most is everything around the numbers. Every figure carries provenance: the repository counts were searched from the GitHub organizations on 2026-07-31 (OAI) and 2026-08-12 (AsyncAPI), so you know how old the data is. The AsyncAPI response says plainly that bots were excluded by account type plus a named list, and warns that raw org totals “are dominated by automation and must not be compared across bodies.” Both responses end with a measurement_gaps list saying the tool does not know whether shipped implementations conform to the specification, or what test coverage the body publishes.

Some things here are weak, and they are ours. releases.latest is null for both bodies, so you get a count with no date, which makes “release cadence” a stretch, since a count without a timestamp can’t tell you how fast anything moves. OpenAPI’s stars is null while AsyncAPI’s is 9,690, so that field can’t be compared across the two. And three releases for the OpenAPI Initiative tells you about how OAI uses GitHub releases, not how often the specification ships. 3.1 and 3.2 are real, and the tagging conventions differ. Both numbers are honest readings of what was harvested, but you shouldn’t put them in a slide without that context. The data is also three months old, so it needs a refresh.

What that makes possible

• Compare before you commit. A platform team picking between event-driven and request-response descriptions can put both bodies’ contributor depth and governance structure next to each other, instead of comparing GitHub stars.
• Give an agent a grounded answer. An agent asked “is this standard mature?” can quote figures with dates and sources, and repeat the caveats, rather than guess.
• Know where the evidence stops. The measurement_gaps list is a to-do list for anyone writing a standards report. It names the questions, like conformance, that need a different kind of evidence.
• Find the next call. From here, standard_coalition tells you who is behind a body, and standard_repositories lists the repositories these counts come from.

Try it

It’s free, because a specification is a public good. Over MCP, connect to https://mcp.apievangelist.com/mcp (or the lighter https://mcp.apievangelist.com/mcp/insights) and call standard_adoption with a slug from find_measured_standards. Over REST:

curl https://api.apievangelist.com/v1/standards/asyncapi/adoption

The reference is at developer.apievangelist.com/api, the MCP docs are at developer.apievangelist.com/mcp-server, and getting started is here.