# MCP Gateway The Zuplo MCP Gateway fronts one or more remote [Model Context Protocol](https://modelcontextprotocol.io) (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 against your identity provider, mints an independent upstream credential, optionally curates the capabilities the upstream exposes, and produces a structured analytics event the platform team can audit. ## The five problems an MCP Gateway solves 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. Each gateway feature maps to one of five problems that show up the moment a team uses more than one or two MCP servers: 1. **Discovery.** A single catalog of approved MCP servers your developers and agents can connect to. No more sharing OAuth client IDs in Slack. 2. **Authentication.** Translation from your corporate SSO to whatever each upstream MCP requires. MCP client config files no longer hold raw upstream credentials. 3. **Authorization.** Curate which tools each route exposes. A read-only view of Stripe and a full-power view of the same upstream is a configuration change, not a separate deployment. 4. **Observability.** Every tool call, capability list, and auth event is structured-logged and visible in the analytics dashboard. 5. **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 the gateway is used 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. ## How it fits into Zuplo The MCP Gateway isn't a separate product. It's a set of policies and a route handler that run inside the same Zuplo platform that runs your REST and GraphQL APIs. A project gets MCP Gateway functionality by adding the `McpGatewayPlugin`, an MCP OAuth policy, and one MCP route per upstream — 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. ## 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, and analytics. | You want to expose existing MCP servers (Linear, Stripe, internal services, etc.) to AI clients through one endpoint. | | **[MCP Server handler](../handlers/mcp-server.mdx)** | 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 OIDC Identity Provider Claude Desktop Cursor ChatGPT OAuth 2.1 AS + RS MCP route Capability filter Per-user token store Linear Notion Stripe Each client connects to one or more MCP routes on the gateway. Each route is a path in `routes.oas.json` that uses the `McpProxyHandler` and points at one upstream MCP server, optionally with a curated subset of its capabilities. The gateway is built on the standard MCP authorization spec, so any spec-compliant MCP client discovers and authenticates against it without custom configuration. ## 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 curate tool exposure. - **Anyone building agents** that need to call multiple upstream MCP services without managing per-server credentials in client config files. ## Next steps - [Try the quickstart](./quickstart.mdx) — add the MCP Gateway plugin to a Zuplo project, configure Auth0, expose one upstream MCP server, and connect Claude Desktop. - [Browse the how-to guides](./connect-clients/overview.mdx) — connect specific MCP clients, add more upstreams, curate tools, configure upstream OAuth. - [Read how it works](./how-it-works.mdx) — the request lifecycle, the two OAuth surfaces, and the configuration model. - [Look something up in the reference](./reference.mdx) — the full URL catalog, default TTLs, and configuration constants.