Registries Reloaded: Why We Still Don’t Understand Them

MCP launches a registry preview, but history tells us registries fail more often than they work.

Yesterday the MCP Steering Committee proudly launched its Registry preview. Another registry in the API world, another promise to bring order to the chaos. But if we are honest, registries have been the graveyard of good intentions for more than two decades. We keep relaunching them under new names, new ecosystems, and new standards as if repeating the same idea will magically change the outcome.

UDDI and the First Death of Registries

Remember UDDI? The supposed backbone of SOA discovery. It died under the weight of bureaucracy and governance theatre. Nobody wanted to use it, developers avoided it, and architects quietly abandoned it.

API Management Registries: Where JSON Went to Die

A decade later API management vendors promised us registries embedded in their platforms. What we got instead were glorified catalogs, static dashboards where OpenAPI specs went to rot. No lifecycle, no trust, no governance, just a user interface for ticking boxes.

ORD: A Bold but Trapped Attempt

And then there is ORD, the Open Resource Directory. Born in the SAP ecosystem, it was a bold attempt to standardize service and API descriptions across platforms. NeoNephos pushed it forward, showing that the idea could work in practice and not just in theory. But the reality is that ORD never broke free of its ecosystem. It was useful if you lived in SAP’s orbit, irrelevant if you did not. It showed what could be done, but it was never a neutral standard the wider industry could rally around.

Catalogs Are Not Registries

This is where my colleagues Miriam and Felix hit the nail on the head in their piece on API discovery. They reminded us that developer portals, catalogs, and marketplaces are not registries. Portals are for consumption and onboarding. Catalogs are inventories and governance aids. Marketplaces are for monetization. Registries in contrast are supposed to serve providers as authoritative systems of record. And yet we have spent the better part of a decade confusing catalogs for registries. No wonder everything feels broken.

The Registry That Never Was

Because let us face it, a real registry is not glamorous. It is plumbing. It should track versions, dependencies, ownership, and lifecycle states. It should be the source of truth feeding portals, catalogs, and marketplaces, not masquerading as them. Instead, registries have been treated as dumping grounds for JSON and YAML files, graveyards of outdated specs, and marketing slides for vendors.

MCP Registry: Fresh Start or Same Mistakes

So what about the shiny new MCP Registry. It ties the idea of a registry to model contexts and workflows. That is new. It shifts focus away from endpoints and toward interactions. But let us not get carried away. If it does not solve ownership, trust, and lifecycle governance with teeth, it risks becoming yet another parking lot for specifications, just with fancier labels.

xRegistry: The Last Chance

Which brings us to xRegistry. Finally, a serious attempt at defining what a registry should be across ecosystems. Neutral, interoperable, governance aware. Not a portal. Not a catalog. Not a marketplace. If xRegistry works, it could be the first time we actually have a standard that turns registries into the backbone they were always meant to be. But if it fails, registries will remain the punchline of enterprise architecture jokes for another decade.

Beyond APIs: Registries of Capabilities

And here is the real provocation. APIs themselves may no longer be the problem. Endpoints are transient.

Capabilities endure. We do not just need registries of OpenAPI/AsyncAPI files, we need registries of capabilities, semantics, policies, and context. Without that, even the most sophisticated registry will be irrelevant in the era of federated platforms and AI driven ecosystems.

Stop Pretending

So let us stop pretending that every new registry is salvation. MCP’s preview is interesting. xRegistry has potential. ORD proved that ecosystems can push useful ideas. But unless we answer the hard questions, what problem does a registry solve, who does it serve, and how does it federate across systems, we are simply reliving history.

Closing Reflection

Registries are not sexy. They are infrastructure. But they matter. They are the difference between API chaos and API strategy. If we fail again, MCP, xRegistry, and ORD will all join UDDI in the graveyard of good intentions. And that would be a shame, because efforts like NeoNephos around ORD prove

there is passion and vision in the community. The problem is not a lack of effort. The problem is that ecosystem bound solutions rarely escape their orbit. Twenty years from now the industry may still be asking the same question: why do registries never work.

What do you think? Are MCP and xRegistry finally a turning point, or are we watching the same old movie play out with new branding? I would love to hear your take. Share your experience with registries past and present and let us see if we can break this cycle together.