If you’ve searched for an “MCP gateway”, you’re usually hitting a practical problem:
You have multiple MCP servers (files, GitHub, search, internal APIs, etc.).
Each client (Claude Desktop, Cursor, a custom agent, etc.) wants its own config.
Secrets and permissions start to sprawl.
An MCP (Model Context Protocol) server exposes tools and resources to an AI client. MCP is an open standard—think “USB-C for AI apps.”^1
An MCP gateway sits in the middle and gives you a single entrypoint where you can centralize:
which MCP servers are enabled
which tools are exposed
authentication and token handling
logging / auditing
This tutorial shows how to host MCP servers on Zo Computer in a “gateway-shaped” way: one stable endpoint, durable processes, and security guardrails.
Prerequisites
A Zo Computer (your own always-on Linux server)
At least one MCP server you want to run (local or remote)
Step 1: Decide what you’re actually trying to expose
Before you set up infrastructure, write down the smallest useful tool surface.
Examples:
“Let my coding assistant read only
Projects/my-app/and nothing else.”“Expose one internal API tool, but don’t let the agent have general shell access.”
“Expose search + GitHub issues, but make credentials and rate limits centrally managed.”
This matters because MCP is powerful: if you expose a filesystem tool pointed at /, you effectively gave an AI the ability to read your whole server.
Step 2: Put MCP servers on Zo as managed services (so they stay up)
On Zo, the clean way to keep long-running processes alive is to run them as a managed service (auto-restart, logs, stable port).
The pattern:
Run each MCP server on
localhost(never directly public)Expose one “front door” service as your gateway entrypoint
Even if you don’t run a formal, off-the-shelf “MCP Gateway” product, this structure gets you most of the benefit: one stable endpoint and centralized control.
Step 3: Choose your “gateway” approach
There are two common options.
Option A (simple): one remote MCP server that aggregates the tools you need
Instead of running 8 separate MCP servers, you run one MCP server that defines exactly the tools you want, and those tools call out to:
your internal services
a database
a handful of safe scripts
This is often the best production default because it’s explicit. There’s no “tool sprawl” unless you add it.
Option B (classic): a real MCP gateway that fronts multiple MCP servers
A gateway can proxy/aggregate tool discovery and tool calls across multiple upstream servers.
A concrete example of this architecture is Docker’s MCP Toolkit/Gateway: it runs MCP servers in isolated environments and unifies them behind one gateway surface, with secret isolation and OAuth support.^2
Even if you don’t use Docker’s implementation on Zo, the architecture is the key idea you want.
Step 4: Security rules you should apply on day 1
MCP’s official security guidance calls out a few failure modes that show up quickly in real deployments.
Don’t do token passthrough
Token passthrough is when your “gateway/server” accepts a token from a client and blindly forwards it to downstream services.
The MCP spec explicitly forbids this pattern and recommends that MCP servers only accept tokens that were issued for that MCP server.^3
Practical rule: your gateway should terminate auth and mint/forward its own credentials, not act as a dumb pipe.
Assume prompt injection will happen
If any MCP tool reads remote content (webpages, issues, docs), assume an attacker will try to smuggle instructions into that content.
Practical rules:
keep tool permissions narrow
log tool calls
scope file access to a specific directory
avoid tools that can run arbitrary commands unless you truly need them
Treat sessions carefully
The MCP spec also discusses session hijacking and event injection risks in stateful HTTP setups, and recommends binding session IDs to user-specific information and validating inbound requests.^3
Practical rule: if you expose a gateway over HTTP, don’t let a random bearer of a session ID become “the user.”
Step 5: Add observability (minimum viable)
If your gateway is going to be used by agents, you need to answer:
What tool was called?
With what arguments?
By which client/user?
Did it succeed?
Even basic request logs are enough to catch:
runaway loops
unexpected access patterns
“why did it delete that file?” incidents
Step 6: Use Zo’s built-in durability to make this boring
The big advantage of running MCP infrastructure on Zo is that it’s not ephemeral.
Config lives in your files
Logs live on your server
The gateway can be restarted and upgraded like any other service
Agents and workflows can evolve without losing state
If you want MCP tools to be reliable, you want boring infrastructure.
Where to go next
If you’re new to MCP, start with the official overview and core concepts.^1
If you’re building anything beyond local-only experiments, read MCP’s security best practices and implement the “no token passthrough” rule early.^3
If you want to connect Zo to external systems without exposing MCP at all, Zo’s built-in web tools are a safer on-ramp:
read_webpage(fast extraction) andview_webpage(full browser rendering + screenshot).^4