An MCP proxy changes how a client and a server connect. It takes a server that speaks one transport, such as stdio, and makes it reachable over another, such as Streamable HTTP, or the reverse. An MCP gateway does that plus the work around it: authentication, tool policy, logging and routing across several servers. Many tools are called either one, so check what each actually does.
What is an MCP proxy?
An MCP proxy sits between an MCP client and an MCP server and forwards messages unchanged. Its one job is translation between transports. The Model Context Protocol defines two standard transports: stdio, where the client launches the server as a local subprocess, and Streamable HTTP, where the server runs somewhere else and the client calls a URL. Older servers may still use the legacy SSE transport. The MCP transports documentation describes all of them.
The mismatch shows up in practice. Some clients only launch local stdio servers. Plenty of servers now live behind an HTTP URL. A proxy closes that gap so the two can talk. It does not decide who may call what, and it does not keep a record of calls unless you add that yourself.
The reason this matters for non-developers is simple. If Claude Desktop or another app shows a config file asking for a command, you are in stdio territory, and a proxy is what lets that command point at a remote URL. If instead the app takes a connector URL, as Claude.ai and ChatGPT do, you do not need a proxy at all: the server just has to be reachable over Streamable HTTP. See Streamable HTTP for how that transport works.
Some people search for "mcp reverse proxy". In the MCP world that usually means one of two things. It can be a general-purpose web reverse proxy such as nginx or Caddy placed in front of an HTTP MCP server for TLS and routing. Or it can mean an MCP-aware layer that fronts one or more servers. The first is plain web infrastructure. The second is closer to a gateway.
What is mcp-proxy, the open-source project?
When people type "mcp-proxy" with a hyphen, they often mean a specific open-source tool: sparfenyuk/mcp-proxy on GitHub. Its README describes it as a tool that lets you switch between server transports, and it supports two modes.
- stdio to SSE or Streamable HTTP. The client launches
mcp-proxyas if it were a local stdio server. The proxy connects out to a remote server URL. This is how a stdio-only client such as an older Claude Desktop setup reaches a remote server. Pass--transport=streamablehttpwhen the remote server uses Streamable HTTP. - SSE to stdio. The reverse direction: the proxy launches a local stdio server and exposes it on a network port, so remote clients can reach it.
It also takes --headers and OAuth2 client credential options for authenticating to the remote server, and a named-server option so one process can front several backends. You install it with uv tool install mcp-proxy, pipx or a container image. Two limits matter. You run it and keep it patched. And it forwards calls; it does not give you per-tool allow or deny rules or call logs of its own.
A related small tool is mcp-remote, run as npx mcp-remote <server-url>. It does the stdio-to-remote half of the job for clients that cannot connect to a URL directly.
What does an MCP gateway add?
A gateway is a single entry point for many MCP servers and many clients. Transport bridging may be part of it, but the point is control. Typical additions:
- Authentication. Clients present one key or token to the gateway instead of holding credentials for every server. See MCP authentication.
- Tool policy. You decide which tools are visible and callable. Read tools stay on, write or destructive tools stay off. The deeper case is in controlling what AI agents can reach.
- Logging. A record of which tool was called, by which client, and when.
- Multi-server routing. One URL fronts many servers, and the gateway sends each request to the right one.
For a definition of the term itself, see the MCP gateway glossary entry. This page covers only how it differs from a proxy.
MCP proxy vs MCP gateway: side by side
| MCP proxy | MCP gateway | |
|---|---|---|
| Main job | Bridge transports (stdio, SSE, Streamable HTTP) | Central control point for many servers and clients |
| Authentication | Passes headers or OAuth credentials to one server | One key or token for clients, credentials held per server |
| Tool allow or deny | No, forwards every tool | Often, per tool or per profile; check the product |
| Call logging | Not built in | Often built in; varies by product |
| Multiple servers | Possible (named servers) but no policy | Routes many servers behind one endpoint |
| Who runs it | You | You (self-hosted) or the provider (hosted) |
| Examples | mcp-proxy, mcp-remote | Docker MCP Gateway, LiteLLM, MCPifex |
Which tools are proxies and which are gateways?
The names blur in the wild, so judge each tool by features, not label.
- mcp-proxy is a pure transport bridge, as covered above. Self-run, no policy layer.
- Docker MCP Gateway. The open-source docker/mcp-gateway runs MCP servers in isolated Docker containers and exposes them behind one endpoint. Docker's docs say profiles choose which servers are available. You run it on your own Docker setup. See the Docker documentation and our MCPifex vs Docker MCP Gateway comparison.
- LiteLLM MCP Gateway. Part of the LiteLLM proxy. It adds centralized access control with API-key or OAuth auth, and connects to remote HTTP or SSE servers and stdio servers launched from a command. You host LiteLLM. See the LiteLLM MCP docs.
- Cloudflare. Cloudflare's remote MCP server guide shows how to build and host your own server on Workers, with the code written by you. A local bridge such as mcp-remote then connects stdio-only clients to it.
- Hosted gateways such as MCPifex. The gateway and the servers behind it are run for you. More on that below.
How do you choose between them?
Start from the gap you actually have.
- Is the only problem that client and server do not share a transport? You need a proxy. Nothing more.
- Do several servers, clients or people need one set of rules? You need a gateway, because that is where auth, tool policy and logs live.
- Who will operate it? A proxy or a self-run gateway is software you install, upgrade and secure. A hosted gateway moves that work to the provider.
- Do you need to restrict tools, not just reach them? A proxy forwards every tool the server exposes. If a server has a delete tool, the AI can call it. Only a policy layer lets you switch that off.
Whichever you pick, test with your real client. Make one call that should work and one that should be refused. The MCP security checklist lists what else to verify.
Where does MCPifex fit?
MCPifex is a hosted gateway. You pick a server in the marketplace, such as PostgreSQL, save your own credentials, and choose which tools are allowed. MCPifex runs the real server package and gives you an API key. Every instance is reached through the same URL, https://mcp.mcpifex.com/mcp. Clients that cannot send headers can put the key in the URL path instead. Write and destructive tools start off, tools outside the catalog are refused, and each instance keeps call logs. The gateway page and security and data docs have the details.
Verdict: should you choose a proxy, a gateway or MCPifex?
Choose a proxy when you already run the server, you trust everyone who can reach it, and the only obstacle is stdio versus HTTP. mcp-proxy or mcp-remote solves that in a few minutes and adds nothing you have to learn.
Choose a gateway when you need shared authentication, tool allowlists, call logs or routing across several servers, and you have people to run it. Docker MCP Gateway and LiteLLM fit teams that already operate containers or an LLM proxy.
Choose MCPifex when you want Claude, ChatGPT, Claude Code or Cursor to reach one of the live servers (PostgreSQL, Google Trends, Google Search Console, App Store Connect or WhatsApp) without installing Node, Python or Docker, and you want to decide which tools your AI may use. MCPifex is not the right pick if the server you need is not in its catalog. The Free plan covers 3 instances with no card, so you can try it against your own client.
Sources
- Transports, modelcontextprotocol.io.
- Architecture, modelcontextprotocol.io.
- sparfenyuk/mcp-proxy, GitHub.
- geelen/mcp-remote, GitHub.
- MCP Gateway, LiteLLM documentation.
- docker/mcp-gateway, GitHub.
- Build a Remote MCP server, Cloudflare Developers.
Quick answers
An MCP proxy forwards messages between an MCP client and server and converts between transports, for example stdio to Streamable HTTP. It does not add tool rules or logging by itself.
It is the open-source sparfenyuk/mcp-proxy project. It runs in two modes: stdio to SSE or Streamable HTTP, so a stdio-only client can reach a remote server, and SSE to stdio, which exposes a local stdio server over the network. You install and run it yourself.
Only if you need more than connectivity. If you want shared authentication, per-tool allow and deny, call logs, or one endpoint for several servers, a gateway covers that. If you only need to bridge stdio and HTTP for a server you run, a proxy is enough.
Not always. A web reverse proxy like nginx adds TLS and routing in front of an HTTP MCP server but knows nothing about MCP tools. A gateway understands MCP and can filter or log tool calls.
A hosted gateway. It runs the MCP servers for you, filters the tool list to what you enabled, refuses other calls, keeps call logs per instance, and gives you one URL for every server.
Ready to try it?
Run hosted MCP servers behind one endpoint and choose exactly which tools your AI can use.