Three ways to control who can call a paid MCP server, and what each costs you to build and run. Stevens Keys is in preview (test mode); where we describe it, we describe only what's built.
| License keys | OAuth | Plain API keys (DIY) | |
|---|---|---|---|
| Best for | Paid access, plans and quotas per customer | Acting on a user's account in another service; per-user identity and consent | Internal or small-scale access you control |
| Setup cost | Low with a key service; you add one validate call | Highest: authorization server, token handling, client registration | Low to start; grows as you add hashing, quotas, revocation, usage |
| Revocation | As fast as your validation path (see below) | Depends on token lifetime and whether you check revocation | Whatever you build |
| Metering | Natural: one key per customer, count on each check | Not built in; you meter per user yourself | Yours to build |
| Ties to payment | Directly: a key is issued per purchase | Indirect: you map users to entitlements | Manual |
A license key is a secret issued per customer (or seat) when they get access. The client sends it, typically as Authorization: Bearer <key>, and your server checks it before running a tool: 401 when missing, 403 when invalid, revoked or over quota. Store only a hash of each key so a leaked database doesn't leak working keys.
Fits when: you sell access to a remote server, want per-customer quotas, and want to cut off one customer without touching the rest. Weak spot: local stdio servers run on the user's machine, so a check there can be patched out; gate a hosted backend instead.
In Stevens Keys, keys are sk_mcp_test_ plus 43 random base62 characters, stored as SHA-256 hashes, and a single POST /v1/validate call both checks and meters. See the docs.
The MCP specification defines an optional authorization flow for HTTP transports based on OAuth 2.1. It's the right choice when your server needs the user's identity or acts on their behalf in another service (their calendar, their repo). The cost is real: you need an authorization server or provider, token issuance and refresh, and handling for each client's flow. Client support varies by client and version, so verify the clients you target.
OAuth tells you who a user is; it doesn't say what they paid for. Paid servers using OAuth still need an entitlement and usage check, which can be a license key behind the scenes.
Functionally the same as license keys, but you own every piece: generation, hashing, per-key status, quotas, usage counters, revocation, and a dashboard for customers. That's fine for a handful of known users. It gets expensive once you have plans, quotas and paying customers.
Revocation is only as fast as the slowest cache in the path. Some marketplace license systems cache valid results for hours; at least one documents up to 24 hours before a revoked key stops working. OAuth access tokens usually remain valid until they expire unless your server checks revocation on each call.
Stevens Keys routes every check for a key through one Durable Object, so a revoke is seen by the next validation call. Validate returns a cache_ttl hint (30 seconds by default, 0 on deny); caching allows is your choice and bounds the delay. Try it in the demo: issue a sandbox key, validate it, revoke it, validate again.
Per-customer keys make metering straightforward: count units in the same call that checks the key so quota and usage can't drift apart. Stevens Keys does this per key, with live counters and daily usage rollups in the dashboard. With OAuth you meter per user or client yourself.
Per-call pricing matches price to cost but needs accurate metering and gives customers less predictable bills. Subscriptions are simpler to sell; pair them with a monthly call cap so one customer can't run up your costs. Either works with license keys. More in the MCP monetization FAQ.
The MCP specification defines an optional authorization flow for HTTP-based transports built on OAuth 2.1. Support differs between clients and versions, so check each client you care about before relying on it. stdio servers don't use this flow; they typically read credentials from the environment.
There is no separate license-key standard in MCP. A license key is sent like any bearer token, usually as an Authorization: Bearer header set in the client's server configuration, or as an environment variable for local servers. Whether a client lets users set custom headers varies by client.
Every check for a key goes through one Durable Object, so a revoke is seen by the next validation call. Validate returns a cache_ttl hint (30 seconds by default, 0 on deny); if your server caches allows, revocation takes up to that long.
Yes. A common split is OAuth for who the user is, and a license key or entitlement check for what they paid for and how much they have used.
Verification emails are not being sent yet. After signing up, use "Request early access verification" in the dashboard, and real creators are approved by hand. Until then you can try the full issue, validate and revoke flow in the demo. Payouts via Stripe Connect are planned, not live.
MCP monetization FAQ · License keys for paid MCP servers · Creator docs · Demo