---
title: "Front a Third-Party Server with the Zuplo MCP Gateway"
description: "Put a third-party MCP server behind real auth and tool curation without writing a line of config. We front Linear with the Zuplo MCP Gateway, strip its destructive tools, and connect it to Claude, all in the portal."
canonicalUrl: "https://zuplo.com/blog/2026/06/03/set-up-virtual-mcp-server-portal"
pageType: "blog"
date: "2026-06-03"
authors: "martyn"
tags: "Model Context Protocol, ai-agents"
image: "https://zuplo.com/og?text=Front%20a%20Third-Party%20Server%20with%20the%20Zuplo%20MCP%20Gateway"
---
The [MCP Gateway](/blog/introducing-zuplo-mcp-gateway) runs a wizard to build
the virtual server; after that you add environment variables, connect a client,
and watch the calls land. Get one thing straight first: there are two auth
layers. Inbound auth controls who connects to the gateway, upstream auth
controls how the gateway reaches Linear.
## 1. Add a virtual MCP server route
Start in a Zuplo project and open the **Code** tab. Click **Add Route** and pick
**MCP Gateway Virtual Server**. That route type fronts one upstream MCP server,
putting it behind your own auth and tool policy, and hands you back a governed
Gateway URL. Every other MCP server you want to govern gets its own route the
same way.
## 2. Pick an upstream from the library
The wizard opens on a grid of predefined MCP servers Zuplo already knows about:
Stripe, Linear, GitHub, Notion, PostHog, and more. Select **Linear** (or
whichever server you want to work with).
Picking from the library prefills the name, the upstream MCP URL, and the path
the server will live at (`/mcp/linear-v1` by default). Change the path to
whatever you want.
## 3. Set inbound authentication with your identity provider
Click **Next** and choose how end users prove who they are before they reach the
server. If your organization runs single sign-on, this is where it plugs in:
[Auth0](https://zuplo.com/docs/mcp-gateway/auth/configuring-auth0),
[Okta](https://zuplo.com/docs/mcp-gateway/auth/configuring-okta),
[WorkOS](https://zuplo.com/docs/mcp-gateway/auth/configuring-workos),
[Entra](https://zuplo.com/docs/mcp-gateway/auth/configuring-entra),
[Google](https://zuplo.com/docs/mcp-gateway/auth/configuring-google), and the
rest of the
[OIDC presets](https://zuplo.com/docs/mcp-gateway/auth/configuring-generic-oidc)
each have a setup guide. The same login your team already uses now gates the MCP
server too.
Select **Auth0**. The wizard names the inbound policy and tells you which
environment variables it needs. Note the names down; you'll add the values once
you've finished the wizard.
## 4. Curate the tools you expose
Click **Next** to decide what the upstream exposes downstream. Two options:
| Option | What it does |
| --------------- | ---------------------------------------------------------------------------------------- |
| **Passthrough** | Every tool, prompt, and resource the upstream exposes flows straight through, untouched. |
| **Curate** | The Gateway lists everything the upstream offers and you tick exactly what to expose. |
Passthrough is fine when you trust the upstream completely. Choose **Curate**
for control. The Gateway groups the tools by what they can do, so Linear's
catalog splits into read-only tools, safe write tools, and destructive tools.
Switch the destructive ones off and they never reach the client.
We front Linear, Stripe, and Notion this way internally, and stripping the
destructive tools is the first thing I do on every new upstream.
Curating out destructive tools is the cheapest guardrail you'll set up all
week. The LLM physically cannot call a tool the virtual server doesn't expose,
so there's no prompt-injection path to a tool you've filtered.
## 5. Choose how the Gateway authenticates upstream
Click **Next** for the last step: how the Gateway talks to Linear on the user's
behalf. Pick the model that matches the upstream.
| Upstream auth | When to pick it |
| ------------- | ----------------------------------------------------------------------------------------------------------- |
| **OAuth** | The upstream speaks OAuth, like Linear. Leave registration on **Dynamic** and the Gateway registers itself. |
| **API key** | Custom or partner servers that hand out keys instead of running an OAuth flow. |
Linear is OAuth, so leave it selected, keep **Dynamic** registration, and click
**Finish**. Nothing here is manual.
You'll see the request chain Zuplo built: authenticate with Auth0, call the
Linear upstream, filter out the tools you dropped. Click **Save** to deploy.
## 6. Add your identity provider's environment variables
Before anyone connects, Auth0 needs its credentials. This assumes you already
have an Auth0 application; if you don't, create one (a standard web app is
fine). Open the inbound policy to see the three variables it expects: the Auth0
domain, client ID, and client secret. Grab those from your Auth0 application's
settings.
In Zuplo, go to **Settings**, then **Environment Variables**, and add the three.
Saving redeploys the environment so they're live. If you don't have access to
the Auth0 project, this is the step to hand to whoever does.
The wizard shows the variable names, not the values. Skip this step and the
connect flow fails at the Auth0 screen with nothing obviously wrong in the
config. Add the values, let the redeploy finish, then connect a client.
## 7. Connect the Gateway from your MCP client
Back in the **Code** tab, copy your project's Gateway URL (shown at the top of
the route view) and append the route path (`/mcp/linear-v1`) to get the full URL
clients connect to. Then, in Claude:
1. Open **Settings**, then **Connectors**, and choose **Add custom connector**.
2. Name it, paste the URL, and click **Add**. Claude reports you're not
connected yet.
3. Run the connect flow. It walks you through Auth0, you authenticate, and Zuplo
asks you to authorize access to the Linear upstream.
4. Approve it.
The connector now lists exactly the tools you curated: read-only and safe write,
with the destructive ones absent. Ask Claude "what is my latest ticket?" and the
call routes through the Gateway.
## 8. Watch every tool call in MCP analytics
Back in the portal, open the **Analytics** tab and select **MCP**. Every call
you just made shows up: total events, the top capabilities (list issues, in this
case), the top users, success rates, and any upstream errors. With a team
connected, this is where you see which tools get used, by whom, and how often:
the visibility that was missing when everyone wired up their own MCP servers in
the shadows. It sits next to the
[Agents analytics we shipped in May](/blog/introducing-agents-analytics).
## Going from Development to Production
The wizard doesn't say so, but everything you just built lives in your **Working
Copy**, Zuplo's development environment. Saves deploy instantly, which is
exactly what you want while you're testing the gateway and running the connect
flow. It's not where production agents should point.
For production we recommend two changes. Connect source control so deployments
come from a git branch instead of portal edits, which gives you review,
rollback, and the preview environments that sit between Working Copy and
production. Then put the gateway on a custom domain, so the URL you hand to
clients is one of yours rather than a generated dev hostname.
That's one server. Add a route for every other MCP server your team touches,
custom and partner servers included, and each gets the same auth, curation, and
audit trail.
The MCP Gateway is in public beta on every plan, the free tier included, so
there's nothing to wait for.
[Spin up a free Zuplo project](https://portal.zuplo.com/signup?utm_source=zuplo-blog&utm_medium=web&utm_campaign=mcp-gateway)
and front your first MCP server today.