--- title: "MCP Gateway: Federate, Secure & Govern MCP Servers" description: "Federate remote MCP servers behind one spec-compliant gateway. Verified identity on every call: a bundled OAuth 2.1 authorization server, first-class IdP integrations, per-tool authorization, and audit logs for the MCP you ship and the MCP your teams use." canonicalUrl: "https://zuplo.com/mcp-gateway" sourceUrl: "https://zuplo.com/mcp-gateway" pageType: "product" generatedAt: "2026-08-28" --- # One gateway for every MCP server your agents touch. > Ship MCP to your customers. Govern the MCP your teams use. Same gateway, same > OAuth server, same audit trail. The hero shows a live diagram: AI clients (Claude, ChatGPT, Cursor) connecting through the MCP Gateway (tagged OAuth 2.0, Virtual servers, Audit log) out to federated upstreams (Stripe, GitHub, Linear, Notion, Atlassian, Cloudflare, +12 more), alongside a scrolling audit log of recent calls. ## Know who's behind every call Most AI gateways trust whatever the caller claims. Zuplo verifies it — and you never build or run an auth server. - **One click to connect** — A full OAuth server is built in. Customers click Connect — you build nothing. - **Auth works on the first try** — Agents negotiate auth automatically — no setup guides, no support tickets. - **A leak stops at one server** — A token for one MCP server is rejected at every other. - **Your login, not another one** — Users sign in with the account they already have — any identity provider. **Cross-App Access (ID-JAG)** _(IETF draft)_ — Your IdP brokers agent access to upstream servers — Zuplo is a named Okta launch partner. **Sign in with what you already run** — first-class identity provider integrations: Okta, Microsoft Entra ID, Auth0, Google, Clerk, WorkOS, Amazon Cognito, Keycloak, Logto, OneLogin, PingOne, and any OIDC provider. **For your security review** — spec receipts: `OAuth 2.1`, `PKCE S256`, `DCR · RFC 7591`, `CIMD`, `RFC 8414`, `RFC 9728`, `RFC 8707`, `RFC 7009`. [Explore the auth docs](/docs/mcp-gateway/auth/overview) ## Federate remote MCP servers behind one gateway Yours or third-party — you choose what each one exposes. An agent (Claude · ChatGPT · Cursor · VS Code) connects to "Your Zuplo Gateway," which fronts a set of routes, each bound to an upstream MCP server with individually toggleable tools: - `/mcp/github` → GitHub's MCP — tools: Create Issue, Review PR, ~~Delete Repo~~ (disabled) - `/mcp/slack` → Slack's MCP — tools: Post Message, ~~Send DM~~ (disabled) - `/mcp/stripe` → Stripe's MCP — tools: Refund Charge, Read Customers - `/mcp/internal` → Your own MCP — tools: Run Query, Read Inventory - ...any other MCP server you need! ## Wire up a virtual MCP server Stripe, Linear, GitHub, Atlassian, or your own — configured alongside the routes you already have. The "New MCP Gateway Virtual Server" configuration flow steps through Upstream → Upstream Auth → Tools → Inbound Auth. The upstream library includes Stripe, Linear, Notion, GitHub, Atlassian, Cloudflare, Vercel, PayPal, Sentry, Asana, Intercom, and Webflow, or you can bring your own MCP server (point the gateway at any first- or third-party MCP service not yet in the library) or create a new MCP from an API (auto-generate a dynamic MCP server from any OpenAPI definition — same auth, policies, and GitOps workflow as your APIs). ## Scope which tools each team — and each user — can call Access is decided by policy on every call — not by scopes baked into tokens. - **Expose only what you choose** — Hidden tools stay blocked — even when a client calls them by name. - **Fine-grained when you need it** — Decide which user can call which tool on which resource — via OpenFGA, AuthZEN, or Okta FGA. - **Your rules, in code** — When the rules are yours alone, write them in TypeScript. ## Use MCP Gateway externally to productize, or internally to govern The MCP you ship to customers and the MCP your team uses — one gateway covers both. **External** — Ship MCP to customer agents. Customers connect from Claude or ChatGPT with real sign-in, a curated catalog, and an audit trail. **Internal** — Govern the MCP your team uses. Linear, GitHub, and internal servers behind one URL — IT keeps visibility without slowing anyone down. ## Put your first MCP route in production this week Start free and wire up your first upstream in minutes — or get a guided demo for your architecture. [Read the State of MCP report →](/mcp-report) ## See everything your agents do Every session, tool call, and sign-in — in Zuplo or the dashboards you already watch. An analytics dashboard tracks MCP events over time alongside top capabilities, top users, and top virtual servers, with metrics for event volume, success rate, p95 latency, and failure origin broken out by gateway/upstream/client. - **Nothing happens off the books** — Every request, tool call, and sign-in lands in Datadog, New Relic, or Splunk. - **Answers without stitching** — Who, which client, which tool, how long, what failed — in every log row. - **No opaque 500s** — Every failure returns a documented code that tells clients how to recover. ## Whose credentials hit the upstream? Pick per route, mix freely across your fleet, and switch without a redeploy — per-user attribution stays in the audit log either way. - **OAuth — Each user brings their own login**: Users sign in to the upstream themselves; the Gateway handles their tokens. - **OAuth — One OAuth grant for the whole gateway**: Connect once for every user — the audit log still knows who did what. - **API key — A unique secret per user, vault-stored** _(Roadmap)_: Every user gets their own vaulted key — rotated without a redeploy. - **API key — One shared secret, rotated centrally**: One vaulted key for every call. Rotate it once — no client changes, no leaks. ## Hardened before your first request The defaults that get an MCP gateway through a security review — already on. - **Bad requests die at the edge** — Malformed and rogue-client calls are rejected before they touch an upstream. - **Tokens checked first** — Verified before the upstream sees a byte; bad calls get a clean 401. - **Logins can't be hijacked** — Every authorization is signed, single-use, and expiring — nothing to replay. - **Secrets stay sealed** — Upstream credentials live encrypted in a vault, decrypted only at request time. - **Runaway agents hit a ceiling** — Default limits on size and time keep one misbehaving agent from taking you down. ## FAQ Common questions about running MCP Gateway on Zuplo. **What is an MCP gateway?** An MCP gateway is a control plane that federates, authenticates, and governs multiple Model Context Protocol servers behind one spec-compliant gateway, with an OAuth-protected route per upstream server. Where an MCP server exposes one set of tools to AI agents, an MCP gateway sits in front of many (yours and remote third-party ones), handling OAuth, credential brokering, virtual-server composition, and observability across all of them. Zuplo's MCP Gateway implements the 2025-11-25 MCP spec over streamable HTTP. **What is the difference between an MCP server and an MCP gateway?** An MCP server exposes a single set of tools, prompts, and resources to AI clients. That's what you build when you turn an API into MCP. An MCP gateway sits in front of many MCP servers, yours and third-party, and adds a shared OAuth authorization server, upstream credential brokering, virtual-server composition, governance, and observability across all of them. Zuplo ships both: use MCP Server when you're exposing one set of tools, MCP Gateway when you're running many. **Which MCP spec version does the Gateway implement?** The latest 2025-11-25 spec, over streamable HTTP. Tools, prompts, and resources are first-class MCP primitives; GraphQL operations can also be exposed as MCP tools alongside REST. Any spec-compliant client connects: Claude Desktop, Claude Code, Cursor, ChatGPT (as a custom connector), VS Code, and MCP Inspector all work out of the box. **Can I use MCP Gateway externally, internally, or both?** Both, and most teams use it for both. Externally, API teams expose tools to customer AI agents: Stripe-style productized MCP for your platform. Internally, IT and security teams put one gateway in front of approved internal and third-party MCP servers, so employees connect Claude, Cursor, and ChatGPT through one governed control plane. Same product, same OAuth server, same audit trail. **What OAuth does the MCP Gateway support?** A complete OAuth 2.1 authorization server is bundled by default, on every plan. AI clients onboard themselves with Dynamic Client Registration (RFC 7591) or Client ID Metadata Documents; PKCE S256 is required as the MCP spec mandates. The Gateway publishes authorization-server metadata at .well-known/oauth-authorization-server (RFC 8414) and protected-resource metadata at .well-known/oauth-protected-resource (RFC 9728), so MCP clients discover exactly which scopes apply per virtual server. Tokens are bound to a specific virtual server via RFC 8707 resource indicators, so a token issued for one virtual server is rejected at another, and RFC 7009 revocation is built in. Auth0, Okta, Microsoft Entra ID, Clerk, WorkOS, Amazon Cognito, Google, Keycloak, Logto, OneLogin, and PingOne ship as first-class integrations, plus generic OIDC for any other provider. **How do I federate a remote MCP server through the Gateway?** Bind any route to an upstream MCP server and pick a credential model. Today the gateway ships per-user OAuth (each end-user logging in to the upstream themselves), a shared gateway-wide OAuth grant, and a single shared API key in the encrypted vault. Per-user API keys are on the roadmap. All configured in JSON alongside your existing routes. **What ships in production hardening by default?** Bearer token validation with spec-compliant WWW-Authenticate challenges pointing at the protected-resource metadata, CSRF-safe OAuth state, encrypted upstream credentials at rest, and sensible default ceilings on tool argument size, capability count, timeout, and response size. Compose prompt-injection or PII scanning as additional inbound policies when you need them. Off-the-shelf defaults you can ship through a security review. **What does observability look like?** Typed analytics events cover the MCP request lifecycle, capability invocations (tools, prompts, resources), and the full upstream OAuth flow. Structured logs carry trace-ready metadata like tenant, user, client, capability, latency, and failure origin, ready to drop into Datadog, New Relic, or Splunk. Every failure mode returns a documented problem code so MCP clients know exactly what went wrong and how to recover. ## Next steps - Start a free account: https://portal.zuplo.com/signup - Read the docs: /docs/mcp-gateway/introduction - Get a guided MCP demo: /schedule-call - Read the State of MCP report: /mcp-report