MCP Proxy

An MCP proxy sits between an MCP client and one or more upstream MCP servers, aggregating their tools into a single endpoint and relaying every tool call to the right server. How it works, and why you put one in front of your MCP servers.

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.

9:41
ChatGPT 5
Pull my open GitHub issues and draft replies
On it. Reading your assigned issues now and drafting a reply for each.
Ask anything
9:41
ChatGPT 5
Pull my open GitHub issues and draft replies
On it. Reading your assigned issues now and drafting a reply for each.
Ask anything
MCP proxyaggregates tools
One inbound session; the proxy routes each call to the owning server and bridges its transport.

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.

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

Put SealGate between your agents and your tools

One gateway that blocks the Lethal Trifecta, enforces access levels, and audits every tool call - no code changes to your agents.