Last week I shipped 26 MCP servers in 2 days. This week I'm at 35 servers, a Google Sheets add-on, and a full x402 payment stack.
Revenue so far: $0.
Not because nothing works. Everything works. Every server is deployed, every paywall responds, every API returns the right answer. The problem is different — and it's the thing nobody talks about when they write about AI monetization.
The reality check
When I started building MCP servers, I genuinely believed the hard part was technical. Get the server running, wire up x402 for agent payments, publish to the marketplace, done. The money should follow.
Here's what actually happened:
- 35 MCP servers are live on MCPize with SEO, logos, pricing, and marketplace listings
- Two Cloudflare Workers — HS Codes Classifier and Document-to-JSON — are running with x402 paywalls settled in USDC on Base
-
A Google Sheets add-on —
=HSCODE(A2)— returns real customs codes from real product descriptions - Zero external API calls in the last 24 hours
- Zero active users across all servers
- Zero revenue
Everything is configured correctly. Nothing is reaching anyone.
What I built
The stack, briefly:
MCP servers (35)
Validators (iban-validator, vat-validator, swift-validator), parsers (invoice-parser-v2, document-to-json-mcp), extractors (contract-clause-extractor, meeting-action-extractor), and domain tools (hs-codes-mcp, license-checker-mcp, medical-coding-helper-mcp).
Cloudflare Workers with x402
Every Worker sits behind an x402 paywall. Agents pay USDC on Base — no signup, no API key. Pricing is $0.01 per call for single operations, $0.05 for batch operations up to 100 items. 50 free calls per day.
Google Sheets add-on
A custom function =HSCODE("laptop computer") that returns 8471.30 | confidence: 0.95 in any cell. The add-on calls the same Cloudflare Worker, caches results locally, and gives regular spreadsheet users direct access to the same classifier that agents get via MCP.
The technical details that actually matter
Service Bindings instead of public fetch
When I first connected a call counter to my MCP servers, I tried the obvious thing: a public fetch() call to another Worker inside ctx.waitUntil(). The request never arrived. Cloudflare's loop protection blocks worker-to-worker calls through public URLs.
The fix is Service Bindings — direct worker-to-worker calls declared in wrangler.toml. The [[services]] block binds a name (CALL_COUNTER) to another Worker (call-counter). Inside the handler, env.CALL_COUNTER.fetch(...) reaches the target Worker directly, bypassing the public network entirely.
Non-blocking, fire-and-forget, and it works. This took me three hours to figure out.
KV cache is doing real work
The classifier caches results by SHA-256 hash of the normalized description. When someone classifies "laptop computer" for the first time, it costs an OpenAI call. The second time, it returns from KV in milliseconds.
Across the 35 servers, this cache absorbs repeat queries at near-zero cost. It's the difference between $0.0003 per call and $0.000001 per call.
Secrets management is fragile
Uploading a secret via wrangler secret put does not always propagate to the current deployment. Sometimes it does. Sometimes it needs a follow-up wrangler deploy. I spent an hour chasing a token mismatch that turned out to be a stale deployment.
If you're debugging an unauthorized response and everything looks correct, redeploy. Then redeploy again.
Three monetization models — and what each one means
Model 1: Freemium
Each server has a Free tier — 50 calls per day. This makes the listing visible in the marketplace and gives users a zero-friction way to try it. Good for discovery, bad for revenue.
Model 2: Subscription ($19/mo)
The MCPize marketplace adds a Pro tier — $19/month for 5,000 calls. This is the model the marketplace actually wants — one subscription, one API key, uniform billing across all servers. Predictable, but the barrier is high for first-time users.
Model 3: Pay-per-call (x402, $0.01)
Agent-native. No signup, no subscription, no API key. An agent calls a tool, gets a 402 response with a payment challenge, settles in USDC, gets the result. This is the most technically elegant model — and the least understood by anyone outside the crypto-native AI space.
In practice, all three can coexist on the same server. My iban-validator has all three: Free tier, Pro $19/mo, and x402 pay-per-call at $0.01–$0.02.
The problem is that the third model assumes demand. If no agent is calling your server, there's nothing to bill.
What I learned
Configuration is not distribution.
I can spend a week tuning SEO, pricing tiers, and listing descriptions. None of it matters if nobody opens the page. Marketplace listings don't automatically bring traffic — they give traffic somewhere to land when it arrives.
x402 doesn't sell itself.
The protocol is elegant. The settlement is instant. But agents only pay when they have a reason to call. And they only call when the tool is either (a) in their default toolset, or (b) findable through a search mechanism they use. Neither of those things is automatic.
Google Sheets is underrated.
=HSCODE(A2) takes three seconds to type. No documentation, no API key, no setup. If you're building tools for non-developers, spreadsheet integration beats an API endpoint every time. A logistics manager will use a spreadsheet formula before they'll touch an MCP server.
What's next
Two directions:
Programmatic SEO. Generate hundreds of pages — "HS code for laptop", "HS code for wooden chair", "IBAN validator for Germany" — each linking directly to the relevant server or the Sheets add-on. Google indexes them, long-tail traffic arrives, conversion becomes a matter of landing page quality.
Distribution through existing channels. The Dev.to and Medium posts are the start. Reddit's r/SideProject and r/mcp. Hacker News. Discord servers for AI agents. Every channel that already has an audience for this problem.
Everything else is already built. The remaining work is getting the first 100 users to see it.
Try it
Google Sheets: open a new sheet, go to Extensions → Apps Script, and paste the code from my GitHub. Then in any cell: =HSCODE("iPhone 15 Pro"). You'll get 8517.12.
MCP servers: browse the list at mcpize.com/mcp/iban-validator — it's a good example of the pricing model, the SEO setup, and the overall shape of what I've shipped.
Cloudflare Workers: hs-codes-classifier.boring-saas-infra.workers.dev — try /health and see the 402 response on /classify.
Everything: boring-saas-infra.pages.dev
What's your experience with AI monetization? Is it a traffic problem for you too, or have you found channels that actually convert?
Top comments (5)
Your Sheets example suggests a useful small experiment: pick just HS classification and measure discovery -> first successful result -> a second distinct task within 7 days -> paid use. That would separate a distribution problem from a tool people try once but don't need again.
For the first comparison, keep the underlying task and free quota the same and change only the entry point: Sheets versus the MCP listing. Aggregate counts by entry point would be enough to start; no need to retain customer product descriptions.
I'd exclude health checks, repeated 402 challenges and retries from successful-task counts, and track payment settled separately from result delivered. Would you publish that one-tool funnel before expanding the SEO pages? The drop-off point could tell you which part to work on next.
This is exactly the type of granular instrumentation we need before scaling up the top-of-funnel traffic. You're completely right about excluding 402 challenges and health checks from the core task counts—otherwise, the automated pipeline noise completely skews the activation metrics. Tracking the time-to-second-task window within those 7 days is probably the best proxy for actual product-market fit we have right now. I’ll map out this specific funnel visualization first to pinpoint the drop-off before dumping resources into broader SEO expansion. Appreciate the sharp breakdown!
Isolating the conversion funnel down to a single distinct tool is exactly the kind of validation we need before scaling up broader distribution channels like programmatic SEO. Here is how we are breaking this down based on your suggestions:
Fellow traveler here — Script Master Labs runs the same stack (a fleet of MCP servers, x402 on Base) and your three lines are the whole game: 'Revenue so far: $0.' / 'Configuration is not distribution.' / 'x402 doesn't sell itself.' One pattern that has actually produced outside settlements for us: lead with a decision, not a catalogue. Our Verdict Protocol sells a single multi-juror decision — $0.25/decide, USDC on Base, bands published up front (≥0.80 auto-pay, 0.50–0.79 confirm, <0.50 escalate) — and the paid calls come from agents that need a yes/no before they move money, not from directory traffic. Would genuinely value comparing notes on repeat buyers; that's the metric neither of us has cracked yet. — Timothy, Script Master Labs (verdict.scriptmasterlabs.com)
"Lead with a decision, not a catalogue" is the best TL;DR for MCP monetization I've seen yet. It perfectly explains why agents will happily pay for an execution block but ignore generic data endpoints.
On the repeat buyer metric: I suspect the answer lies in zero-friction integration into automated loops. If an agent's workflow hits a policy check, paying $0.25 for a definitive yes/no is a no-brainer compared to the cost of a failed transaction or a human waking up to fix a mistake. Once that API call is baked into the agent's code, repeat purchases happen automatically—you just have to survive the initial integration test.
One technical question on the Verdict Protocol: if an agent is waiting for a multi-juror decision, how do you handle latency? Does the delay ever break the agent's workflow or cause a timeout?