Tool Registry — References

Interface description formats an entry can be built on, and the compatibility and ownership conventions that make a catalogue governable.

Describing a registered contract

• JSON Schema — the vocabulary most tool declarations are expressed in; its $id and $ref mechanics are what let one registered contract reference another without copying it.
• OpenAPI Specification — operation-level description including parameters, responses, and documented error shapes; the closest existing practice for cataloguing callable operations at scale.
• Model Context Protocol — defines the shape a server uses to advertise a tool, which is the form many entries must be convertible to.

Change and compatibility

• Semantic Versioning — the convention that makes "this entry changed compatibly" a statement a consumer can act on rather than a claim in a release note.
• RFC 9110: HTTP Semantics — the definitions of safe and idempotent operations, the established precedent for recording effect class as a property of an interface rather than a property of an implementation.

Cataloguing and ownership

• Backstage — entity catalogue with owners, lifecycle state, and relationships; useful as prior art for which governance fields an entry needs, even where the entity model does not fit a tool.
• Service Registry pattern — the original statement of registration, lookup, and the staleness problem that follows from separating them.

No verified reference is recorded for a standard tool-catalogue schema covering effect class, data sensitivity, and deprecation together. Published work on this is vendor documentation rather than specification; the stack note lists the products.