DEV Community: Randy Rockwell

# Two Weeks Running a Paid MCP on Base Mainnet — What's Actually Hard

Randy Rockwell — Tue, 12 May 2026 20:59:34 +0000

Two weeks ago I shipped ForgePoint Signal — a paid MCP server with x402 micropayments on Base mainnet. Four tools, $0.10 USDC per call, no signup, the payment is the auth. Federal Register and IRS Internal Revenue Bulletin data, parsed by Claude, served over MCP.

Two posts ago I wrote about the build pattern. One post ago I wrote about the positioning mistake I made along the way. This one's the messier one: the stuff that's actually hard once it's running.

This isn't a victory post. The Glama listing on Signal shows roughly zero usage in the last 30 days. Volume's still low, and that's part of what I want to be honest about. Most "I shipped a paid MCP" posts skip past this part. I think that's the part that matters.

The Easy Parts (Mostly)

The stack itself was the smallest piece of the work. If you have ever wired Express + Vercel + Supabase before, the MCP server layer is roughly an afternoon. Claude does the parsing reliably. The cron is a single GitHub Actions workflow. x402 on Base mainnet wired up with the Coinbase facilitator in a few hours — the docs are clear enough, the example code works.

A lot of people I've talked to expect the build to be the hard part. It is not. The build is roughly 20% of the actual work.

The Hard Parts

Middleware ordering will bite you.

The x402 verifier has to run before the MCP tool dispatcher. Not after. Run it after, and you end up either letting unauthenticated calls through on retries or double-charging the same agent for one call. I got this wrong on the first deploy and saw the symptom before I understood the cause. If you're wiring this yourself, draw the request lifecycle on paper before you trust the framework defaults. Whatever middleware library you use will quietly let you get the order wrong.

The facilitator landscape is moving under your feet.

When I shipped, the Coinbase facilitator was the obvious choice. Two weeks later, PayAI has its own facilitator (with active bugs surfacing on x402-foundation/x402 as I write this), Amazon Bedrock launched AgentCore Payments on May 7, and Google's AP2 is sitting in the wings. The picking-the-facilitator decision you make this week is a different decision than the one you would have made last week, and a different decision than the one you'll be making in two months.

I picked Coinbase because it was the most production-tested at the time. If I were shipping fresh today I'd probably still pick Coinbase but I'd write my facilitator integration thin enough to swap. Don't tightly couple to a specific facilitator's response shape. They're going to converge but they haven't converged yet.

Discoverability is the entire game after you ship.

This is the one I underestimated by the largest factor. The build took a couple of weekends. Getting the server discovered and called — that's been the entire two weeks since.

I have listings on Smithery, Glama, mcp.so, and mcp.directory. I have an .well-known/mcp/server-card.json per the spec. The Anthropic MCP registry knows about it. The Glama listing — which is one of the more active MCP directories — shows that agents have called my server zero times in the last 30 days that I'd describe as meaningful traffic.

This is normal. Almost every newly-listed MCP server I've looked at on Glama shows similar zero-or-near-zero numbers in the first few weeks. The marketplace listings are necessary but not sufficient. They're the equivalent of being indexed on Google — being indexed is not the same as being clicked.

What actually moves traffic, as far as I can tell so far: writing about it (this kind of post), being mentioned in adjacent communities, getting picked up by aggregator newsletters, and direct integration with agent frameworks where someone explicitly configures your endpoint. Nothing automatic.

Pricing decisions are not obvious and have no good defaults.

I priced everything at $0.10 USDC per call. That was a guess. The published x402 examples mostly use $0.01–$0.10. So I rounded.

The actual right pricing — per call vs per query depth, flat vs tiered, repeat-read pricing vs one-shot deeper analysis — I don't have data to make those decisions. Anyone telling you "here's the optimal x402 pricing curve" is making it up. The market is too young; there isn't enough traffic across enough endpoints to know.

What I suspect, from the few thoughtful operators I've talked to: agents probably balk at high repeat-read costs but pay willingly for one-shot deeper analysis. So a flat per-call price under-monetizes deep queries and over-prices shallow ones. But that's a hypothesis, not data.

The Surprises

Cold outreach to other builders is a relationship game, not a sales game.

I sent fifteen-plus cold messages to other technical solo builders shipping MCP servers. Three replied substantively. Every single one of them treated me as a peer to compare notes with, not as a service provider to hire. That tells me something important about who the buyer for this kind of work actually is. The people who build this stack mostly want to ship their own — they don't outsource it. The people who don't build this stack are who you actually need to find.

That changes the whole shape of "who is this for." If you're considering shipping a paid MCP and you assume your audience is other developers — it probably isn't. It's whoever has the data and doesn't want to learn five new pieces of infrastructure to expose it.

Marketplace listings are necessary but not sufficient (and the listings themselves take real work).

Every directory has its own submission process, its own JSON schema, its own review timing. Glama wants one set of metadata, Smithery wants another, mcp.so wants a different schema, mcp.directory has yet another. Each takes 30 minutes to an hour to do well. You can do this part wrong and tank your discoverability before you even start.

There's a real opportunity for someone to build the "list-everywhere" tool for MCP servers and capture the friction. I'd buy it.

The technical buyer and the operational buyer are different people.

If you're shipping this stack, you're going to talk to two kinds of people in cold conversations: technical builders who want to compare notes (peers), and operational/data-owner people who want to know if their data could earn from agents (potential buyers). The conversation feels almost identical from the outside, but the buying intent is completely different. Learn to tell them apart early or you'll spend weeks confused about why "great conversations" aren't producing customers.

What I'd Do Differently

If I were shipping this stack fresh today, three changes:

Wire x402 first on a stub tool, before the data ingest works at all. Get the payment loop end-to-end on a hello world endpoint. See the receipt. Then layer the actual data work on top. Most of the painful debugging I did was in the payment loop, which I tried to wire last.
Abstract the facilitator integration thin. Treat the response shape as a moving target. Don't depend on specific Coinbase or PayAI quirks.
Treat distribution as part of "shipped," not "what I'll do next." Write the dev.to post the same day you push the v1. Submit to all four directories the same day. Don't let "I'll do the marketing tomorrow" become "I shipped two weeks ago and nobody knows."

Who This Might Be For

I'm writing this post for two kinds of reader.

If you're a builder considering shipping a paid MCP — most of the above is the stuff I wish someone had told me. The build is the easy part; the post-ship grind is the work.

If you're a data owner — you have a useful dataset, you've thought about whether AI agents would pay to access it, but you don't want to learn five pieces of infrastructure to find out — I'd genuinely like to hear what you're sitting on. ForgePoint Signal is still live at forgepointsignal.com, the source is on GitHub, and the easiest way to reach me is here or on dev.to. I've spent the last two weeks watching the friction points up close. There's a real chance the pattern fits your data and you'd never have to learn what x402 means.

That's it. Two weeks in. Glama still shows zero. The work continues.

Shipping Paid MCP Tools on Base Mainnet: the Build Pattern and What I Got Wrong

Randy Rockwell — Thu, 07 May 2026 14:38:04 +0000

A couple of months ago I shipped ForgePoint Signal — a regulatory monitoring MCP server with x402 micropayments on Base mainnet. The first post was about what I built and how. This one is the harder one: what I learned, what I got wrong, and the part of the build that's actually portable.
If you're sitting on a data feed and wondering whether you can monetize it directly to AI agents — this is for you.
The Build Pattern
Strip the domain off Signal and what's left is a five-step pipeline anyone with a useful data source can run:
public/private data source
↓ (GitHub Actions cron)
Claude — parse + summarize + classify
↓
Supabase — idempotent storage, keyed on source URL
↓
MCP server — hosted on Vercel, exposes tools
↓ (x402 middleware)
USDC payments on Base mainnet — no API keys, no accounts
That's it. Five layers. Each one is independently swappable. The cron can be GitHub Actions, AWS EventBridge, a hosted scheduler — whatever. The parser doesn't have to be Claude. The store doesn't have to be Supabase. The MCP layer is standardized by spec. The payment layer is x402, which is itself protocol-agnostic about the chain underneath.
What makes the pattern interesting is that it's the first time I've shipped infrastructure where the payment is the auth. No signup flow. No API key issuance. No Stripe webhook reconciliation. An agent calls a tool, the server returns 402 with the price, the agent signs a USDC transfer, retries with the payment header, gets the response. The user never logs in. The agent never asks for credentials. The whole identity question collapses into "did this wallet pay."
Three Things That Surprised Me
Middleware ordering matters more than the docs make it sound.
The x402 verifier has to run before the MCP tool dispatcher. Run it after, and you end up either letting unauthenticated calls through on retries or double-charging. I got this wrong on the first deploy — saw the symptom before I understood the cause. If you're wiring this yourself, draw out the request lifecycle on paper before you trust the framework defaults.
Per-call price elasticity is non-linear.
I priced everything at $0.10 USDC and assumed agents would just pay or not pay. What I'm actually seeing: agents balk at >$0.05 on repeat reads of the same data, but happily pay $0.50+ for a one-shot deeper analysis. Repeat-read pricing and one-shot analysis pricing are different products and probably want different price points. Most pricing writeups I've read assume flat-rate. That's not what the data on a live mainnet endpoint shows.
Discoverability is the real grind, not the build.
The pipeline took roughly two weekends. Getting agents to actually find and call the server — getting it listed in Smithery, mcp.so, Glama, mcp.directory, the x402 ecosystem registry — has been a much longer slog. Anyone telling you "ship and they will come" is either lying or has an audience already. The build is the easy part.
What I Got Wrong
The first version of this project was positioned for estate attorneys. Federal Register monitoring, parsing changes that affect estate planning practice, charging a subscription. The technical artifact shipped fine. The positioning didn't. Estate attorneys aren't the people who naturally end up on a dev.to post about MCP servers. They're not the people who comment on x402 GitHub discussions. They don't read the IndieHackers feed.
The actual people who keep showing up — in comments, in DMs, in GitHub issues I land in — are other technical solo builders sitting on their own data feeds. They built something, they shipped an MCP wrapper, they're staring at the monetization layer wondering whether to use Stripe or x402 or punt on the question entirely. They're me, six months ago, with a different dataset.
That changes the posture. Signal stays running because it's a working production proof of the pattern, not because it's a product. The thing I'd actually want to help build is the next version of your monetized data feed.
What's Reusable
The skeleton in this repo is roughly 80% portable to any public-data domain:

The cron + idempotent storage layer is general-purpose
The Claude parse step needs domain-specific prompts but the structure transfers
The MCP server scaffolding is identical across projects (the spec is what makes it identical)
The x402 middleware is identical across projects
The deploy pipeline (Vercel + Supabase + GitHub Actions) is the same

What's not reusable is the domain knowledge — what counts as a useful signal in regulatory tax data is different from what counts as useful in, say, sports stats or scientific paper deltas or municipal procurement filings. That's the actual insight you bring.
What I'd Do Differently
If I were shipping this stack again from scratch:

Wire the x402 middleware first, before the data ingest works at all. Build the payment loop end-to-end on a stub tool that returns "hello world." Get the receipt. Then layer the actual data work on top. Most of the painful debugging I did was in the payment loop, which I tried to wire last after the data was already flowing.
Cache the facilitator response shapes. The Coinbase facilitator and PayAI facilitator emit subtly different schemes; if you switch between them later you'll be glad you abstracted the parsing.
Write the discoverability tasks (registry submissions, MCP client config snippets, post drafts) into the same checklist as the deploy. Treat distribution as part of "shipped," not "what I'll do later."

If You're Building This Too
If you're reading this because you're shipping or considering shipping a similar stack — cron + parse + MCP + x402 — I'd genuinely like to compare notes. What's your data source? Where are you stuck? What facilitator are you using? Drop a comment, or hit me on dev.to.
ForgePoint Signal is still live at forgepointsignal.com. The MCP endpoint is at forgepointsignal.com/mcp. preview_regulations is free; the rest are metered at $0.10 USDC on Base mainnet. If you want to point your own MCP client at it as a reference and watch a real x402 payment loop, that works.
Tools list, if you're plugging it into Claude Desktop or any MCP client:

preview_regulations — free
get_recent_regulations
get_regulation_detail
search_regulations

Connection config:
{"mcpServers":{"forgepoint-signal":{"url":"https://forgepointsignal.com/mcp"}}}

How I Built a Regulatory Monitoring MCP Server with x402 Micropayments

Randy Rockwell — Fri, 24 Apr 2026 13:04:24 +0000

The Federal Register publishes hundreds of regulatory changes every day. For estate attorneys, that firehose is mostly noise — a Treasury technical correction on valuation discounts matters; a routine notice of meeting does not. And for AI agents trying to answer "what changed in federal estate tax law this week," there's no clean API. You're stuck scraping PDFs, parsing dense legal prose, or paying for walled-garden legal research platforms that cost more than they're worth for a single question.

I built ForgePoint Signal to fix that. It monitors federal estate, gift, trust, and inheritance tax changes, parses them into structured summaries, and exposes everything over MCP so agents can query it directly. Some tools are free, the rest cost 10¢ per call in USDC — no signup.

What I Built

Ingest — A GitHub Actions cron runs daily. It pulls estate-tax and gift-tax documents from the Federal Register API and the IRS Internal Revenue Bulletin, then dedupes on document number.

Parse — Claude extracts a plain-English summary, impact level (low/medium/high), and effective date for each document.

Store — Results go into Supabase, keyed uniquely on source URL so the cron is idempotent.

Serve — A Vercel serverless function hosts the MCP server. Paid tools are gated with x402 — $0.10 USDC on Base mainnet.

The MCP Server

Four tools. One free, three paid. Here's the one agents use most:

{
  "name": "search_regulations",
  "description": "Search the full ForgePoint Signal regulatory database by keyword, jurisdiction, category, or impact level. Returns full entries with plain-English summaries and source links. Updated daily."
}

How x402 Works

Agent calls a paid tool. No payment attached.

Server returns 402 with payment requirements — $0.10 USDC on Base, 120 second window.

x402 client signs a USDC transfer and retries with an X-PAYMENT header.

Server verifies via x402 facilitator, executes the tool, returns data with a receipt header.

No API keys. No accounts. No Stripe webhooks. The payment is the auth.

How to Connect It

{"mcpServers":{"forgepoint-signal":{"url":"https://forgepointsignal.com/mcp"}}}

Drop that into any MCP client — Claude Desktop, Cursor, Cline. preview_regulations is free. Everything else is metered at $0.10 USDC.

What's Next

A human dashboard with full-text search and email alerts. A $199/month Stripe tier for users who don't want to think in micropayments. More data sources — IRS Internal Revenue Bulletin, state revenue departments, Tax Court opinions.

Try It

Live now at forgepointsignal.com. Point any MCP client at the endpoint and call preview_regulations — no wallet, no key, no signup required.