Compare

MCP Proxy vs. MCP Gateway: Hosting, Routing, and Policy

An MCP proxy usually bridges transports, for example letting a stdio-only client reach an HTTP server. An MCP gateway usually goes further and adds shared routing, authentication or tool policy behind one endpoint. Neither name promises that someone else runs the server for you, so check who operates it.

A quick example

Say your client only speaks stdio, but the server you want lives at an HTTP URL. A proxy sits on your machine, looks like a stdio server to the client, and forwards everything to the URL. Nothing else changes.

Now say your team runs five MCP servers and you're tired of every client holding five sets of credentials. A gateway gives them one endpoint, one auth scheme, and one place to log and restrict tool calls. That's a different job with a similar name.

Why "proxy" and "gateway" are fuzzy

Neither is an MCP spec term. The architecture only defines hosts, clients and servers. The ecosystem made up both names.

The spec also defines two transports: stdio, for a local subprocess, and Streamable HTTP, for remote servers. Plain SSE is the older, superseded transport. Some proxy docs still assume it.

mcp-proxy: a transport bridge

sparfenyuk/mcp-proxy is the tool that matches the name. Install it with uv tool install mcp-proxy, pipx install mcp-proxy or Docker. Point it at a stdio command or a remote SSE or Streamable HTTP URL, and it converts one to the other.

The --named-server flag lets one process front several backends. --headers and OAuth2 client-credential flags handle auth outbound. It can launch a stdio subprocess, but you supply the package, the environment, the credentials and the machine it runs on.

Gateways you run yourself

Several gateways manage servers for you, but you operate the gateway.

  • LiteLLM MCP Gateway. Centralized access controls with API-key or OAuth auth. Configure servers in its UI or YAML. It supports remote HTTP or SSE endpoints, and can launch stdio servers from a command, arguments and environment variables. You still host LiteLLM and install what those commands need.
  • Docker's mcp-gateway. Runs each server in its own container from an OCI-based catalog, with per-profile tool allowlists. docker mcp gateway run --profile <name> --port 8080 --transport streaming starts the containers behind one port. This is the open-source Toolkit; Docker also offers an Enterprise Gateway with different deployment options. See MCPifex vs. Docker's mcp-gateway.
  • Lasso's MCP Gateway. Manages configured servers and adds plugins that inspect requests and results. Its repository documents basic secret masking, optional Presidio-based PII handling, and a separate Lasso service integration that needs an API key.

Inspecting content and enforcing permissions are different jobs. A filter may flag suspicious output. An authorization rule decides whether an operation runs at all. Test both.

Cloudflare's remote-MCP guide

This solves a third problem: building your own server and hosting it on Workers. The mcp-remote shim (npx mcp-remote <server-url>) then lets a stdio-only client reach it. It's a small local proxy, useful if you're the one writing and operating the server. It doesn't hand you a catalog of ready-made servers.

Side by side

ToolWhat it solvesWho runs the serversHosted endpoint?
mcp-proxystdio and SSE/HTTP bridgingYouNo, you host the proxy
LiteLLM MCP GatewayCentral access to remote or stdio serversYou, through LiteLLMNo, you host LiteLLM
Docker mcp-gatewayContainerized servers, per-profile allowlistsYou, in your Docker environmentNo
Cloudflare + mcp-remoteDeploying and reaching your own serverYou write and host itOn your Workers
Lasso MCP GatewayServer management plus request inspectionYouNo
MCPifexCatalog servers hosted for youMCPifexYes, https://mcpifex.com/mcp

Where MCPifex fits

As of September 2026, MCPifex is a managed option. You create an instance of a server such as PostgreSQL in the portal, save its credentials, and choose which tools are enabled. You get an API key, and we run the real server package.

Every instance uses the same URL. The key goes in a Bearer header, or in the URL path (https://mcpifex.com/mcp/mcpx_...) for clients that can't set headers. The tool list is filtered to what you enabled, and any other call is refused, including tools outside our catalog. Read the MCP gateway entry and security and data for details.

Which should you use?

  • A transport bridge when compatibility is the only gap and you already operate the server.
  • LiteLLM or Docker when you want central configuration in an environment you run.
  • Lasso when its inspection plugins match a real requirement.
  • MCPifex when the server you need is in our catalog and you'd rather not operate it.

Whichever you pick, test your exact client with one allowed call and one that should be denied. See the quickstart, the marketplace and the pricing page.

Sources

  1. Transports, modelcontextprotocol.io.
  2. MCP Specification, Architecture, revision 2026-07-28.
  3. sparfenyuk/mcp-proxy, GitHub.
  4. MCP Gateway, LiteLLM documentation.
  5. docker/mcp-gateway, GitHub.
  6. Build a Remote MCP server, Cloudflare Developers.
  7. Lasso, MCP Gateway and inspection plugins
  8. Docker, profiles and tool selection
  9. Docker, gateway and manual Docker Engine installation