MCP Gateway
The Zuplo MCP Gateway fronts one or more remote Model Context Protocol (MCP) servers with a single, OAuth-protected endpoint that AI clients connect to. Users sign in once through your identity provider, the gateway brokers credentials to each upstream server, and every tool call lands in your analytics — without raw tokens ever reaching the AI client.
What it does
The gateway sits between MCP clients (Claude Desktop, Claude Code, ChatGPT, Cursor, VS Code, and any other client that speaks the MCP authorization spec) and the upstream MCP servers your team relies on (Linear, Notion, Stripe, GitHub, Slack, internal services, and so on).
For each MCP request, the gateway:
- Authenticates the user through your existing OAuth or OIDC identity provider — Auth0, Okta, or any RFC 8414 / OIDC discovery-compatible authorization server.
- Issues its own short-lived bearer token bound to a specific MCP route, so no upstream token is ever exposed to the client.
- Resolves the right upstream credential per user. For OAuth-protected upstreams, each user goes through a one-time consent and the gateway stores their per-upstream tokens encrypted at rest.
- Curates the set of tools, prompts, and resources each Virtual MCP exposes, so an agent only sees the capabilities you've approved.
- Emits structured analytics events for every tool call, capability list, auth event, and upstream proxy hop.
Why use it
Without a gateway, every MCP server an employee connects to is its own silo — its own OAuth flow, its own audit trail (or none), its own surface area for prompt injection or token misuse. A few problems compound quickly:
- Shadow MCP. Employees connect Claude, Cursor, and ChatGPT to third-party MCP servers faster than security teams can review them.
- Scattered OAuth. Every MCP server prompts for a separate browser login; users paste raw tokens into AI clients to make things work.
- Audit gaps. The MCP spec defines no log format, no per-user attribution, no SIEM hook.
- Tool sprawl. Agents that mount every MCP server they can find end up with hundreds of tools, which floods the context window and degrades model performance.
The MCP Gateway addresses each of these by putting the gateway in front of every upstream MCP server, scoping access by team, and producing one auditable trail.
The five problems an MCP Gateway solves
Every gateway feature maps to one of five problems that show up the moment a team uses more than one or two MCP servers:
- Discovery. A single catalog of approved MCP servers your developers and agents can connect to. No more sharing OAuth client IDs in Slack.
- Authentication. Translation from your corporate SSO to whatever each upstream MCP requires — OAuth, API key, or anything in between. MCP client config files no longer hold raw upstream credentials.
- Authorization. Curate which tools each user or team can see. A read-only view of Stripe for the finance team and a full-power view for the billing on-call is a configuration change, not a separate deployment.
- Observability. Every tool call, capability list, and auth event is structured-logged and visible in the analytics dashboard.
- Guardrails. Compose the gateway with Zuplo's PII redaction, prompt injection detection, and other security policies. The MCP traffic runs through the same policy engine your REST APIs already use.
Two ways teams use the gateway
The same product solves two distinct shapes of problem:
- Inside-out — governing how your own employees and internal agents reach third-party MCP servers (Linear, Notion, Stripe, Grafana, Slack, and dozens of others). This is how Zuplo's own team uses the MCP Gateway day to day: every internal MCP call from every employee goes through one gateway.
- Outside-in — publishing your own MCP server to external consumers with the same OAuth, rate limiting, audit, and analytics surface you'd expect from any modern API.
Both flows use the same configuration model, the same Virtual MCP abstraction, and the same policy engine.
Part of API Management
The MCP Gateway isn't a separate product. It's a new endpoint type inside the same Zuplo platform that runs your REST and GraphQL APIs. The same policy library, the same OpenAPI-as-config model, the same deployment and observability primitives — applied to MCP traffic. If your team already uses Zuplo, every existing skill and integration carries over.
Who it's for
- Platform teams that want to ship a single, governed MCP endpoint to developers and let them connect their preferred AI clients.
- Security and IT teams that need SSO, audit logs, and the ability to block or curate tool exposure per role or team.
- Anyone building agents that need to call multiple upstream MCP services without managing per-server credentials in client config files.
MCP Gateway vs. the MCP Server handler
Zuplo offers two distinct MCP features. They solve different problems and can live in the same project.
| Feature | What it does | When to use it |
|---|---|---|
| MCP Gateway | Proxies traffic to one or more upstream MCP servers. Handles OAuth, capability curation, RBAC, and analytics. | You want to expose existing MCP servers (Linear, Stripe, internal services, etc.) to AI clients through one endpoint. |
| MCP Server handler | Turns your OpenAPI routes into an MCP server. Each route becomes an MCP tool, prompt, or resource. | You want to expose your own API as MCP so AI clients can call it as tools. |
If you maintain your own REST or GraphQL API and want AI agents to use it, reach for the MCP Server handler. If you want a single front door to a set of MCP servers that already exist, this is the right product.
Architecture
Code
Each client connects to one or more Virtual MCP endpoints on the gateway. A Virtual MCP has a stable slug and points at one upstream MCP server with an optional curated subset of its tools. The gateway is built on the standard MCP authorization spec, so any spec-compliant MCP client discovers and authenticates against it without custom configuration.
What you get today
- A Portal experience for creating an MCP Gateway project, adding Origin MCPs, defining Virtual MCPs, picking tools, and connecting AI clients.
- An OAuth 2.1 authorization server that implements RFC 9728 Protected Resource Metadata, RFC 8414 Authorization Server Metadata, OpenID Connect discovery, RFC 7591 Dynamic Client Registration, OAuth Client ID Metadata Documents, and PKCE.
- Per-user OAuth federation to upstream MCP servers with encrypted token storage and automatic refresh.
- Team grouping and Virtual MCP assignment in the Portal — the basis for the RBAC enforcement that's coming next.
- A built-in analytics dashboard covering events, success rate, latency, capability volume, failure origins, and user-level breakdowns.
- Full code-config control through
routes.oas.json, theMcpProxyHandler, and a set of MCP policies for teams that prefer to manage configuration in source control alongside the rest of their Zuplo project.
Tool-level role-based access control (RBAC), token-cost analytics, and audit-log
forwarding to external SIEMs are on the near-term roadmap. Today, teams group
members and assign Virtual MCPs; tool-level filtering is configured per route
with the mcp-capability-filter-inbound policy rather than per user.
The gateway implements the MCP authorization spec at revision
2025-11-25,
which is the current revision at the time of writing.
Next steps
- Quickstart — set up an MCP Gateway project, add an origin, expose a Virtual MCP, and connect Claude Desktop in about ten minutes.
- How it works — the request lifecycle, both OAuth surfaces, and how Portal config maps to runtime behavior.
- Reference — the full URL catalog, default TTLs, and configuration constants.
- Troubleshooting — symptoms, likely causes, and fixes for the common issues.