Selling Your MCP Server

You built a server, packaged it, and shipped it. People are installing it. The natural next thought is: can this make money? Maybe. But most MCP servers should not try, and the ones that can are a narrower slice than the hype suggests.

This article is the honest version. What the real revenue models are, where auth and billing actually plug in, and how to decide whether to charge at all.

The server itself is rarely the product

Start from an uncomfortable fact: the MCP server is usually the cheap part. It is a thin JSON-RPC layer over something that already exists, a database, an API, a SaaS product. The value lives in that backing thing, not in the tool definitions.

That shapes every honest pricing model. You are not selling “an MCP server.” You are selling access to whatever sits behind it, and the server is just a new front door for AI clients. Once you see it that way, the options get concrete.

flowchart LR
    CLIENT["AI client<br/>(agent or host)"] --> SERVER["MCP server<br/>(thin layer)"]
    SERVER --> VALUE["The real value:<br/>API, data, or service"]
    VALUE --> BILL["Billing sits here"]

Three ways to actually charge

There are three models that hold up in practice. They are not mutually exclusive; larger products combine them.

1. A hosted version you run and charge for. Your server is open source and free to self-host. You also run a managed instance: uptime, scaling, backups, a clean setup flow, someone to email when it breaks. People pay for not operating it themselves. This is the classic open-core play; operating a remote server well is genuine work a busy team would rather buy. The free code is your marketing; the hosting is the product.

2. A paid API the free server wraps. Here the server is a free, open client for a metered backend you already sell. Think a search API, a data feed, a compute service. The server hands the user’s request to your API, your API bills per call, and the server stays free because giving away a good client grows API usage. You are not charging for the protocol; you are using MCP to put your existing paid service in front of every AI agent.

3. Premium tools gated behind auth and billing. One server, two tiers. Free tools work for anyone. The valuable tools, the ones that hit expensive infrastructure or proprietary data, require an authenticated, paying account. The server checks the caller’s identity on each call and either serves the premium tool or returns an “upgrade to use this” error. This only works on a remote HTTP server, because gating needs a per-user identity that stdio does not give you.

Why can't a local stdio server charge per user?

A stdio server is launched as a subprocess by the host on the user’s own machine. It inherits that machine’s trust and has no network identity of its own. There is no login, no token, no way to tell one paying user from a freeloader, and nothing stopping someone from reading the source and removing your check.

Charging needs a server you run, reachable over the network, that sees each caller as a distinct authenticated account. That is a remote HTTP server. If money is involved, the transport question answers itself.

Where auth and billing fit

Any model that charges needs the same backbone: a remote HTTP server that knows who is calling and can count what they use. Three pieces.

Per-user auth. The connection carries a token. MCP’s HTTP transport supports OAuth, so the standard flow is: the client authenticates the user, gets an access token, and sends it on every request. Your server validates the token and resolves it to an account. No token, or an invalid one, means no premium tools.

Usage metering. Before or after each billable tool call, you record it: which account, which tool, how much. This is the same metering any usage-based API does. Meter on the dimension you charge on (calls, tokens processed, rows returned), and enforce plan limits here.

A billing provider. Do not build billing. Stripe, Lemon Squeezy, Paddle, or similar handle subscriptions, metered invoicing, tax, and dunning. Your server reports usage to them and reads back the account’s plan and status. When a subscription lapses, the provider tells you, and your auth check starts refusing premium tools.

sequenceDiagram
    participant C as Client
    participant S as MCP server
    participant B as Billing provider
    C->>S: tools/call (with token)
    S->>S: validate token, resolve account
    S->>S: check plan allows this tool
    S->>C: result
    S->>B: report usage
    Note over B: invoices, limits, tax

Here is the shape of the check that gates a premium tool. The details vary by SDK, but the logic is always this.

@server.tool()
async def premium_search(query: str, ctx: Context) -> str:
    account = await resolve_account(ctx.request.headers["authorization"])
    if account is None:
        raise ToolError("Authentication required. Sign in to use this tool.")
    if not account.plan.allows("premium_search"):
        raise ToolError("This tool needs a Pro plan. Upgrade at example.com/billing.")

    result = await run_expensive_search(query)
    await meter.record(account.id, tool="premium_search", units=1)
    return result

Return a clear, actionable error when access is denied. The AI client will relay it to the user, so “Upgrade at example.com/billing” is far better than a bare 403. The model can read that and tell the user what to do.

When to charge, and when not to

Now the honest part. As of 2026, most MCP value is internal or open, and paid public servers are a real but small niche.

Internal servers dominate. A team wires its own databases, deploy tools, and dashboards into MCP so their AI tools can reach them. There is no customer; the payoff is the team moving faster. Nobody sells these, and nobody should.

Open servers dominate the public side. The ecosystem grew on free, self-hostable servers, and that is still the norm and the expectation. A free server that solves a real problem earns reputation, contributors, and reach. Slapping a paywall on something a competent engineer can rebuild in a weekend just invites them to.

Paid servers work in a specific case: when the thing behind the server is genuinely hard to replicate and costs real money to run. Proprietary data, expensive compute, a service with a moat. If your backend already justifies a paid API, MCP is just another client for it, and charging is natural. If your “product” is only the tool definitions, there is nothing to charge for.

Isn't "put my API behind MCP" just adding an API?

Mostly, yes, and that is the point. MCP is not a new business model. It is a new distribution channel for a business model you may already have.

The reason it can still be worth it: agents are becoming a real source of API traffic, and an agent can only call your service if there is a tool it can discover and invoke. Shipping a good MCP client for your paid API puts it in reach of every agent, the same way a good SDK once put it in reach of every developer. The money still comes from the API. MCP just widens the funnel.

A short decision guide

Walk it top to bottom and stop at the first match.

flowchart TB
    Q1{"Is it only<br/>useful to my team?"}
    Q1 -->|Yes| INTERNAL["Keep it internal.<br/>No pricing."]
    Q1 -->|No| Q2{"Is the value in<br/>a costly backend<br/>or private data?"}
    Q2 -->|No| OPEN["Open-source it.<br/>Reputation is the payoff."]
    Q2 -->|Yes| Q3{"Would people pay<br/>to not operate it,<br/>or to call the backend?"}
    Q3 -->|Not really| OPEN
    Q3 -->|Yes| PAID["Remote HTTP server:<br/>auth, metering, billing."]

If you land on the paid box, keep the free tier real. The pattern that works is free code plus a paid hosted or premium tier, not a crippled free version that exists only to nag. The free part is how anyone finds you.

Common beginner mistakes

Selling the protocol layer: charging for tool definitions when the value is in the backend. Price the backend, keep the client free.
Trying to bill on stdio: a local subprocess has no per-user identity. Billing needs a remote HTTP server.
Building your own billing: subscriptions, tax, and dunning are a product on their own. Use a billing provider.
Paywalling a weekend project: if a competent engineer can rebuild it quickly, a paywall just pushes them to.
Returning bare error codes: a denied call should say what plan is needed and where to upgrade, so the agent can relay it.

Questions you will face in production

“Can I charge for a server that just wraps a public, free API?” Not really. You would be charging for a thin translation layer that anyone can copy. If you host it reliably and someone values not running it, that is an open-core hosting play, but the API itself gives you no moat.

“OAuth sounds heavy. Can I just use API keys?” For a first paid server, a per-user API key the client sends as a header is simpler and fine. OAuth is the standard for consumer-facing servers where users log in through their AI host, and MCP’s HTTP transport supports it. Start with keys if that is all you need, move to OAuth when you need real user login.

“How do I meter fairly when the AI decides how many tool calls to make?” Meter on a dimension the user can reason about, not raw call count they cannot control. Charge on results returned, data processed, or a monthly seat, so an agent’s chattiness does not surprise them with a huge bill. Publish limits and return a clear error when they are hit.

What to remember

The server is a thin layer; the value, and the price, live in the backend behind it
Three honest models: hosted version, paid API the free server wraps, premium tools gated by auth
Charging needs a remote HTTP server with per-user auth, usage metering, and a real billing provider
Deny access with a clear, actionable error the agent can relay, not a bare code
Most MCP value in 2026 is internal or open; paid public servers are a real but niche slice
Keep the free tier genuine; free code is how people find the paid part

What to study next

That closes out this MCP track. The single biggest consumer of the servers you now know how to build is AI agents, the systems that decide which tool to call and when. If you want to understand who is on the other end of your JSON-RPC connection, start with article 01: What an AI Agent Actually Is. Everything you learned about tools, transports, and auth becomes the surface an agent acts through.