MCP-as-a-Service: Building a Developer Portal That Sells AI Tool Access

The problem

Your team has an MCP server running in production. Tools work. Resources return correct data. Prompts route. Then a developer asks “How do I get access?” and the answer is a thirty-minute call where you read them an API key over the phone. The capability exists. The product around the capability does not.

Most teams hit this because they treated MCP as a protocol problem when it is also a packaging problem. An API is a capability; a product is a capability wrapped in documentation, sandbox, pricing, support, and self-service onboarding. By early 2026 the registry showed more than 10,000 published MCP servers. The ones that generate revenue are not the ones with the most tools — they are the ones where a developer can make a successful tool call in five minutes without speaking to a human.

This walks through the gateway architecture, sandbox flow, documentation rendering, and pricing model that turns a working MCP server into a metered developer portal on Cloudflare’s free tier.

What most people get wrong

Mistake one: gating the sandbox behind signup. Every minute of friction between landing page and first successful call costs you developers. The data on Time-to-First-Transaction is unambiguous — portals where TTFT lands under fifteen minutes convert five to eight times better than portals that push it past an hour. Putting a signup wall in front of sandbox.api.example.com knocks 60 to 80 percent of developers off the path before they have a reason to care about you. The sandbox should be a curl away. Authentication, billing, and tier selection come after the developer has proven to themselves that the tool works.

Mistake two: treating the three MCP primitives as one revenue model. Tools, resources, and prompts map to three different monetization shapes:

• Tools generate per-call revenue. Each invocation is a discrete metered event.
• Resources generate subscription revenue. Free tier exposes basic feeds; premium tiers expose real-time analytics or proprietary data.
• Prompts generate conversion. They are the onboarding accelerator — guided workflows that turn free-tier exploration into paid integration.

Portals that bill tools and resources identically (flat per-call) leave subscription revenue on the table. Portals that meter prompts the same way push developers away from the templates that are supposed to be doing the conversion work. The three primitives need three pricing surfaces.

A working approach

The gateway pattern. Every developer portal that sells API access needs a layer between the client and the backend that handles four functions: authenticate, rate-limit, meter, route. Build it on Cloudflare Workers; the free tier covers all four for the first 100,000 requests per day.

interface Env {
  API_KEYS: KVNamespace;
  USAGE_METRICS: KVNamespace;
  RATE_LIMITER: RateLimit;
  MCP_BACKEND: Fetcher;
}

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const apiKey = request.headers
      .get("Authorization")?.replace("Bearer ", "");

    if (!apiKey) {
      return new Response(
        JSON.stringify({ error: "Missing API key" }),
        { status: 401 }
      );
    }

    const keyData = await env.API_KEYS.get(apiKey, "json");
    if (!keyData) {
      return new Response(
        JSON.stringify({ error: "Invalid API key" }),
        { status: 403 }
      );
    }

    const { success } = await env.RATE_LIMITER
      .limit({ key: apiKey });
    if (!success) {
      return new Response(
        JSON.stringify({ error: "Rate limit exceeded" }),
        { status: 429 }
      );
    }

    const usage = await getMonthlyUsage(env, apiKey);
    if (usage >= keyData.quota) {
      return new Response(
        JSON.stringify({
          error: "Monthly quota exceeded",
          usage,
          quota: keyData.quota,
          upgrade_url: "https://soft.house/pricing"
        }),
        { status: 429 }
      );
    }

    const response = await env.MCP_BACKEND.fetch(request);
    await recordUsage(env, apiKey, request);
    return response;
  }
};

API keys live in KV as structured records, not opaque strings. Each key carries tier, quota, scopes, and environment:

interface ApiKeyData {
  developer_id: string;
  tier: "free" | "pro" | "scale" | "enterprise";
  quota: number;         // Monthly request limit
  rate_limit: number;    // Requests per minute
  scopes: string[];      // Allowed tool names
  created_at: string;
  expires_at: string | null;
  metadata: {
    name: string;
    environment: "sandbox" | "production";
  };
}

The scopes array does work most portals delegate to gateway middleware. A sandbox key gets read-only tool scopes. A Pro key gets the standard write set. A Scale key gets custom scopes the developer configures during key creation. Tier differentiation happens at the scope layer, not just the quota layer — which is what gives Scale and Enterprise customers a real reason to upgrade beyond “more calls per minute.”

Per-tier rate limits follow a 5x progression that creates natural upgrade pressure without breaking legitimate batch operations:

const TIER_LIMITS: Record<string, number> = {
  free: 20,        // 20 requests/minute
  pro: 100,        // 100 requests/minute
  scale: 500,      // 500 requests/minute
  enterprise: 2000 // 2,000 requests/minute
};

Usage metering runs asynchronously via ctx.waitUntil() to keep latency clean. Every tool invocation logs to D1 with the key, tool name, timestamp, and response status. That table powers monthly billing, the developer-facing analytics dashboard, and capacity planning — three product features from one write path.

The sandbox sits in front of all of this. Three onboarding tracks, each with a TTFT target:

1. Sandbox (target: under 2 min) — curl sandbox.api.example.com/v1/tools/search returns 200 OK with no auth. Pre-baked test data. The developer learns whether your tools are usable before being asked for an email address.
2. Free key (target: under 5 min) — email field, instant key, 1,000 calls/month, 20/min rate limit.
3. Production key (target: under 15 min) — OAuth via Google or GitHub, scope configuration, billing integration.

Documentation runs on Scalar, not Swagger UI. The reason is conversion: Scalar’s “Try It” panel is a real API client embedded in the docs page, so a developer can construct a request, send it, and see the response without leaving the documentation. The OpenAPI 3.1 spec stays in version control as the source of truth; Scalar renders it. Pagefind indexes the rendered docs at build time, giving you full-text search with zero JavaScript runtime cost. Portals running Scalar report 100:1 docs-to-support-ticket ratios — the documentation is the support layer.

Where this scales

The article above is the spine. The full book covers what survives the first ten thousand developers:

• Self-service key management — rotation flows with a 24-hour grace window, revocation, scope adjustments, all in a dashboard. Most portals offer this manually for the first six months and end up consumed by key-related support tickets.
• Usage analytics dashboard — monthly call volume, top tools, error summaries, projected end-of-month usage. The webhook event list (usage.threshold at 75/90/100%, key.expiring, rate_limit.triggered) is the proactive layer that keeps developers from getting surprised.
• The TTFT optimization framework — five concentric layers (discovery, registration, documentation, authentication, integration) with measurable per-layer targets. The book includes the alert thresholds: less than 40% under 2 min means your sandbox is broken; more than 15% over 60 min means a funnel leak.
• The five-tier pricing model with anchor effects — Sandbox / Free / Pro $49 / Scale $299 / Enterprise $4,999. The enterprise anchor is doing structural work; pulling it shifts Pro-to-Scale conversion measurably.
• Year-one growth projections with the documentation flywheel — how documentation generates inbound links that generate developers that generate documentation. The math runs from $1,188 Q1 MRR to $59,271 Q4 MRR on three revenue streams (subscription, overage, enterprise contracts) at 95%+ gross margin.

Included with the book

• api-pricing-calculator.csv — five-tier pricing template with revenue projections, cost structure, and break-even analysis. Imports cleanly to Google Sheets; the assumptions are editable.
• Scalar docs configuration template — scalar.config.yaml with theme, authentication, and Try-It server pre-wired. Drop your OpenAPI spec path in and deploy.
• Pricing strategy quick reference — free tier sizing, max price jump ratio, annual discount norm, overage versus hard-cutoff guidance.

Get the full picture

Readers of this also chose

Questions readers ask

Does this require an existing MCP server, or can I start from zero?

You need a working MCP server. The book is about the portal around it — gateway, sandbox, docs, pricing, billing. If you are still building the server, start with our sister title 08-first-mcp-server (the weekend MCP server build) and come back to this one when the tools work.

Why Cloudflare Workers specifically?

Five capabilities the gateway needs — edge deployment, KV, native rate limiting, service bindings to your backend, D1 for usage analytics — all sit inside Cloudflare's free tier for the first 100,000 requests per day. The math is that the entire pricing margin on the Free and Pro tiers flows to profit rather than infrastructure subsidy. Other edge platforms are viable; the book's code samples are Workers-shaped.

How do I price an MCP portal? What's a defensible anchor?

The five-tier model in Chapter 6: Sandbox (free, no auth), Free ($0, 1,000 calls/mo), Pro ($49/mo, 50,000 calls), Scale ($299/mo, 500,000 calls), Enterprise ($4,999/mo, unlimited + SSO + audit logs). The Enterprise anchor does structural work — pulling it shifts conversion at every tier below. The CSV calculator in the bonus content lets you re-anchor for your market.

Is TTFT really that important, or is it engineering perfectionism?

Five to eight times conversion difference between portals that hit TTFT under 15 minutes and portals that push it past an hour. That is not perfectionism; it is the single highest-leverage metric in developer-facing SaaS. The framework in Chapter 8 walks through the five layers (discovery, registration, documentation, authentication, integration), measurement, and the alert thresholds that flag a broken funnel.

What's the refund policy?

Lemon Squeezy's standard refund window applies. If the patterns don't fit your portal, the refund link is in the receipt email.