Note · Building on MCP
A connector directory is not a marketplace, and the difference is the toll
A directory lists you. A marketplace takes a cut, ranks you, and eventually decides how you charge. MCP connector directories currently do the first and not the rest, and that gap is worth building into rather than waiting out.
- Written by
- Corey
- Published
- 26/08/2026
An app store is not a directory. It is a directory plus three other things: a toll on the money, a review gate on what gets in, and a ranking algorithm that decides who is seen.
Connector directories for MCP currently have the gate. They do not have the toll, and ranking is thin. That is the whole observation, and it is worth sitting with rather than skimming, because it describes a window rather than a permanent state.
Why the toll is the part that matters
The gate shapes what you build. The ranking shapes how you market. The toll shapes what your business is.
A platform that takes a percentage changes your pricing. A platform that requires its own billing changes your relationship with the customer - you stop having one. That second condition is the one worth watching for, and it is a different thing from a fee: a fee is expensive, but being told you may not use your own payment relationship means the customer is theirs and you are a supplier.
Right now, on MCP, you keep both. You run the server. You hold the auth. You bill however you like, because nothing in the protocol has an opinion about money.
What we did with that
Two production servers, deliberately built differently to find out what the protocol actually constrains.
One is Python, hosted, multi-tenant, with seats and billing behind it. The other is TypeScript on Cloudflare Workers, acting as an OAuth resource server under RFC 9728 - it verifies tokens somebody else issued, holds no client secret and mints nothing.
Neither arrangement needed permission from a directory. Both are reachable from any client that speaks the protocol, which is the part people miss: the directory is discovery, not distribution. Being listed helps someone find you. It is not how they reach you, and it is not where the value accrues.
That distinction is why the current gap is worth building into rather than waiting out. If a toll arrives later, it arrives for the discovery layer. The server, the auth and the billing were never the directory’s to take, unless you built them somewhere they could be.
The part that is actually a risk
Not the fee. The default.
Every one of these directories will eventually have a recommended way to authenticate, a recommended way to charge, and a recommended shape for a server. Recommendations become defaults, and defaults become the thing everyone ships because it is one step fewer.
The teams that end up with no leverage will not be the ones who paid a percentage. They will be the ones who took the convenient default on auth and billing early, and later found that “convenient” and “portable” were not the same word.
We chose the awkward version twice, on purpose, and it cost real time. That is the trade, stated plainly: a resource server under a spec you have to read is slower to build than the shortcut, and it is the reason a change of directory would cost us a listing rather than a rebuild.
Where this stops working
- This is a reading of how these directories are structured today, not a prediction about what any vendor will do next. If you are making a commercial bet, read the current terms yourself rather than trusting a note with a date on it.
- It assumes your product can be reached over a remote server you control. If your value is a hosted UI, the directory is a link to your app rather than the surface the work happens on, and none of the leverage here applies.
- Being early in a directory is worth very little on its own. What compounds is the server being genuinely good when someone finds it; a listing does not fix a bad tool surface.