🌉 MCP Server: SaaS Gateway

A small TypeScript template for building one Model Context Protocol server that fronts many REST APIs.

One gateway, N apps. Drop tokens in env vars, expose each API as a slug, ship a single MCP entry to Claude Desktop / Claude Code.

Why this exists

The default pattern in the MCP ecosystem is one server per backend. That works fine when you only need Slack OR GitHub. It gets messy fast when you actually want Claude to orchestrate across several of your own SaaS APIs in a single conversation — every backend becomes another entry in claude_desktop_config.json, with its own token to rotate.

This template flips the model: one gateway server, N apps. Each app is a slug + baseUrl + Bearer token. Tools are named {app_slug}_{action} so Claude understands which API does what.

Born from a real production setup that fronts 4 internal SaaS (PostMaid, Daiv, Botlers, AGSteel) and exposes ~30 tools through one MCP entry — total config footprint in Claude Desktop: 6 lines.

This is not a published npm package — it's a template. Fork it, edit src/index.ts and src/config.ts, ship your own gateway.

Quick start

# 1. Clone the template
git clone https://github.com/grobinson3108/mcp-server-saas-gateway.git my-gateway
cd my-gateway

# 2. Install + build
npm install
npm run build

# 3. Run with your tokens
EXAMPLE_API_TOKEN=your-token npm start

Wire into Claude Desktop:

{
  "mcpServers": {
    "my-gateway": {
      "command": "node",
      "args": ["/absolute/path/to/my-gateway/dist/index.js"],
      "env": {
        "EXAMPLE_API_TOKEN": "your-token"
      }
    }
  }
}

Restart Claude Desktop. Your tools appear under the 🔌 icon.

What's inside

The pattern

// 1. Declare your apps
const config = loadConfigFromEnv('my-gateway', [
  { slug: 'postmaid', name: 'PostMaid',  defaultBaseUrl: '...', type: 'internal' },
  { slug: 'stripe',   name: 'Stripe',    defaultBaseUrl: 'https://api.stripe.com/v1', type: 'external' },
]);

// 2. Build a client per app
const clients = Object.fromEntries(
  Object.entries(config.apps).map(([slug, app]) => [slug, new ApiClient(app)])
);

// 3. Register tools, namespaced by slug
server.tool('postmaid_get_profile', 'Get PostMaid editorial profile', {}, async () => {
  return wrap(await clients.postmaid.get('/profile'));
});

server.tool('stripe_list_customers', 'List recent Stripe customers',
  { limit: z.number().optional() },
  async ({ limit }) => wrap(await clients.stripe.get('/customers', { limit: String(limit ?? 10) }))
);

That's it. No registry magic, no codegen, no schema crawling. Each tool is a 3-line lambda that calls one endpoint.

When to use this template vs alternatives

Trade-offs we made

• No schema introspection / OpenAPI codegen. Adding it would buy you 10 minutes per tool while costing a lot of maintenance complexity. Tools are 3 lines of TypeScript — writing them by hand stays fast and readable.

• stdio only. HTTP/SSE transport is on the roadmap if a real use case shows up.

• No per-tool authorization. All apps share the gateway's spawn-time env. If you need per-call scopes, do it inside the tool callback (the Bearer token of the app is yours to scope however you want).

• Not on npm. This is a starter template — fork-and-edit beats install-and-configure for this kind of code.

Examples

• examples/multi-saas-gateway/ — A 4-app gateway inspired by a real production setup

• examples/stripe-only/ — Minimal Stripe wrapper

License

MIT — see LICENSE.

About the author

Greg Robinson — AI Architect, RAG and agentic systems, Audelalia (🇫🇷 Montpellier).

Companion package for the PHP side: laravel-mcp-server — same idea, but for Laravel apps where the SaaS itself is the backend.

⭐ If this saved you an hour, drop a star.