How to Build a Paid MCP Business With Stripe and Cloudflare

Stripe shipped an agent SDK last month that lets you attach a price ID directly to a tool call, which means the first time an unpaid user invokes your AI tool they see a payment link and a clear reason to upgrade, not an error message and a wall of documentation. I am Madhuranjan Kumar, and this is worth unpacking because it solves a problem that has quietly killed most knowledge-as-a-product businesses before they ever got traction: the gap between someone being interested in your expertise and them actually paying for it in a frictionless way. MCP, the protocol layer that lets AI agents reach into external systems, is the distribution channel. Stripe is the payment layer. Cloudflare is the hosting infrastructure. Together, they make it possible for anyone with deep domain knowledge to package that knowledge as a paid tool that any AI agent can call on demand, without a sales call, without a support ticket, and without requiring the buyer to set up a separate account before seeing any value.

The Distribution Problem That Has Killed Most Knowledge Businesses Online

Every professional who has ever tried to sell their expertise digitally has hit the same wall in some form. The knowledge is real and valuable. The potential buyers exist. But the path from interest to payment is full of friction: the potential buyer visits a site, decides whether to trust it, signs up for an account, enters payment information, receives credentials, configures an integration, and then maybe sees the first useful output. At each step a percentage of interested people drop off. By the time the paying user gets to the value, the funnel has filtered out a large share of the people who would have paid if the path had been shorter.

Most MCP servers have this problem in an especially severe form. The standard setup requires a technical user to install a local server, configure environment variables, manage API keys, and maintain the connection manually. Even for a technically sophisticated audience, that setup cost is enough to prevent casual adoption. For the broader audience of business owners and professionals who use AI tools without managing the underlying infrastructure, it is simply inaccessible.

The paid MCP model via Stripe and Cloudflare fixes the distribution problem at the protocol layer. Because the server runs on Cloudflare Workers rather than locally, the user does not install anything. Because the payment is embedded in the tool call rather than gated before it, the user experiences the tool before paying rather than paying before experiencing it. The friction that drops the conversion rate is removed at the moment where it matters most: the transition from curious to committed.

This is a meaningful shift for anyone who has built knowledge-based products before, tried them in content form or consulting form, and struggled with the conversion problem. The problem was rarely the knowledge. It was the path from interest to transaction. MCP with embedded payments shortens that path to its minimum viable length.

The Payment Layer: Attaching a Price to a Tool Call Without Breaking the Flow

The technical implementation follows a clean pattern. Cloudflare's MCP agent class lets you define any function as a tool with a name, a description of what it does, an input schema, and the logic to execute when the tool is called. This is the standard MCP tool definition: nothing unusual about it. The Stripe layer adds two additional properties to the tool definition: a price ID that maps to a product in your Stripe dashboard, and a payment reason string that will be shown to any user who calls the tool without having paid.

When an unpaid user's AI agent calls the tool, the response is not an error. It is a structured message containing a payment link and the reason string explaining what the upgrade unlocks. The AI agent can display that message inline, so the user sees the paywall inside their existing workflow rather than being redirected to an external site and losing their place. They pay, the Stripe webhook confirms the payment, and the next call to the same tool succeeds. The entire interaction happens within the AI environment the user is already in.

For pricing structure, usage-based billing fits the MCP model better than flat subscriptions because the costs of running the server scale with calls. Different tools may invoke different underlying models at different costs, and those costs vary based on input length and output complexity in ways that are difficult to predict at a flat rate. Usage-based pricing means the revenue scales with the value being delivered rather than requiring a guess upfront about what the right flat fee is. A Stripe meter is the mechanism: it counts events as the tool is called, and the invoice calculates automatically based on accumulated usage. The tier structure can include a free starting allocation, a paid bundle, and a per-unit rate beyond the bundle, giving users flexibility while keeping your billing automated.

For any business that currently provides Facebook and Instagram ad campaigns management or Google Ads optimization as a service, the MCP model opens the possibility of packaging specific repetitive parts of that work, such as ad copy scoring, audience overlap checking, or creative compliance validation, as automated tools that clients or other agencies can call on demand at a per-use price. The expertise is the same. The delivery mechanism scales without scaling the time cost.

The Meter: Usage-Based Billing That Scales With the Value You Actually Deliver

The Stripe meter deserves a closer look because it is what makes the business model work at scale without requiring manual invoice management or complex subscription logic. A meter in Stripe is a counter that receives an event each time a specified action occurs. In the MCP context, you configure the tool to emit a meter event each time it runs successfully, and Stripe increments the counter associated with that user's billing record.

At the end of the billing period, Stripe calculates the invoice based on the accumulated meter count and the pricing tiers you have defined. A three-tier structure might look like: zero cost for the first five calls in a month, one dollar per thirty calls in the first paid bundle, and two cents per call beyond the bundle. These numbers are illustrative, and the right rates depend on the value the output provides and the cost of the underlying model calls, but the structure is consistent across most successful metered tools: a free allocation to lower first-use friction, a bundle that rewards commitment, and a per-unit rate that scales with heavy use.

The meter also provides useful operational data. You can see which users are approaching their free tier limit, which is a natural trigger for an upgrade prompt, and which users are the heaviest consumers, which identifies your best candidates for premium tier offers or enterprise relationships. This kind of behavioral data about actual usage is more predictive of future revenue than any demographic information, because it reflects observed behavior rather than stated interest.

The Email Moat: Why the OAuth Signup Step Is Worth More Than the First Month's Revenue

The authentication layer in the paid MCP stack is Cloudflare's OAuth provider class combined with a user account system, and it serves a purpose that goes well beyond access control. Because MCP servers serve multiple different client environments, including Cursor, Claude Desktop, and other AI tools, they use OAuth as the standard authorization protocol. The user grants access by going through a login flow rather than pasting a static API key, which is the right security pattern for a shared protocol.

The operational mechanism for signup in this setup is Supabase with a six-digit one-time password by email. The OTP approach delivers reliably and lands in the inbox rather than the spam folder more consistently than magic links do on cold email addresses. But the significant consequence of requiring this login step is not the security it provides. It is the email address it captures.

Every user who connects to your MCP server, including users who are still in the free tier and have not paid yet, completes the OAuth flow. That flow captures their email. The result is a list of people who raised their hand for your tool by the act of connecting to it, which is a stronger signal of genuine interest than a newsletter subscriber who clicked a button once. That list grows every time a new user connects, and it can be used for upgrade prompts, new tool announcements, educational content about the problem domain your tool addresses, and direct outreach about higher-value related services.

For a knowledge business where the paid MCP is the entry-level offer, the email list built through mandatory OAuth signup is the pipeline for the higher-value offers. The accounting firm running a receipt categorization MCP at one dollar per thirty uses is building a list of small business owners who have already demonstrated they will pay for automated bookkeeping help. That list is the warm audience for a full-service bookkeeping engagement, a quarterly tax estimate service, or an annual financial review package. The MCP is the top of funnel. The email capture is the mechanism that makes the funnel closed rather than open.

The Free Tier and the First Call Are the Same Decision

A free tier on a paid MCP is not a concession. It is the mechanism that converts curious users into paying ones. The first call to a tool is the highest-friction moment in the user journey, because it requires both technical setup and a decision to invest time in something unknown. A free allocation of five calls removes the payment decision from that first moment and replaces it with a pure experience decision. Does this tool produce useful output? Five free calls answer that question at zero cost to the user and near-zero cost to the operator.

The conversion from free to paid happens most reliably when the user runs out of free calls in the middle of a task that the tool has already proven useful for. At that moment, the payment is not a leap of faith. It is a continuation of something already working. The payment link in the unpaid call response, combined with the reason string explaining what the upgrade unlocks, arrives at exactly that moment and converts at a substantially higher rate than a cold pricing page would.

Setting the free tier allocation requires balancing two things: giving enough free uses that the user can genuinely evaluate the tool, and not giving so many that the typical light user never has a reason to upgrade. For most specialized tools with a clear professional application, five to ten free uses per month is the right range. For tools where the value is visible on the first use, three free uses may be sufficient. For tools where the value accumulates over multiple sessions, a slightly larger free allocation gives users time to build the habit before the payment decision arrives.

The mcp-remote package handles the Cursor login UX specifically, prompting the user to sign in through a browser when they first connect. Swapping the connection command to npx mcp-remote and providing the server URL is the entire change on the client side. The rest of the auth flow is handled server-side by the OAuth provider and the Supabase OTP logic.

How an Accounting Firm Packaged Expense Categorization and Built a Lead List

Let me make the model concrete with a worked example. Consider an accounting firm that handles small business clients across several industries. The most time-consuming part of the monthly close for every client is receiving disorganized expense data, often a mix of photos of paper receipts, PDF bank statements, and manually entered notes, and converting it into a clean, categorized ledger. The firm's staff spends significant time on this every month, and the clients dread the process of compiling and submitting it.

The firm could package the core intelligence of that categorization process as an MCP tool: a server that accepts a batch of raw expense descriptions or a PDF bank statement upload, applies the firm's actual categorization logic including industry-specific nuances and the client's specific chart of accounts, and returns a structured JSON output ready for the bookkeeping software. The tool is not general purpose. It is trained on the firm's real categorization patterns and embeds the professional judgment the firm applies to common edge cases.

The pricing structure follows the free-then-paid pattern. Five free categorization runs per month for a new user, then one dollar per thirty-run bundle. The OAuth signup captures the email of every small business owner who connects. The tool runs on Cloudflare Workers at negligible cost per call once built.

To illustrate the revenue picture at a realistic scale: if the tool reaches two hundred connected users after three months, with half of them converting to paid usage averaging one bundle per month, the recurring revenue is one hundred dollars times one dollar, or one hundred dollars per month. At five hundred users with the same conversion rate and usage pattern, that is two hundred fifty dollars per month in direct tool revenue.

That number is not the point. The point is the email list. Five hundred connected users, including the free-tier ones, is five hundred small business owners who have demonstrated they will invest time in automating their bookkeeping. That is a warm audience for the firm's full-service monthly bookkeeping engagement at a significantly higher price point. If even five percent of the five hundred users convert to a full-service engagement over twelve months, and the engagement is worth two thousand dollars per year per client, the tool has generated fifty thousand dollars in full-service revenue from an asset that costs almost nothing to operate.

The SEO and organic search implications of publishing this tool and its documentation are also worth noting. A firm that has a documented, publicly accessible AI tool for a specific professional use case builds a form of credibility and discoverability that general marketing does not produce. The tool is the content that surfaces in searches for the problem it solves, and the OAuth signup is the conversion mechanism attached to that content.

The full stack, Cloudflare Workers for hosting, Stripe for metered billing, Supabase for auth and OTP, and mcp-remote for the Cursor connection UX, has real moving parts that require careful integration to work correctly end to end. The auth flow, the payment webhook, the meter event emission, and the free tier tracking all need to work together without gaps. You can assemble this yourself if you are comfortable with API integrations and have a focused week to work through the setup. If you would rather have the infrastructure built correctly from the start and handed over working, that is the kind of technical build I take on for clients who want to ship a paid MCP without the integration overhead.