MCP v2 shipped on March 26 with native OAuth 2.1 authorization. The spec is tighter. The security story is cleaner.
What did not ship: a billing layer for the 5,800+ community servers running on it.
Most MCP servers are free. Not because their operators want them to be free — because adding per-execution billing to an existing server is genuinely annoying. You need to intercept requests, validate payment, handle cold-start failures silently, and do it without breaking your tool schema.
This post is about skipping all of that by wrapping an existing server instead of modifying it.
The cold-start problem nobody talks about
Before billing: cold starts.
When an agent calls your MCP server after a period of inactivity, Cloud Run (and most container runtimes) spin up fresh. That first call fails or times out. The agent logs an error and moves on. You never know it happened.
At ClawMerchants we tracked this across 2,500+ agent probes. The pattern is consistent: agents do not retry. They fail silently and route around you.
The fix is a retry wrapper with exponential backoff and health-check pre-warming. But again — most MCP operators do not have the time to build this.
What "wrapping" an MCP server means
Instead of modifying your server code, a gateway sits in front of it:
agent request
→ gateway (auth check, MPP billing, retry logic)
→ your existing MCP server (unchanged)
→ response back through gateway
Your server does not need to know about billing. It does not need to handle payment headers. It speaks MCP as it always has.
The gateway handles:
-
MPP session billing — the Machine Payments Protocol from Stripe + Paradigm. Agents send an
Authorization: Paymentheader; the gateway validates and charges per execution. - Cold-start retries — three attempts with backoff before failing to the agent. The agent sees a healthy response or a clean error, not a timeout.
- SLA tracking — uptime and latency logged per tool call so you have data when something goes wrong.
The MPP header in practice
The Machine Payments Protocol (launched March 18, 2026) is designed for exactly this: agent-to-service payments without requiring the agent to hold crypto.
A request to a wrapped MCP server looks like:
POST /mcp/my-tool HTTP/1.1
Host: gateway.clawmerchants.com
Authorization: Payment <session-token>
Content-Type: application/json
{"jsonrpc": "2.0", "method": "my_tool", "params": {...}}
If the session token is valid and the balance covers the execution cost, the gateway forwards the request. If not, it returns a 402 with the session price and renewal instructions.
The agent handles the payment. Your server handles the logic. The gateway handles everything in between.
Registering your server
ClawMerchants has an enterprise integration page at clawmerchants.com/enterprise where MCP server operators can register for gateway wrapping.
The registration takes about 5 minutes:
- Submit your server URL and the MCP tools you expose
- Set a per-execution price (minimum $0.001)
- Receive a gateway endpoint your agents can call immediately
The gateway runs on Cloud Run with automatic scaling. Cold-start retry logic is built in — no configuration required.
Why now
MCP v2 is the right moment to add a billing layer. OAuth 2.1 means agents now have a proper authorization flow. The payment layer is the natural next piece.
The 5,800+ community servers that shipped on MCP v1 are still unmonetized. Some of them have real data, real compute, or real utility behind their tools. The operators just never built the billing layer.
Wrapping instead of rewriting is the path of least resistance.
If you operate an MCP server and want to add per-execution MPP billing without touching your server code, clawmerchants.com/enterprise is where to start.
Top comments (0)