MCP Proxy

An MCP proxy is a server that speaks the Model Context Protocol on both sides: it accepts one MCP client connection and forwards each request to whichever upstream MCP server owns the tool. To the client it looks like one server exposing every tool. That single path matters for security: without a proxy, each MCP server is a separate connection with its own credentials, and there is nowhere to attach authentication, audit, or policy. A gateway adds those on top of a proxy.

How an MCP proxy works

The proxy is an MCP server to the client and an MCP client to each upstream. On connect it calls tools/list against every upstream and merges the results into one catalog, remembering which server owns each tool and prefixing the name on a collision. When the client calls a tool, the proxy forwards it to the owning upstream and streams the response back, so adding or removing a backend never touches client code. That same seam is where a gateway inserts policy: because every message passes through, a call can be checked, redacted, or dropped before it moves on.

Aggregation and transport bridging

One agent that needs GitHub, Slack, and a database would otherwise open three connections and manage three credential sets; the proxy presents them as a single session and one tool namespace. It also bridges transports: an MCP server speaks either STDIO (a local process over stdin/stdout) or streamable-HTTP (a remote URL), and a proxy can front several STDIO servers behind one HTTP endpoint so a remote client reaches tools built to run locally. See MCP malware risks for why STDIO servers are a security concern.

Running an MCP proxy: local and remote

Where a proxy runs follows from the transports it bridges. A local MCP proxy runs on your own machine and fronts one or more STDIO servers, each a child process it speaks to over stdin/stdout, so a single CLI agent reaches several local tools through one connection. A remote MCP proxy listens on a streamable-HTTP URL so a cloud or mobile client can reach it, and it can wrap those same STDIO servers, turning tools built to run locally into ones callable over the network. You can run a proxy yourself and point it at each upstream as a command or a URL, or use a hosted one so you never have to host, secure, or scale the endpoint. SealGate runs the remote shape as a managed, per-user endpoint, described next.

The per-user composite proxy in SealGate

SealGate runs a proxy of this shape on FastMCP. Each user gets an isolated composite instance, keyed by their API key, that wraps every enabled server into one endpoint; instances share no state between users. Every call is relayed through SealGate and policy-checked before it reaches the upstream - that enforcement is detailed in MCP Gateway. The API key rides as a segment of the URL path, so any streamable-HTTP client connects with no extra header wiring; treat that URL as a credential - the key is per-user and revocable. See Connect an Agent for the exact URL format.

Frequently asked questions