Smithery's registry growth has a payment problem baked in
Smithery hit a meaningful milestone: it's become the go-to registry for connecting agents to MCP servers. the "connect in minutes" pitch works because discovery is solved. you find the server, you get the connection config, you're running.
what's not solved is the commercial layer. most MCP servers listed on Smithery right now are free or invite-only. the ones that want to charge — and there are more of them every week — run into the same problem: there's no standard way for an agent caller to pay for a tool call, and there's no standard way for a server to gate access until payment clears.
this is a solvable problem. it's just not solved yet in the registry model.
why the discovery layer and the payment layer are different problems
Smithery solves discovery by providing a normalized registry format: server metadata, tool definitions, connection instructions. an agent can look up "I need a tool that does X" and get back a list of compatible servers with connection details.
payment is a different protocol layer. it requires:
- upfront authorization — the agent (or its principal) commits to a payment method before the first tool call
- per-call settlement — each invocation either succeeds (and triggers a payment) or fails (and doesn't)
- multi-rail support — because the calling agent might be running in a Stripe context, an x402 context, or a USDC context, and the server has no way to know which one in advance
none of that is in the registry metadata. the registry tells you how to call the tool. it doesn't tell you how to pay for it.
what a commercial MCP server actually needs today
if you're running an MCP server on Smithery and want to monetize it, the current path is: pick a payment rail, implement it yourself, and accept that you're excluding callers on the other two rails. that's not a good outcome for anyone.
MnemoPay is the normalization layer that sits between the server and its callers. 1.4K weekly npm downloads, v1.0.0-beta.1 — you wire it in once and it handles AP2, x402, MPP, and Stripe-native payments from the caller side. your server doesn't need to know which rail the caller is on.
as Smithery's registry grows and more servers try to go commercial, this problem is going to get louder. the teams that solve the payment layer now will have a significant advantage over the ones that try to bolt it on after they've already got callers.
Top comments (0)