The OpenAPI Registry
What happens if OpenAPI copies MCP's discovery strategy?
It's 2025, and I still can't easily find the APIs I'm looking for. And it's not because there's a lack of places to look. Au contraire. It's because I can't trust any of those places enough to accept that their results are the best match for what I need. There are easily more than 200,000 public APIs available, I'd say. The challenge is that they're spread across more than a dozen API directories. While some of those directories are dedicated to specific sectors, e.g., banking, most are generic. The result is that the process of finding an API is highly convoluted. It consists of jumping between API directories until you locate what you're interested in. That's definitely not ideal. What we need is a trusted, authoritative directory of APIs. What's stopping us from building it? Read on to find more.
This article is brought to you with the help of our supporter: Speakeasy.
Turn your API platform into an AI platform with Gram by Speakeasy. Create tools from OpenAPI, curate into custom toolsets, and deploy hosted MCP servers.
Scattered over places like APILayer1, APIs.guru2, APIsList3, the Postman API Network4, and a few others are the APIs I don't yet know I need. When the time comes, I'll go through each one of those places and search for the capabilities I'm interested in from a pool of hundreds of thousands of APIs. If I'm lucky, I'll find a few good candidates. Depending on where I find them, I'll have to understand if the API is up to date with the contract I found, or if the collection reflects the operations the API exposes. This can only be done by trying, and could be avoided if the API details were published by the official entity owning the API. This problem isn't new, though.
ProgrammableWeb, an API-focused blog and directory of APIs, was created in 2005 and tried to overcome the challenge of outdated information. The solution they found, though, was not scalable. It involved manually curating all the APIs that were available in its directory. As the number of listed APIs grew to over 25,000 in 2022, it was clear that there was no way to continue operating the service. In the meantime, Postman found a better solution, almost by chance. In around 2017, they launched their API network, also as a manually curated list of collections. However, they quickly realized that the API producers should be the ones publishing the APIs and owning the information. The result was that the number of collections they list grew to over 100,000 in 2025. What's not so great is that they're not listing OpenAPI documents. Instead, and understandably, what they're listing is Postman collections. If you think the perspective of a potential API consumer isn't too positive, look at what happens if you're an API producer.
In 2025, if you want to publicize your API to attract consumers, you'll have a hard time. First, you have to choose between all those directories I mentioned before. Then, from those places, you'll want to pick the ones that have the highest number of users. Since your goal is to attract consumers, you want to maximize your chances by publishing your API where users are. You'll use other tricks as well. The most widespread, since there's no official place to search for APIs, is to use the next best thing: official programming language package repositories. You'll publish your API's SDK in the most popular programming language package repositories. As an exercise, searching for "api" on the npm repository will retrieve thousands of results. Among those results, you'll see the official SDKs of many public APIs. Companies such as Microsoft, Netlify, Slack, and Stripe are following this approach. Stripe's npm package, for example, has over four million weekly downloads. Could this messy situation have been avoided? I think so, and it looks like I'm not the only one.
Bruno Amaral is the founder of Gregory AI5, an AI-based medical research assistant. Amaral is running several versions of the assistant dedicated to areas like multiple sclerosis, brain regeneration, and encephalitis. Amaral told me that he wishes there were an authoritative API directory so he could publish the assistant API there. For now, he has to contact developers directly to show them how the API works. In a different sector, there's David Biesack. He's the Chief API Officer at Apiture6, a digital banking company in business in the United States since 2017. They connect financial partners to banks through their platform and a set of dedicated APIs. Biesack shared that potential partners find their public developer portal through Google searches. Something similar is happening in Brazil. Vinicius Marques, a Brazilian banking technology professional, mentioned that, in general, banks have a public API portal where developers can see what APIs are available. However, most developers find those APIs through Google searches. It surely looks like there's a pattern here, and we'd all benefit from a dedicated, authoritative registry like the one I'm proposing. Is anyone already building something along these lines? I'd say so, judging by what's now happening to the popular MCP standard.
"Can OpenAPI copy MCP's discovery strategy?" I asked recently on a few social media channels. On September 8, 2025, MCP launched its registry7. According to the official announcement8, it's "an open catalog (...) for publicly available MCP servers to improve discoverability." Before this announcement, there were at least 15 MCP server directories in the market. Names like PulseMCP9, MCP.so10, and even Postman11. Does the scenario sound familiar? The official MCP registry might not put an end to third parties, but it will certainly give consumers a source of truth and a single place to search. MCP is doing it the right way by a) creating an official registry, b) offering a way to extend the official registry, and c) searching and interacting with MCP servers directly from the consumer tool. This could be a solution for OpenAPI. Imagine going to search.openapis.org (doesn't exist at the time of this writing) to find the API you're looking for. Or, even better, being able to search for APIs right from your favorite API client, and making a first request in almost no time. Building something like this shouldn't be too difficult. But before we even try that, let's see how it would align with the business needs of API producers and consumers.
Some people in the API industry defend that an official OpenAPI registry would never work because it wouldn’t be able to align with the business needs, whatever they are. That is correct, an API registry would never be able to align with all existing business needs. In the same way, a Web page registry, a.k.a. a search engine, doesn’t align with all existing business needs. There is, however, at least one business need with which an API registry aligns. If the business need of an API producer is to attract new customers, then the APIs should be easy to discover and onboard. How can we make APIs easy to discover by potential customers? One way is to publish information about those APIs in a place where potential customers can go to and find them. That place is the OpenAPI registry. Coincidentally, the registry would also align with the consumer business need of being able to easily find an API. What happens after a consumer finds an API is beyond what the OpenAPI registry would offer. And that is precisely why building something like this isn't too complicated.
There are a few approaches to building an API registry. You could consider, for example, building it from the ground up openly. That's, by the way, the approach MCP is taking. However, if you're not inclined to put everything up from scratch, there are a few open-source solutions that could be a good fit. The Apigee Registry12 is, according to their documentation, "a structured approach to organizing information about APIs." It offers a gRPC API that lets you manipulate entries, perform searches, and obtain the full information about single APIs. Behind the scenes, it can use a relational database such as PostgreSQL or SQLite. It looks like a good candidate if what you're looking for is simplicity and the ability to extend it. Then you have the Apicurio Registry13, which lets you store both APIs and schemas. It's a system that lets you store API definitions so that potential consumers can search the list of available APIs, view details about a given API, and even read auto-generated documentation for each API. The final open-source solution on my list is the Scalar Registry14. It lets you store OpenAPI documents, JSON schema, and even Spectral rules. It offers the basic functionality of creating, reading, updating, and searching items, and it also connects to GitHub actions. This can be an advantage because it lets API producers automate the process of updating their OpenAPI documents whenever there are changes. Any of these could be a potential starting point for implementing the official OpenAPI registry. I bet any of the companies behind these registries would be open to giving a hand to the OpenAPI Initiative to help get things started. Building the registry sounds quite easy. Even if maintaining it might come with its cost in the long term, the benefits are immense compared to the chaos where we are right now.
Whether or not the OpenAPI Initiative ends up launching an official, authoritative API registry is up to them to decide. Now, please don't take these words and decide to build it yourself, or we'll end up with an even more fragmented space than the one we're in. The goal is to consolidate the API searching experience in one single interface that potential consumers trust. That's what I'd call the OpenAPI registry.
The APILayer directory is available at https://apilayer.com/marketplace
The APIs.guru API directory is available at https://apis.guru
The APIsList API directory is available at https://apislist.com
The Postman API Network is available at https://www.postman.com/explore
Gregory AI is available at https://gregory-ai.com
Apiture is available at https://apiture.com
The MCP registry is available at https://github.com/modelcontextprotocol/registry
The MCP registry announcement is available at https://blog.modelcontextprotocol.io/posts/2025-09-08-mcp-registry-preview
The PulseMCP Server Directory is available at https://www.pulsemcp.com/servers
MCP.so is available at https://mcp.so
Postman MCP servers directory is available at https://www.postman.com/explore/mcp-servers
The Apigee Registry is available at https://apigee.github.io/registry
The Apicurio Registry is available at https://www.apicur.io/registry
The Scalar Registry is available at https://guides.scalar.com/scalar/scalar-registry/getting-started