Your teams are already wiring AI agents into Linear, GitHub, Stripe, and a pile of internal servers, with nowhere to govern any of it.
Today, the MCP Gateway launches in public beta, available to everyone: one spec-compliant gateway in front of every MCP server your agents touch, with the OAuth, credential brokering, tool curation, and observability that make it safe to ship.
- API teams shipping MCP servers to customer agents
- IT and security teams governing the MCP servers employees already use
- Platform teams tired of bolting OAuth onto every internal MCP server
13:27One Gateway for Every MCP Server You Use
Josh and WebMCP inventor Alex Nahas whiteboard the five whys of an MCP gateway: discovery, auth translation, authorization, observability, and guardrails, plus a deep dive on how the Gateway handles MCP OAuth.
What an MCP gateway does
An MCP server exposes one set of tools, prompts, and resources to an AI client. An MCP gateway sits in front of many of them, yours and third-party, putting each behind a governed endpoint and adding what every server would otherwise build on its own: a shared OAuth authorization server, upstream credential brokering, tool curation, governance, and observability. MCP is just another protocol for calling APIs, built on the HTTP stack, which is why the right place to govern it is the same place you govern the rest of your APIs: the gateway.
A year ago “do we expose an MCP server?” was the interesting question. Today most teams are running, or consuming, several at once: Stripe-style productized MCP for the platform you sell; Linear, GitHub, and Atlassian for the work your employees do every day; a handful of internal servers for your own APIs.
Each one is its own OAuth flow, its own credential model, its own audit trail. That’s how shadow MCP starts: the same drift as shadow IT, where users hook agents up to MCP servers nobody on the platform team can see, govern, or revoke. The Gateway removes that drift.
The Zuplo MCP Gateway implements the 2025-11-25 MCP spec over streamable HTTP, so any spec-compliant client connects: Claude Desktop, Claude Code, Cursor, ChatGPT (including the OpenAI Apps SDK), VS Code, and MCP Inspector all work out of the box.
Curate tools with virtual MCP servers
The core primitive is the virtual MCP server: a curated view of an upstream MCP server that exposes only the tools, prompts, and resources you pick, at its own Gateway URL.
Pick an upstream from the curated library (Stripe, Linear, GitHub, Notion, Slack, PostHog, and more), or bring your own. Federate its catalog live so new capabilities appear when the upstream adds them, or hand-pick a fixed subset of tools, prompts, and resources. I use the Stripe MCP server every day with the destructive tools filtered out, so my LLM can’t make a mistake I’d spend the afternoon apologizing for.
The same URL goes to a customer agent connecting from ChatGPT, or to your own employees connecting from Claude behind SSO.
A virtual MCP server is a first-class route in Zuplo’s OpenAPI-driven config, so the wizard sits in the designer next to your existing REST and GraphQL routes. A single project can ship a REST API, a GraphQL endpoint, and a virtual MCP server side by side. Toggle tools on or off without forking the upstream, and switch credential models without a redeploy.
A full OAuth 2.0 authorization server, included
OAuth is the part nobody wants to build, so the Gateway ships one written to the MCP spec. Your customers click Connect; they don’t paste tokens.
The implementation covers what the spec calls for:
- Dynamic Client Registration + PKCE. AI clients self-register via RFC 7591. PKCE S256 is enforced as the MCP spec requires, so no shared client secrets ship to the desktop.
- Spec-compliant discovery. Authorization-server metadata at
.well-known/oauth-authorization-server(RFC 8414) and protected-resource metadata at.well-known/oauth-protected-resource(RFC 9728). MCP clients negotiate auth correctly the first time, every time. - Per-virtual-server token scoping. Every token carries an RFC 8707 resource indicator bound to its virtual MCP server. A token minted for one is rejected at another, so a compromised server can’t replay a user’s token against a different upstream (the confused-deputy attack the MCP spec calls out).
- Identity-provider presets. First-class presets for Auth0, Okta, Entra, Clerk, Cognito, WorkOS, Google, Keycloak, Logto, OneLogin, Ping, and any OIDC-compliant provider. Drop your issuer URL in and hit save.
By default, a spec-compliant client discovers, registers, authorizes, and calls a virtual server with no out-of-band setup.
Four credential models, one audit trail
Every MCP server behind the Gateway needs an answer to “whose credentials hit the upstream?” The Gateway gives you four, picked per route and switched without a redeploy. Per-user attribution stays in the audit log regardless of which credentials reach the upstream, because the Gateway’s OAuth flow authenticates the user on the front end.
| Model | How it works | Status |
|---|---|---|
| Per-user OAuth | Each end-user completes the upstream’s OAuth flow; the Gateway brokers and refreshes tokens per session, with per-user revocation. | Live today |
| Shared OAuth grant | One OAuth grant at the gateway serves every user behind it. The upstream sees a single service principal; your audit log keeps per-user attribution. | Live today |
| Per-user API key | Each user gets their own key in the encrypted vault, self-service or admin-provisioned, rotated without a redeploy. Good fit for partner APIs that issue per-user tokens. | On the roadmap |
| Shared API key | One key in the encrypted vault, attached to every outbound call. Rotate once; every user picks up the new value on the next request. | Live today |
Mix them across your fleet. A Stripe upstream might use per-user OAuth so customer agents authenticate as the customer, while an internal analytics MCP uses a shared API key. Once per-user API keys land, a partner API that issues per-user tokens slots in the same way.
Production hardening, on by default
Defaults that pass a security review, off the shelf:
- Origin and host validation on every MCP request, against an allowlist you control.
- Bearer token validation with spec-compliant
WWW-Authenticatechallenges pointing at the protected-resource metadata, so clients re-authenticate cleanly. - CSRF-safe single-use OAuth state, signed and TTL’d.
- Encrypted upstream credentials sealed in the gateway vault, decrypted only at request time.
- Sensible upstream limits on tool arguments, capability counts, timeouts, and response sizes, sized to survive a misbehaving agent.
- Automatic redaction of tokens and customer payloads in logs, plus the prompt-injection detection inherited from Zuplo’s policy stack. Injection in MCP flows backwards: a poisoned tool response lands straight in the LLM’s context, so the Gateway scans responses, not just requests.
The rest of Zuplo’s policy library applies too, including the one policy no MCP server should ship without: a rate limit.
Analytics for every tool call
The Gateway emits typed events across three families: the MCP request lifecycle, capability invocations (tools, prompts, resources), and the full OAuth lifecycle across both gateway and upstream.
They surface in the new MCP tab in Zuplo Analytics, alongside Requests, Consumers, AI Gateway, and the Agents tab we shipped in May.
The headline KPIs cover what an MCP operator cares about: success rate, the client vs server error split, and whether failures originate at the gateway, the upstream, or the client. Below them, the leaderboards: which tools get called most, which users and virtual servers drive the traffic, and which MCP clients are connecting (claude-code, ChatGPT, Cursor).
When something fails, you see exactly where and why: every failure maps to a
documented reason code, like expired_token or
upstream_capability_invocation_failed, so MCP clients know what went wrong and
how to recover.
Structured logs carry tenant, MCP session, capability, latency, and failure origin, so piping them into Datadog, Honeycomb, or Splunk is a copy-paste exercise, not a project.
One gateway for customer agents and employees
The Gateway works in two directions, and most teams using it use both. Outside-in is the traditional gateway deployment: put auth, monetization, and tool curation in front of your first-party MCP servers and hand the URL to customer agents. Inside-out points the other way: govern how your own employees and agents connect to the third-party MCP servers they already use.
| Direction | Who runs it | What it does | What you get |
|---|---|---|---|
| Outside-in | API teams | Expose tools to customer AI agents via virtual MCP servers, connected from Claude, ChatGPT, or any agent. | Real OAuth flow, per-customer tool catalogs, Stripe-style productized MCP. |
| Inside-out | IT and security teams | Put the Gateway in front of the internal and third-party MCP servers employees are already using. | Per-team access, brokered credentials, audit log on every call. |
We run the inside-out direction ourselves: Zuplo employees reach the Linear, Stripe, Notion, QuickBooks, and ClickHouse MCP servers through our own Gateway. Lower friction on the official path than the unofficial one is the only thing that moves MCP usage out of the shadows. Same product, same OAuth server, same audit trail. Pick a direction, or use both.
MCP Gateway Quickstart
Build your first virtual MCP server entirely in the browser: pick an upstream, wire up OAuth, and point an agent at it, with every call landing in your analytics.
From sign-up to governed agents in an afternoon
The public beta is open to everyone. Start a free Zuplo project, put the upstream MCP servers your team already depends on behind it, and each one gets a spec-compliant Gateway URL to hand to any MCP client. OAuth, governance, and audit logs are on by default, and the MCP analytics tab lights up the moment the first agent connects.
Spin up a free Zuplo project and ship your first virtual MCP server today.