PREVIEW · TEST MODE — no real money moves yet. Payouts are not live.
Stevens Keys by Marc Stevens

License keys for paid MCP servers

How to gate a paid MCP server with license keys, why revocation speed matters, and whether to sell through a marketplace or from your own site.

How to gate an MCP server with license keys

A remote MCP server is an HTTP endpoint, so gating it works like any paid API:

  1. Give each customer a key. Issue a unique key per customer (or per seat) when they pay. Never share one key across customers; you lose the ability to cut off one without the rest.
  2. Have the client send it. MCP clients that support remote servers let users set headers, so the usual pattern is Authorization: Bearer <key> in the server config.
  3. Check it on every request. Before running a tool, validate the key with your key service. Deny with 401 when it's missing and 403 when it's invalid, revoked, or over quota, and return a message the user can act on.
  4. Meter as you validate. If you charge by usage or cap free plans, count the call in the same check so quota and usage can't drift apart.
  5. Store hashes, not keys. Your database should hold a hash of each key, so a leaked database doesn't leak working keys.

Local (stdio) MCP servers are harder: the code runs on the user's machine, so a check can be patched out. Keys still work well for gating a hosted backend that the local server calls.

Near-instant revocation vs cached keys

Many license systems cache validation results, sometimes for hours, to save on lookups. That's fine for desktop software. It's a problem for MCP servers, where a leaked key in a public config or a refunded customer can keep calling paid tools until the cache expires. Some marketplaces document revocation delays of up to 24 hours.

The alternative is to route every check for a key through one authoritative place, so a revoke is seen by the next call. Stevens Keys does this with one Durable Object per key, and returns a short cache_ttl hint (default 30 seconds, 0 on deny) for servers that want to cache allows. You choose the trade-off; you can see it in the demo.

Selling from your own site or GitHub vs a marketplace

Marketplaces bring discovery, and typically take 15–20% of revenue. The catch is that the customer relationship lives on their storefront, and moving away later means re-issuing keys to every customer.

Selling yourself (your site, your GitHub README, your listing on a directory) keeps the customer relationship and pricing in your hands, but you have to build keys, metering and billing. A billing layer that isn't a storefront sits between the two: you sell wherever you want, and it handles keys, validation, usage and (once live) payouts.

MarketplaceYour own site + key service
DiscoveryBuilt inYours to drive (directories, GitHub, content)
Customer relationshipTheirsYours
Typical fee15–20%Stevens Keys: 15%, free to start
Switching costHighLow: keys and server stay where they are

Where Stevens Keys fits

Stevens Keys, from Marc Stevens and the team behind Surface, issues hashed license keys, validates and meters them at the edge, and revokes on the next call. Creators keep 85%. It's in preview: test mode only, payouts via Stripe Connect not live yet, and account verification is manual during early access.

Read the docs Try the demo

More from Marc Stevens