Comparison

Tollwicket vs. RevenueCat for MCP servers: a positioning comparison

RevenueCat is the default subscription layer for mobile apps. Tollwicket is the equivalent for MCP servers. Here's how they differ and which one fits your use case.

See Tollwicket pricing →

If you've shipped a mobile app, you've probably used RevenueCat. It's the de-facto subscription SDK for iOS and Android — a thin layer on top of App Store / Play Store / Stripe that handles entitlements, paywalls, and analytics.

Tollwicket is built on the same idea, but for MCP servers. Same shape: a thin SDK on top of an underlying payment processor (Stripe in our case) that handles the subscription logic an app author shouldn't have to build from scratch.

If you're evaluating both — or wondering whether RevenueCat itself could work for an MCP server — this page is the comparison.

The short answer

Use RevenueCat if you're shipping a mobile app and need subscription infrastructure on the App Store and Play Store.

Use Tollwicket if you're shipping an MCP server and need subscription infrastructure on top of Stripe.

They are not direct competitors. They serve different surfaces. Most teams don't need both, but some do — you might use RevenueCat for your iOS app and Tollwicket for the MCP server that powers it.

Where they overlap conceptually

Both products solve the same shape of problem:

Identity → entitlement mapping. Given a user, what plan are they on?
Quota / feature gating. Given an entitlement, can the user do X?
Receipt validation. Given a payment from the underlying processor, did it actually happen?
Plan changes. Upgrades, downgrades, cancellations, all kept in sync.
Analytics on subscription health. Conversion rate, churn, ARPU.

In both cases, the value is removing the 1–2 weeks of plumbing work and the ongoing edge-case maintenance.

Where they differ

Aspect	RevenueCat	Tollwicket
Surface	Mobile apps (iOS, Android, web)	MCP servers
Payment processors	App Store, Play Store, Stripe, Amazon	Stripe (more planned)
SDK languages	Swift, Kotlin, React Native, Flutter, web	Python, TypeScript (more planned)
Paywall surface	UI components (sheets, modals)	Tool-call response strings
Identity model	Anonymous + login-linked user IDs	OAuth-on-first-use, MCP-aware
Pricing model	Free up to 2.5k MTR, then flat tier	Free up to $500/mo, then flat tier
Open source SDK	Yes	Yes

Why RevenueCat doesn't quite work for MCP servers

You could in theory use RevenueCat as your billing backend for an MCP server. We've talked to people who tried. Three things make it awkward:

The paywall surface is wrong. RevenueCat's paywall UI assumes a screen — sheets, buttons, hero images. An MCP paywall is a response string sent through an LLM. RevenueCat's strength on the UI side is wasted here.
The identity flow is wrong. RevenueCat's identity model assumes app installs map to users (with linking for cross-device). MCP identity is OAuth-mediated; users authenticate through a browser flow that returns to the MCP client. RevenueCat doesn't have first-class primitives for this.
The payment processor mix is wrong. RevenueCat's biggest value is wrangling Apple's and Google's stores. For an MCP server, neither matters — you're billing through Stripe, full stop. You'd be paying for infrastructure you don't use.

It's possible to bend RevenueCat into the shape of an MCP billing SDK, but the seams show.

Why Tollwicket doesn't quite work for mobile apps

Conversely, we don't recommend Tollwicket for shipping an iOS app. The reasons mirror the above:

We don't have iOS / Android SDKs and aren't planning them. Our SDK targets MCP server runtimes (Python, TypeScript).
We don't integrate with the App Store or Play Store. We only handle Stripe.
We don't have UI paywall components. Our paywall is a structured tool-call error, designed for LLM consumption, not for human-readable modals.

If your monetization surface is a mobile app, use RevenueCat. If it's an MCP server, use Tollwicket. If it's both, use both.

Pricing comparison

Both products use roughly the same business model: free up to a revenue threshold, flat tier after that.

RevenueCat: Free until $2,500/mo of monthly tracked revenue (MTR), then a percentage of revenue with a flat ceiling per tier.
Tollwicket: Free until $500/mo of customer revenue through your MCP server, then flat monthly tier based on which revenue bracket you're in. No per-call fees.

The pricing structures are intentionally similar — neither company gets paid until you do. The thresholds reflect the different revenue scales of the markets: mobile apps clear $2,500/mo more easily than early MCP servers.

When to use both

If you're shipping a product with both a mobile app and an MCP server (we've seen a few — productivity tools that have both a Mac app and a Claude integration), use both:

RevenueCat handles the iOS / Android / web subscription on the app side.
Tollwicket handles the MCP subscription for users coming in through Claude / Cursor / etc.

You can share identity across the two (a single user with subscriptions on both surfaces) by linking your internal user ID to both RevenueCat's appUserID and Tollwicket's customer_id. We provide an API for this exact use case.

Honest tradeoffs in choosing Tollwicket

Younger product. Tollwicket is newer than RevenueCat. We have fewer customers, less institutional knowledge, and the SDK API may still evolve. The upside: we're shipping aggressively and respond to integration feedback within days.
Stripe-only. Right now, Stripe is our only payment backend. If you need PayPal, BNPL, or Asian payment rails as a primary integration, we don't have them yet (PromptPay support is in development).
Smaller SDK matrix. Python and TypeScript only. Go and Rust SDKs are planned.

If those tradeoffs are dealbreakers, RevenueCat (for mobile) or Stripe-direct (for MCP, see our comparison) may be a better fit today.

What to do next

Building a mobile app? Use RevenueCat. Don't even evaluate us.
Building an MCP server? Start with Tollwicket free — no credit card, no time limit.
Building both? Use both, and reach out to us about cross-surface identity linking.