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.
AI Clients
Federated Upstreams
+12 more
Recent Calls
LiveFederate 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.
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.
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
Path
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.
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.
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.
MCP Gateway observability you can pipe into your existing dashboards
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 hoursTop Capabilities
Top Users
Top Virtual Servers
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.
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.
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.
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.
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.
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.
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.
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 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.