The money in MCP isn't in the tools — it's in owning the system that connects them
Jesse Hopkins' framing is the clearest I've seen on MCP economics: "the money wasn't in the tools. The money was in the system that connects them. And the money was in knowing how to build them in the first place."
That's correct. But it skips a step that matters: the system that connects tools also needs to be able to charge for connecting them.
What "the connecting system" actually means
There are two interpretations of what Jesse is pointing at:
Interpretation A: the value is in being the developer who can build the integration — the skill premium. You don't sell the MCP server; you sell your ability to build whatever the client needs.
Interpretation B: the value is in the platform layer — the infrastructure that orchestrates multiple MCP servers, manages agent workflows, and handles the business logic around which tools get called when.
Both interpretations are correct. But interpretation B has a problem: if you build the orchestration layer and want to charge for it, you need billing infrastructure that doesn't currently exist in the MCP protocol.
The billing gap in orchestration platforms
An orchestration platform that routes agent requests to multiple MCP servers has natural monetization options:
- Charge per agent-hour
- Charge per tool call routed
- Charge for premium MCP server access vs. free tier
- Revenue-share with MCP server developers for traffic
All of those models require the same thing: a payment layer that's aware of the MCP protocol, can authorize calls before they run, and can settle across multiple server relationships without requiring the client to have accounts everywhere.
That's not a standard billing problem. It's an agent-native payment problem — and it's different from putting a Stripe checkout in front of an API key.
The per-call model at orchestration scale
For an orchestration platform, per-call pricing at the MCP layer means:
The orchestrator knows the price of each tool call before it decides whether to invoke it — so it can optimize agent workflows for cost, not just capability.
Payment is settled at the tool level, not at the platform subscription level — so the orchestrator can pass through costs accurately to its own clients.
MCP server developers get paid for actual usage, not lumped into an orchestration subscription that undercuts them.
This is the architecture that makes interpretation B viable as a business: the platform earns by connecting tools, the tool developers earn per call, and the agent layer has price visibility before committing.
MnemoPay in this context
MnemoPay is the payment layer that wires per-call billing into MCP servers and the orchestration platforms above them. The Agent FICO score (300-850) gives orchestrators a creditworthiness signal per client-agent so they can gate expensive tool calls appropriately.
672 tests in v1.0.0-beta.1. npm-native. if you're building the "system that connects them" and want the payment infrastructure handled at protocol level, the SDK integration path is under an hour for a Node environment.
Top comments (0)