Buf has published a practical walkthrough of getting two more formats out of a schema you already have. In Protobuf, JSON Schema, and OpenAPI, Kevin McDonald takes a small inventory service with Protovalidate rules and runs it through two plugins: Buf’s own protoc-gen-jsonschema, which emits JSON Schema draft 2020-12, and protoc-gen-connect-openapi, a community plugin McDonald wrote and maintains, which emits an OpenAPI 3.1 document for each Connect endpoint. The validation rules travel: a Protobuf min_len and max_len become minLength and maxLength, and the SKU regex becomes a pattern. The closing instruction is the thesis: “If you need JSON Schema or OpenAPI for schemas you already have in Protobuf, generate them rather than writing them by hand.”
There are no adoption figures, which is right for a how-to, and the useful content is the three ways to run the plugins. Locally with a Go install, remotely through the Buf Schema Registry so nothing is installed on the machine, or as a generated SDK downloaded from a stable archive URL for any published module, so “your CI pipelines and developer machines can now download the JSON Schema or OpenAPI specifications without needing the Buf CLI.” McDonald is careful about provenance, noting the OpenAPI plugin “is my own project rather than an official Buf one,” and about what OpenAPI adds that Protobuf lacks, server URLs and authentication schemes, which can be merged from a handwritten base file or carried in gnostic annotations. He also names the agent use: the JSON Schema output can “constrain structured output from LLMs like Gemini or ChatGPT, so the response parses into the shape you expect.”
The catalog has a direct comment to make. The Buf provider page records that Buf’s own public API “is published as Protobuf rather than OpenAPI,” 33 services and 85 RPCs served over Connect, gRPC and gRPC-Web, Apache-licensed on GitHub, with the same surface exposed to agents as a remote MCP server. The two API pages on the record are the Buf Schema Registry and the Buf CLI. The MCP server is lit on the Agent Readiness score, and so are idempotency, error semantics, the event surface, agent skills and the full identity layer, delegated identity, protected resource metadata and dynamic client registration. OpenAPI examples and agentic access are unlit.
The Kin Score is 65.3, strong band, and the split is the story. Operational transparency is 92.1, developer ergonomics 85.7 and access clarity 85.5, while contract quality is 39.0 and contract governance 18.2. The Agent Readiness score is 49.2, agent-ready. Contract quality is where an OpenAPI document with examples would land, and the registry’s own API is the published module best placed to generate one, with the plugin in this post, through the remote path in this post. Buf’s advice is to generate the OpenAPI rather than write it. The record shows what the registry’s own score would gain by taking it.