Zuplo
MCP Gateway Beta

One gateway for every MCP server your agents touch.

Every MCP server your agents touch is one more thing to authenticate, scope, and audit. Govern them all from one control plane: scoped tool access per team, every call logged in one place.

MCP Gateway
ACTIVE

AI Clients

Claude
ChatGPT
Cursor
MCP Gateway
OAuth 2.0Virtual serversAudit log

Federated Upstreams

Stripe
GitHub
Linear
Notion
Atlassian
Cloudflare

+12 more

Recent Calls

Live
alex@acmeGitHub200
agent-prodStripe200
priya@orgInternal Wiki403
sam@corpLinear200
alex@acmeGitHub200
Federation

Federate remote MCP servers behind one gateway

Front any spec-compliant MCP server from one Zuplo deployment, one route per upstream. Your own, your partners', or third-party (GitHub, Slack, Stripe, anything an agent speaks to). Curate the tools each route exposes without forking.

AgentClaude · ChatGPTCursor · VS Code
Your Zuplo Gateway
/mcp/githubGitHub's MCP
/mcp/slackSlack's MCP
/mcp/stripeStripe's MCP
/mcp/internalYour own MCP
any other MCP server you need!
Built on the spec, not around it

Wire up a virtual MCP server in four steps

Pick an upstream — Stripe, Linear, GitHub, Atlassian, and more all work — or bring your own. Federate its catalog live, or curate the tools, prompts, and resources you expose. Configured in JSON alongside your existing REST and GraphQL routes.

New MCP Gateway Virtual Server

Configure the upstream MCP server, tools, and authentication.

×
1 Upstream 2 Upstream Auth 3 Tools 4 Inbound Auth
Library Custom
Search servers…
Stripe Stripe
Linear Linear
Notion Notion
GitHub GitHub
Atlassian Atlassian
Cloudflare Cloudflare
Vercel Vercel
PayPal PayPal
Sentry Sentry
Asana Asana
Intercom Intercom
Webflow Webflow

Bring your own MCP server

Point the gateway at any first-party or third-party MCP service, even one not yet in the Library.

Create a new MCP from API

Auto-generate a dynamic MCP server from any OpenAPI definition — same auth, policies, and GitOps workflow as your APIs.

Name

e.g. Linear, GitHub, Atlassian

Path

/mcp/your-server
One gateway, two surfaces

Use MCP Gateway externally to productize, or internally to govern

Zuplo's MCP Gateway works both ways: for the MCP you ship to customer agents and for the MCP your own team is already using.

External

Ship MCP to customer agents

Compose virtual MCP servers your customers connect to from Claude, ChatGPT, or any agent. Real OAuth flow, per-customer tool catalogs, audit logs on every call.

Internal

Govern the MCP your team uses

Federate third-party MCP servers (Linear, GitHub, Stripe, Atlassian, your own internal ones) behind a single Gateway URL. Per-team access, brokered credentials, audit log on every call. IT keeps visibility without slowing the rollout.

Observability

MCP Gateway observability you can pipe into your existing dashboards

Analytics MCP
All environments ▾ Last 24 hours ▾

Events

7.0K

Success rate

97.58%

6.9K success / 170 error

p95 latency

102ms

gw <1ms · up <1ms

Failure origins

157

gw 0 · up 0 · cl 157

MCP events over time

last 24 hours
3 PM 9 PM 3 AM 9 AM 3 PM

Top Capabilities

Capability Calls
get_issue linear-v1 40
update_thread superhuman-v1 29
list_issues linear-v1 10
list_teams linear-v1 8
notion-fetch notion-v1 5

Top Users

User Events Errors
alex@acme.co 4.1K 0 (0.00%)
agent-prod 181 0 (0.00%)
priya@org.dev 130 0 (0.00%)
sam@corp.io 108 0 (0.00%)
maya@acme.co 85 0 (0.00%)

Top Virtual Servers

Virtual Server Events Errors
notion-v1 1.6K 18 (1.10%)
fathom-video-v1 1.2K 14 (1.17%)
calendly-v1 1.2K 15 (1.29%)
linear-v1 939 22 (2.34%)
cloudflare-observability-v1 714 12 (1.68%)

Typed events across the request lifecycle

Events fire on every MCP request, capability invocation (tool, prompt, or resource), and step of the upstream OAuth flow. Pipe them into Datadog, New Relic, Splunk, or whatever your SRE team trusts.

Trace-ready structured logs

Every log row carries the metadata you'd otherwise stitch together: tenant, session, capability, latency, failure origin. Drop straight into your trace system.

Recoverable, standardized errors

Every failure mode returns a documented problem code, so MCP clients know exactly what went wrong and how to recover. No opaque 500s.

The OAuth nobody wants to build

A full OAuth 2.0 server, included

The Gateway ships a complete OAuth 2.0 authorization server, written to the MCP spec. Your customers click Connect. They don't paste tokens.

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, closing confused-deputy attacks by construction.

Auth0 & OIDC presets

First-class presets for Auth0 and any OIDC provider. Drop your issuer URL in, hit save, and your customers click Connect.

Credential models

Whose credentials hit the upstream?

Every MCP server behind the Gateway needs an answer. Pick per route, mix freely across your fleet, switch without a redeploy, and keep per-user attribution in the audit log no matter which model you choose.

OAuth

Each user brings their own login

End-users complete the upstream's OAuth flow; the Gateway brokers and refreshes their tokens per session, with per-user revocation.

OAuth

One OAuth grant for the whole gateway

Connect once at the gateway level; the same grant serves every user behind it. Your audit log keeps per-user attribution while the upstream sees a single service principal.

API key Roadmap

A unique secret per user, vault-stored

Each user gets their own API key in the encrypted vault, self-service or admin-provisioned, rotated without a redeploy. Ideal for partner APIs that issue per-user tokens you'd rather not paste into an MCP client.

API key

One shared secret, rotated centrally

Store one API key in the encrypted vault; the Gateway attaches it to every outbound call. Rotate in one place and every user picks up the new value on the next request. No client config changes, no leaked keys.

Production hardening, by default

MCP Gateway production hardening and security defaults

Spec-compliant request handling

Every MCP request is checked for the headers and origin the spec requires before it touches an upstream. Malformed and rogue-client requests are rejected at the edge.

Bearer validation with spec-compliant 401s

Tokens are verified before the upstream sees a byte. Invalid requests get a 401 with WWW-Authenticate pointing at the protected-resource metadata, so clients re-authenticate cleanly.

CSRF-safe OAuth state

State values are signed, single-use, and TTL'd. No third-party AI client can hijack an in-flight authorization or replay an old one.

Encrypted upstream credentials

Every upstream token and secret is sealed in the gateway vault, encrypted at rest and only decrypted at request time. Per-user OAuth tokens are keyed by the user's subject ID.

Sensible default ceilings

Default limits on tool argument size, capability count, timeout, and response size. Misbehaving agents bounce off the ceiling instead of taking the gateway down.

Who picks up the Gateway

Who should use an MCP Gateway?

API teams shipping MCP to customers

You want agents to use your product. Ship a spec-compliant MCP server with a real OAuth flow.

IT & security teams governing internal use

Your employees are wiring Claude, Cursor, and ChatGPT into Linear, GitHub, and internal servers. Put the Gateway in front: central catalog, per-role access, audit log on every tool call.

Frequently Asked Questions

Common questions about running MCP Gateway on Zuplo.

Your MCP Gateway, in production today

Spin up a free Zuplo project and federate the upstream MCP servers your team already depends on. OAuth, governance, and audit logs are on by default.