Can You Monetize MCP Servers? 4 Revenue Models, Plus Marketplace Fees and Payout Terms Checked Against the Sources

Can you make money with an MCP server? The answer is yes, but the MCP spec itself has no billing mechanism, so you have to choose and build in the way you get paid yourself.

A number circulates widely online: "12,000+ public MCP servers, fewer than 5% successfully monetized." But when you trace it back, the original study cannot be found. So this article does not use it. In its place we use our own count of the official registry, the MCP specification itself, and the marketplaces' own terms and documentation. Everything was checked on September 30, 2026.

1. How many MCP servers are there? It depends on who counts

Start with the size of the market. Line up four numbers that count different things and you see they do not even agree on the order of magnitude.

The official registry only lets you publish after you prove you own the namespace (a GitHub account or a domain). That is a different population from directories that sweep up repositories broadly. Whenever you see "there are N MCP servers," the first question is who counted what.

Can we then count how many of them earn money? The official registry's metadata (server.json) holds a name, description, version, package location, remote URL and so on; the official description lists no price field. Whether a server is paid, or how much it sells, cannot be read from official data. If you see a confident "X% have monetized," check what was counted and how before you rely on it.

What we can say is this: with MCP, choosing how you get paid is harder than building the server. The reason is in the spec, covered next.

2. Why MCP drifts toward "free": what the spec has and lacks

There are three structural reasons MCP servers tend to be given away.

• 1. The protocol is open: In December 2025, MCP was donated to the Agentic AI Foundation (AAIF), a fund set up under the Linux Foundation (Anthropic's announcement). Anyone can implement it, so the only way to differentiate is the data and logic your server delivers
• 2. Easy to copy: Publish your server's code and anyone can build the same thing. Being open source works against exclusive revenue
• 3. No billing standard in the spec: The MCP spec covers connecting and authorizing, but says nothing about prices, payments or usage metering (table below)

Here is point 3 checked against the source. The table reflects the latest spec (Authorization, 2026-07-28 revision) and the index of the official docs (llms.txt).

In other words, to get paid you need a mechanism outside MCP. There are two broad ways: (a) tie usage to an account on your own service (OAuth or an API key) and meter and bill on your side, or (b) list on a marketplace that bundles payments, auth and hosting. The four patterns in the next section are easiest to read as combinations of these two.

3. The 4 monetization patterns

The ways to get paid for an MCP server fall into four types.

Pattern 3, the API-key model, is clearest when you read the providers' own docs. In every case the MCP server itself has no price tag: you try it on a free tier, then pay for the underlying API.

The strength of this model is that the lack of a billing standard in MCP does not hurt it. Billing runs on the API machinery the company already has, so the MCP server can simply be the entrance. The flip side: a solo developer without a sellable API cannot copy it as is.

4. Where to sell: fees and payout terms compared

Once you know how you will earn, the next question is where to sell. Below are fees and payout terms taken from each company's own terms and docs (all retrieved 2026-09-30; terms change, so reread the source before you list anything).

A worked example. Sell one $10 monthly subscription: on MCPize you keep $8 (the 20% fee includes Stripe processing; payout fees may apply separately). On your own site with Stripe Billing, taking Japan's 3.6% card fee as an example, $10 minus 3.6% and 0.7% leaves about $9.57 (our calculation; currency conversion adds another fee). The gap is about $1.57, but on your own site you carry hosting, tax, refunds and support yourself. The deciding question is the fee difference versus the weight of the work you take on, and the answer flips with your revenue and with what infrastructure you already have.

Judging from their public pages, Smithery and Glama are realistically places to be discovered rather than places to sell. Treat where you sell and where your traffic comes from as separate decisions.

5. Named examples: who actually said the number?

Success stories like "X hit $10K a month in six weeks" are everywhere, but few can be traced back to the person or company. This table keeps only what we could trace to the speaker or a primary page.

Two things stand out. (1) Examples where MCP ships as part of an existing paid service are far easier to verify than ones that put a price on an MCP server alone. (2) The examples that do sell servers on their own sit on top of platforms that take over payments and payouts, like Apify and MCPize.

6. Why servers fail to earn: common failure patterns

There is no primary data on "what percentage fail." But the spec and the terms above make the structure that keeps servers from earning quite clear.

They share one root: the assumption that "if it is useful, someone will pay." MCP is useful, but the spec only takes care of the connection. How you get paid is something you must choose yourself, from the start.

7. The solo developer playbook

If you want to try MCP monetization as an individual today, here is a realistic sequence.

1. Pick a niche (the most important step)

Avoid generic tools like "an MCP that integrates with every SaaS." Aim for "a specific industry × a specific task". Examples: "accounting-software integration for bookkeeping firms," "reading property title documents for real estate," "summarizing appointment data for dental clinics." The narrower it is, the clearer your buyer and the easier it is to charge.

2. Choose how you get paid first

As section 2 showed, the MCP spec has no billing standard. So decide at v0.1 which of these you will use:

• Let a marketplace handle it: MCPize (20% fee, Stripe processing included) or Apify Store (80% of revenue minus run costs). They take over payments, payouts and hosting
• Own it yourself: add OAuth 2.1 authorization to a remote MCP server (following the spec's Authorization section) and bill through your own accounts and Stripe. Fees are lower, but you build everything, metering included

Avoid "launch free, add pricing later": it means retrofitting authorization.

3. Document with video and text

Turn "why you need it → what it does → start in three minutes" into a short screen recording. Connection setup differs by MCP client, so setup examples for each major client in the README cut down on support questions.

4. List in the official registry and in directories

The official MCP Registry is positioned as the upstream source that directories and marketplaces pull from. To publish, you prove ownership of your namespace via GitHub, DNS or an HTTP challenge. Two cautions: once published, a server cannot currently be deleted or unpublished, and metadata for a given version cannot be changed afterwards (you publish a new version number instead), per the official FAQ. Then list in directories such as Smithery, Glama and PulseMCP too. Where you sell and where you get discovered are separate.

5. "Live" in the community

Post updates and usage examples regularly in the official MCP repositories' discussions, MCP communities and on X. Spec revisions and new extensions surface there first, which also helps you avoid failure pattern 4.

6. Set a deadline and keep going

It is common to see no results in the first few months. But do not drift either: set your own target of "N paying users by date X", and change niches if you miss it.

8. Enterprise strategy: MCP as part of the product

Solo developers and companies play entirely different games. For companies, the standard move is not to earn from the MCP server alone but to offer MCP as a front door to an existing SaaS.

Typical examples:

• Notion / Linear / Sentry / Stripe: ship official MCP servers so existing users can operate the product from AI. The goal is keeping customers on the core service
• Bright Data / Exa / Tavily: use MCP as a new storefront for search and scraping APIs. Let people try it on a free tier, then bill for API usage (table in section 3)
• AI model providers: do not charge for MCP itself, but the more MCP enables, the more their models and APIs get used, an indirect revenue stream

All of these follow the same pattern: ship MCP for free and route people to the paid core service. For companies, it helps to think of MCP as a new customer-acquisition channel.

9. Changes worth watching

Rather than guessing market size years out, it is more useful to track moves that could change the premises. As of September 30, 2026, these are visible:

• Whether billing enters the spec: neither the current spec nor the official extensions (MCP Apps, authorization extensions, Tasks, Skills) handle prices or payments. An extension mechanism exists, so a billing extension would change the picture. Keep an eye on the extensions list
• General availability of the official registry: it is in "preview," and the docs state that data resets or breaking changes may happen before GA
• Marketplace consolidation and changing terms: Smithery announces it is now part of Arcade.dev. MCPize raised its fee from 15% to 20% (for servers that started monetizing on or after 2026-06-10). Assume the terms of where you sell will change, and check the "last updated" date regularly

Conversely, billing outside the spec keeps working whatever the spec does. That stability is part of why companies choose pattern 3, billing through their own accounts and APIs.

Summary

• You can monetize an MCP server. But the MCP spec has no standard for prices, payments or usage metering (authorization is OAuth 2.1-based and optional), so you choose how you get paid outside MCP
• The "fewer than 5% of 12,000 have monetized" figure has no traceable publisher. The official registry has no price field, so the share of paid servers cannot be counted from official data
• Server counts vary by an order of magnitude: official registry 37,619 and Glama 94,143 (both 2026-09-30); Anthropic said "10,000+ active public servers" (2025-12-09)
• Four ways to earn: subscription / pay per use / API key / freemium. The easiest successes to verify are API-key models that front an existing paid API
• Where to sell: MCPize (20% fee; 15% for servers that started before 2026-06-10) / Apify Store (80% of revenue minus run costs) / your own site + Stripe (card fee varies by country, e.g. 3.6% in Japan, plus 0.7% for Billing). Smithery and Glama are places to be discovered
• Solo playbook: narrow niche + choose how you get paid first + video docs + list in the official registry and directories + keep posting + set a deadline
• Enterprise strategy: ship MCP for free as a front door to your SaaS and route revenue to the core product

MCP is becoming an infrastructure layer, like HTTP or OAuth. Charging for infrastructure itself is hard. But you can build a house on top of it, payment plumbing included.

FAQ

Q1. Can a programming beginner get into MCP monetization?

Yes, with conditions. Using the official Python or TypeScript SDK, getting a working server running is not hard. But the gap between "a server that works" and "a server that can take payments" is large. Leave authorization and billing to a marketplace (MCPize, Apify and so on), and the realistic route is to first build something you use in your own work, gather feedback from real users, and then start charging.

Q2. Your own site + Stripe, or MCPize?

On fees alone your own site is cheaper (Stripe's card fee varies by country, e.g. 3.6% in Japan, plus 0.7% for Billing, versus MCPize's 20%). But MCPize's 20% includes payment processing, hosting and tax handling, all of which you carry yourself on your own site. Decide by whether the fee difference exceeds the cost of the work you take on. A common approach is to start on a marketplace while revenue is small and move to your own site as it grows, but moving means asking users to redo their connection and authorization.

Q3. What about open source plus paid support?

It works; it is the same model as paid support for Linux distributions. But it is hard for a solo developer: support eats your time and development stalls. As a side project, subscription or pay-per-use suits you better.

Q4. Can an MCP server that competes with an existing paid SaaS (like Notion) make money?

In principle, it is tough. When Notion ships its own official MCP server, building something more convenient is hard. Filling gaps the official one does not cover (advanced analytics, industry-specific templates, more integrations) is where there is a chance.

Q5. If I list in the official MCP Registry, can I sell there?

No. The official registry is a place for server metadata, with no price field and no payment mechanism. The official docs say its main consumers are downstream aggregators such as directories and marketplaces. The division of labor is: sell through a marketplace or your own site, and use the official registry as one of the entrances where people find you.

Q6. If AI starts generating MCP servers automatically, will developer income disappear?

"Servers that merely work" will be generated automatically. "Servers users trust" are another matter. Uptime guarantees, support, domain expertise, keeping up with spec revisions: AI generation alone does not deliver these. The likely split is "AI builds the first working version; humans run, improve and earn trust."

Q7. If I were starting MCP monetization, what would I do in the first week?

Three steps:
(1) Pick one niche (narrow it to your industry, hobby or area of expertise; very narrow is fine)
(2) Decide how you get paid (read MCPize's and Apify's terms in the original, or go with your own OAuth + Stripe), and get a minimal server running
(3) Publish to the official registry and to directories like Smithery, Glama and PulseMCP, and announce it on X
That is one week. If no paying user shows up by your own deadline, change the niche and start again from (1). The number of attempts is what moves the result.