How the Specifications Relate
OpenAPI, AsyncAPI, JSON Schema, Arazzo, Overlay, Spectral, APIs.json, MCP, A2A, GraphQL, gRPC and JSON-RPC — read from their published schemas, mapped by what each one points at, which property does which job, and how much vocabulary they share.
Each of these specifications solves one piece of the problem, and each one leans on the others to do it. The picture below comes from reading their published schemas side by side: which spec points at which, which property does the same job under a different name, and where the same name means something different.
What points at what
An arrow reads from the spec that holds the pointer to the spec it points at. Select a specification to trace its connections and see its root properties. Hover over an arrow to see the property it goes through.
APIs.json indexes nine of the other eleven, so those lines are drawn light; select APIs.json to bring them forward. Its schema has no property type for gRPC or JSON-RPC, so no line is drawn to either.
Same job, different words
Fourteen jobs that most of these specs have to do, and the property each one uses to do it. An empty cell means that spec's schema has no property for the job, either because the job is out of scope or because it is handled somewhere other than the schema. Select a column heading to highlight that spec on the map.
How much vocabulary they share
Every property name each schema declares, anywhere in its object tree, compared pair by pair. Each cell shows how many names the two specs share; its shade is that count as a share of all the names the two use between them (Jaccard). The diagonal shows each spec's own vocabulary size. A shared name is a lead, not proof of a shared meaning; the next section shows why.
Mostly the plain words of description. The overlap that matters is the specific names: securitySchemes, operationId, $ref.
What the strongest pairs share
| Pair | Shared | Property names in common |
|---|
Same word, different meaning
Matching specs by property name goes wrong fast. These names appear in more than one schema, and in most of these cases they do different jobs. Two are exceptions worth noticing: Arazzo borrowed action from AsyncAPI on purpose, meaning included, and MCP's method is JSON-RPC's because MCP is JSON-RPC.
The rest of the catalog
These twelve specifications are read at schema depth because they are the ones an API is actually defined, called and governed with. The other six hundred entries relate to each other too — a practice and the standards that realize it, a profile and the standard it profiles — but those relations are hand-authored assertions rather than properties anyone can check. They are kept on their own page, at their own evidence tier, so the claim this page makes stays exact.
Sources and method
Every key declared under `properties` anywhere in each published schema (A2A: every protobuf message field, camelCased; JSON Schema: the keywords of the seven 2020-12 vocabularies). The three API protocols publish no JSON Schema, so each is read from the most formal thing it does publish. GraphQL: the fields of the introspection types in the specification's own SDL. gRPC: the message fields of descriptor.proto, the Protocol Buffers document a gRPC service is described in and its reflection service returns, plus gRPC's reflection.proto. JSON-RPC 2.0 is prose only, so its nine member names are transcribed by hand from the specification; it is the one vocabulary here that no parser produced. AsyncAPI's bundled schema inlines the JSON Schema, OpenAPI 3.0 and Avro meta-schemas, plus the protocol binding schemas; those are excluded so the count reflects AsyncAPI's own vocabulary. Values under examples, default, const and enum are sample data and are not counted. The relationships and the job matrix are curated by hand, and every entry names the property that proves it — the verified evidence tier, and the only tier this page accepts. An edge that cannot name a property does not belong here; the catalog-wide graph of hand-authored relations that cannot is at /relationships/catalog/, and the two share no edge and are never summed. The OpenAPI → MCP generation line is backed by the OpenAPI extensions profiled on extensions.apievangelist.com: every AI-purpose extension with mcp in its name, counted by provider and document. The counts are regenerated by scripts/build-spec-overlap.py.
| Specification | Version | Properties | Schema read | Catalog |
|---|