MCP gateway and proxy tools compared

An MCP gateway or proxy sits between your agents and your MCP servers, giving you one place to apply authentication, access control, logging, and policy. That single choke point is the whole security argument: it is where you enforce least privilege, capture an audit trail, and run guardrails before tool calls reach a server. Below we compare five real, open-source tools, describing each only from what its repository documents. Feature and plugin lists in this space move fast, so treat specifics as a snapshot and re-check the repo before you commit.

TL;DR:

• Docker MCP Gateway (repo): a Docker CLI plugin that manages MCP servers, with tool allowlisting, profiles, OAuth flows, and Docker Desktop secrets. MIT licence.
• Lasso Security MCP Gateway (repo): a plugin-based intermediary focused on guardrails, with tiered secret masking, PII detection via Presidio, and prompt-injection checks. MIT licence.
• IBM ContextForge (repo): a registry and proxy that federates MCP and other APIs with centralised governance, RBAC, JWT and OAuth, and an admin UI. Apache-2.0 licence.
• TBXark mcp-proxy (repo): aggregates many MCP servers behind one HTTP entrypoint, bridging stdio, SSE, and streamable HTTP. MIT licence.
• sparfenyuk mcp-proxy (repo): a focused bridge between streamable HTTP or SSE and stdio, in two directions. MIT licence.
• For the controls these gateways enforce, see the MCP security best practices guide.

Why put a gateway in front of MCP servers?

MCP is now the default way agents gain capabilities, so the connection between an agent and its tools is a high-value attack surface. Without a gateway, each client talks to each server directly, which scatters credentials, scopes, and logs across many places. A gateway collapses that into one mediating layer.

The security benefits of a single choke point are concrete. You can enforce least privilege by exposing only the tools an agent actually needs, you get a central audit log of every call, and you can run guardrails, for example secret masking or injection checks, before a request or response passes through. For the wider picture of what an MCP server can do wrong, see what is MCP.

What does Docker MCP Gateway do?

Docker MCP Gateway is a Docker CLI plugin that manages MCP servers behind a unified gateway. Per its documentation, it supports stdio by default plus streaming HTTP on a configurable port and SSE for multi-client scenarios. Its security-relevant features include tool allowlisting per server using dot notation, profile-based organisation of servers, OAuth flows for service authentication, and keeping secrets out of environment variables via Docker Desktop’s secrets management. It is released under the MIT licence.

What does Lasso Security MCP Gateway do?

Lasso Security MCP Gateway is a plugin-based intermediary that sits between LLMs and MCP servers and, per its repo, leans hardest into content guardrails. It documents three plugin tiers: a basic tier masking secrets such as GitHub, AWS, and JWT tokens, a Presidio tier detecting PII like credit cards, emails, and SSNs using Microsoft’s Presidio, and a Lasso tier adding custom policy, prompt-injection, and harmful-content checks. It also documents a security scanner that analyses server reputation before loading a server. It is MIT licensed.

What does IBM ContextForge do?

IBM ContextForge, also called MCP Gateway, describes itself in its README as “an open source registry and proxy that federates MCP, A2A, and REST/gRPC APIs with centralized governance, discovery, and observability”. Per its documentation it can expose services over stdio, SSE, HTTP/JSON-RPC, streamable HTTP, and WebSocket at once, wrap non-MCP services as virtual MCP servers, and federate multiple gateways. Its governance features include JWT tokens, OAuth, RBAC, rate limiting, content size limits, a plugin system, and an admin UI with real-time logs. It is under the Apache-2.0 licence.

What do the two mcp-proxy tools do?

These two are narrower, transport-focused tools rather than full governance layers. TBXark mcp-proxy aggregates multiple MCP servers behind a single HTTP entrypoint, bridging stdio, SSE, and streamable HTTP clients, and combining tools, prompts, and resources from many servers. It is MIT licensed.

sparfenyuk mcp-proxy is, per its README, “a bridge between Streamable HTTP and stdio MCP transports”. It runs in two modes: stdio to SSE or streamable HTTP, letting a local client reach a remote server, and the reverse, exposing a local stdio server to remote clients. It documents bearer token and OAuth2 authentication and is MIT licensed.

How do these MCP gateway tools compare?

The table sets out the practical differences. Everything here reflects each project’s public documentation at the time of writing; plugin and feature lists, especially guardrails, change frequently, so treat them as indicative and verify in the repo.

Tool	Primary role	Transport bridging	Auth (per repo)	Guardrails / policy	Licence
Docker MCP Gateway	Gateway + server management	stdio, streaming HTTP, SSE	OAuth flows, Docker secrets	Tool allowlisting, profiles	MIT
Lasso MCP Gateway	Guardrail-focused gateway	Proxy between client and servers	Plugin-based	Secret masking, Presidio PII, prompt-injection, reputation scan	MIT
IBM ContextForge	Registry + federating proxy	stdio, SSE, HTTP, streamable HTTP, WebSocket	JWT, OAuth, RBAC	Rate limits, size limits, plugins, admin UI	Apache-2.0
TBXark mcp-proxy	Aggregating proxy	stdio, SSE, streamable HTTP	Token auth (see usage)	Aggregation only	MIT
sparfenyuk mcp-proxy	Transport bridge	stdio to/from SSE, streamable HTTP	Bearer token, OAuth2	Transport only	MIT

Which is best for security guardrails?

If your goal is to filter what flows through tool calls, Lasso Security MCP Gateway documents the most explicit content guardrails, with secret masking, PII detection, and injection checks. IBM ContextForge documents the strongest governance posture for a team, with RBAC, rate limiting, and central observability. The two mcp-proxy tools deliberately do less: they move and aggregate traffic but do not claim to inspect content, so you would layer guardrails elsewhere.

Which is best for a quick bridge?

For simply getting a stdio-only client talking to a remote server, or the reverse, sparfenyuk mcp-proxy is the most focused option, and TBXark mcp-proxy is the natural pick when you also want to aggregate several servers behind one HTTP endpoint. Neither is trying to be a policy engine, which keeps them simple.

When should you pick which?

Pick Docker MCP Gateway if you already run Docker Desktop and want server management, allowlisting, and secrets handling in one familiar CLI. Pick Lasso Security MCP Gateway when masking secrets and PII in MCP traffic is the priority. Pick IBM ContextForge when you need team-grade governance, federation, and an audit trail across many servers and protocols. Pick TBXark mcp-proxy or sparfenyuk mcp-proxy when you only need transport bridging or aggregation and will add policy controls yourself.

Whichever you choose, the gateway is a control point, not a guarantee: a clean gateway config can still front a malicious server. Pair it with server vetting from MCP security scanners compared, and confirm the runtime controls in the MCP security best practices guide. The full tested-tool index lives in the tools directory.