--- title: "Introducing the Zuplo MCP Gateway" description: "AI agents have unprecedented access to your critical systems. Do you know what they're doing? The MCP Gateway, in public beta today, lets you monitor, control, and customize how agents reach your APIs through MCP." canonicalUrl: "https://zuplo.com/blog/2026/06/02/introducing-zuplo-mcp-gateway" pageType: "blog" date: "2026-06-02" authors: "josh" tags: "Model Context Protocol, ai-agents, product" image: "https://zuplo.com/og?text=Introducing%20the%20Zuplo%20MCP%20Gateway" --- 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](https://zuplo.com/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. ## 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](https://docs.stripe.com/mcp)-style productized MCP for the platform you sell; [Linear](https://linear.app/changelog/2025-05-01-mcp), [GitHub](https://github.blog/changelog/2025-04-04-github-mcp-server-is-now-available-in-public-preview), and [Atlassian](https://www.atlassian.com/blog/announcements/remote-mcp-server) 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](https://modelcontextprotocol.io/specification/2025-11-25) 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. ![Step 1 of the New MCP Gateway Virtual Server wizard, choosing an upstream from the curated library. The grid shows Stripe, Linear, PostHog, Notion, GitHub, Cloudflare, Firecrawl, Atlassian, Slack, Figma, Datadog, Postman, and more, with a search box and a button to set up a custom MCP server.](/blog-images/introducing-zuplo-mcp-gateway/upstream-library.png) The same URL goes to a customer agent connecting from ChatGPT, or to your own employees connecting from Claude behind SSO. ![New MCP Gateway Virtual Server wizard at step 3 of 4, Tools. Curate is selected over Passthrough, exposing two destructive tools from the Cloudflare upstream (search_cloudflare_documentation and migrate_pages_to_workers_guide) and one prompt (workers-prompt-full). Each capability has a checkbox so the operator decides exactly what the virtual server exposes.](/blog-images/introducing-zuplo-mcp-gateway/wizard-tool-curator.png) 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](https://datatracker.ietf.org/doc/html/rfc7591). 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](https://datatracker.ietf.org/doc/html/rfc8414)) and protected-resource metadata at `.well-known/oauth-protected-resource` ([RFC 9728](https://datatracker.ietf.org/doc/html/rfc9728)). MCP clients negotiate auth correctly the first time, every time. - **Per-virtual-server token scoping.** Every token carries an [RFC 8707](https://datatracker.ietf.org/doc/html/rfc8707) 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](https://en.wikipedia.org/wiki/Confused_deputy_problem) 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-Authenticate` challenges 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](/blog/never-ship-mcp-server-without-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](/blog/introducing-agents-analytics). ![MCP analytics tab in Zuplo showing 100.1K events, 93.23% success rate, 3.7K client errors, 100 server errors, and 3.8K failure origins broken down by gateway, upstream, and client. Below the KPIs, a stacked area chart titled MCP Events Over Time plots token validation, credential resolution, capability, and request lifecycle events from May 20 to June 2, peaking near 20K events in a day.](/blog-images/introducing-zuplo-mcp-gateway/analytics-graph.png) 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). ![Top Capabilities table ordered by call volume, showing posthog-mcp-server execute_sql at 2.4K calls, clickhouse-mcp-server run_select_query at 2.1K, firecrawl-mcp-server firecrawl_scrape at 790, calendly-mcp-server meetings-list_events at 726, and fathom-video and linear tools in the hundreds. Each row breaks out client and server error counts, error rate, and p95 latency.](/blog-images/introducing-zuplo-mcp-gateway/capabilities.png) 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. ![Top Reason Codes table grouping events by class and code: auth missing_token at 3.3K events and 3.3K errors, auth reconsent_required and connect_required at 1.2K each with zero errors, auth invalid_token at 204, revoked_token and expired_token in the low double digits, and upstream capability invocation and list failures in single digits.](/blog-images/introducing-zuplo-mcp-gateway/reason-codes.png) 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. ## 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](https://portal.zuplo.com/signup?utm_source=zuplo-blog&utm_medium=web&utm_campaign=mcp-gateway) and ship your first virtual MCP server today.