Every Model Context Protocol tutorial ends at the same green light: a stdio server running on localhost, the Inspector showing all checks passed, and the author waving you off toward “production.” Then the tutorial stops — right where the actual work begins. The gap between that demo and a server you can charge money for is the whole job: transport, hosting, billing, distribution. Crossing that gap twice — once per product — surfaced something: the second time, I was copying the same scaffolding rather than rethinking it. That’s the signal a pattern is stable enough to extract. Today it’s open source as mcp-server-apify-starter — MIT licensed, on the Godberry Studios GitHub org.

What the starter actually gives you

Fork it, swap the example tools, deploy in an afternoon. The wiring is done:

  • Transport: Streamable HTTP on POST /mcp. stdio is fine for Claude Desktop on your machine; for remote callers you need the HTTP transport, and the spec deprecated standalone SSE back in the 2025-03-26 revision. The starter uses the official @modelcontextprotocol/sdk TypeScript package so you inherit correct framing, session handling, and error shapes for free.
  • Hosting: Apify Actor with Standby mode enabled. Standby keeps the container warm for low-latency calls and scales to zero when idle, so you pay platform fees only for real traffic. No VPS, no Docker orchestration, no K8s.
  • Billing: chargeEvent('your-event-name') wrapper around Apify’s pay-per-event API. Configure pricing in .actor/pay_per_event.json, call chargeEvent at the top of each paid tool, and Apify bills the caller’s account. No Stripe integration, no webhook reconciliation, no dunning.
  • Distribution: the Apify Store is the discovery surface. You push with apify push, users find you in-store, and they authenticate with their own Apify API token as a bearer header. Any MCP client that speaks Streamable HTTP — Claude Desktop, Claude Code, Cursor, Cline, custom agents — can call it on day one.

One free tool and one paid tool ship in the box so you can see both patterns at once. word-count is the free one — fast, cheap, no billing. summarize-text is the paid one — calls the Anthropic API under a chargeable event, fixed price per call. Replace both with your own.

The pattern I’m encoding

The starter is opinionated in one place: every paid tool should have a free neighbor. Cheap reads build trust. If an agent can extract-preview before paying for transform, or validate before submit, friction drops and conversion goes up. Agents hedge too — they’d rather pay for summarize once count-words confirms the document is long enough to warrant it.

The second opinion is charge before the expensive work:

await chargeEvent('summarize-text');
const result = await callAnthropic(input);
return result;

Flip the order and you give free compute to users whose billing failed. That’s a silent leak on anything that hits a paid upstream API. chargeEvent throws if the account can’t pay, so the expensive call never runs.

Why Apify and not Vercel + Stripe

Fair question. Vercel + Stripe (or the newer x402 protocol) is where a lot of the MCP ecosystem is headed, and a starter for that pattern is planned as a follow-up. But for a solo developer shipping their first paid MCP server today, Apify wins on three specific things:

One, the billing rail is already there. No Stripe account, no SCA handling, no webhooks for invoice.paid, no reconciling failed charges. You call chargeEvent and Apify takes care of the rest — weeks of saved work if you’ve never built payments before.

Two, the Actor model maps cleanly to MCP tools. An Actor is a function you invoke with input and get output from. So is an MCP tool. Standby mode bridges the two — one warm process, many tool calls, per-call billing. You’re not fighting the platform.

Three, the Store is a distribution channel. People browse apify.com/store looking for actors to solve a problem. If your MCP server solves one, you get organic traffic without running ads. A self-hosted MCP server has zero discovery surface until you build one.

The tradeoff: you’re on Apify. If they change the economics or the product direction drifts away from you, you migrate — and because the tools are plain SDK handlers, that migration is the host and the billing call, not the logic. For me, time-to-first-paying-user beat the lock-in risk. Your math may be different.

What this starter is not

  • Not a general-purpose MCP SDK. For full control, use the official TypeScript SDK directly and host anywhere.
  • Not Stripe or x402. Those are separate starters with different tradeoffs. This one uses Apify’s built-in billing because it’s the fastest path to paying customers today.
  • Not an agent framework. One server, one job, composable. Keep it small, ship it, let agents compose it with other servers.

The production receipts

Two live servers run on this exact pattern:

Both were scaffolded from the same code that’s in the starter. Releasing it now is a deliberate choice: with the second product shipped, the pattern had stopped changing — and a scaffold you stop editing is a scaffold worth giving away instead of rebuilding from scratch the next time.

How to use it

git clone https://github.com/godberrystudios/mcp-server-apify-starter.git
cd mcp-server-apify-starter
npm install
npm run dev            # local dev on port 4321
npm run inspect        # MCP Inspector in the browser
apify push             # ship it

The README walks through replacing the example tools, configuring event pricing, and deploying to Standby mode with the right environment variables. For the deeper question of what to charge and which pricing model to pick, there’s a full MCP server monetization playbook covering per-call, subscription, freemium, and outcome-based models with real revenue numbers. If you get stuck on the starter itself, open an issue on the repo — Discussions is enabled too.

What I’d like back

If you’re building a pay-per-use MCP server from scratch today, fork the starter first — it gets you to the part where you’re actually differentiating your product faster. Then two asks: ship something with it and email hello@godberrystudios.com with the link, so other devs can see the pattern in real use; and if you hit a rough edge, open an issue before working around it. The value of a starter is in what it leaves out, so the bar for merging is high — but the bar for discussing is zero.

Godberry Studios is a one-person studio in Lithuania — that’s me, Tomas. I ship MCP-native tools and write about the agent economy. Browse the work on GitHub or follow along on the blog.