mcpgw vs the alternatives
This page compares mcpgw to four common alternatives operators consider before deploying it. The goal is honest positioning: where does mcpgw save you work, and where does another tool fit better?
The TL;DR for impatient readers:
- vs DIY proxy: mcpgw saves the policy/audit/telemetry plumbing — about a quarter of an SRE per long-running deployment.
- vs egress firewall: solves a different problem. Run both.
- vs network firewall (L4): same — different layer, run both.
- vs nothing: do something. Even a one-page deny rule + audit log is enormously valuable.
vs DIY proxy
You can write a JSON-RPC proxy in Go in a weekend. People do. The first version takes two days and looks great in a slide.
Then you start operating it.
You realize you need:
- An audit log with rotation, gzip, and structured fields. That’s a week of polish for the rough edges (atomic rotation, append-only safety, JSONL schema discipline).
- OpenTelemetry export with a span model that doesn’t change every minor version. That’s another week to land on stable attribute names.
- Hot-reloadable policy. Now you have an
atomic.Pointerand you have to think about in-flight requests crossing the swap. Add a few days for tests that actually catch the races. - A deny model that’s both expressive enough to be useful and constrained enough to be auditable. This is design work, measured in weeks.
- Rate-limiting that scales to hundreds of sessions without blowing up memory or breaking on key-skew.
Everything on this list is solvable. Each piece is two to ten days of work for someone who knows Go and OTel. mcpgw exists because the aggregate — the integrated, supported, deployed-by-many-people version — is what saves time.
When to DIY anyway: if your MCP traffic shape is unusual (binary, custom JSON-RPC extensions, non-standard transports) or you have a hard requirement that mcpgw doesn’t yet meet. The DIY value is bespoke fit; mcpgw’s value is integration.
vs egress firewall (Cloudflare WARP, Tailscale ACLs, Squid, etc.)
Egress firewalls answer: “Should this agent be allowed to reach this destination?” That’s a different question from mcpgw’s.
mcpgw answers: “Should this MCP call be allowed to do this thing?”
The questions look similar from a distance. They diverge when you ask:
| Question | mcpgw | Egress firewall |
|---|---|---|
Block tool shell_exec regardless of which upstream serves it | yes | no — the firewall sees a single TCP flow |
Allow git_clone but redact bearer tokens in arguments | yes | no — TLS is opaque to the firewall |
Audit who called db_query with which arguments | yes | no — the firewall sees only TLS handshakes |
| Block traffic to a malicious domain | no | yes |
| Block exfiltration to non-allowlisted destinations | no | yes |
The right deployment is both. The egress firewall is your network-layer perimeter; mcpgw is your application-layer policy. They have orthogonal failure modes and stack cleanly.
If you only have time for one, pick based on threat:
- “Agents could exfiltrate data to attacker-controlled servers” → egress firewall first.
- “Agents could call dangerous tools or leak secrets in arguments” → mcpgw first.
In practice, both threats are real and the answer is to deploy both, sequenced.
vs network firewall (L4)
L4 firewalls (iptables, AWS Security Groups, GCP firewall rules) answer “should this IP/port flow be permitted?” That is even further removed from mcpgw’s domain.
A useful framing: the L4 firewall protects from the agent’s environment; the egress firewall protects to the destination’s environment; mcpgw protects what the agent does. All three layers are necessary in adversarial deployments.
mcpgw does not replace your network firewall. It complements it.
vs nothing (the most common alternative)
The honest comparison most operators are choosing between is “use mcpgw” vs “leave the MCP server unprotected and hope.” Almost every team we talk to is in the second state.
Even a minimal mcpgw deployment — three deny rules, a wildcard regex redact, audit on, no telemetry — gives:
- A single line of evidence per tool call, kept on the gateway, queryable with
jq. Worth its weight in incidents. - An emergency “pull this tool” lever that’s faster than a code change to the upstream MCP server.
- A natural place to add policy as the threat surface expands.
The downside of mcpgw vs nothing is exactly two things: one extra hop of latency (~1ms p50) and one more thing to operate. Both are small, both are well-understood. The upside is large and front-loaded — you start collecting audit value on day one.
When mcpgw is the wrong choice
Three honest scenarios where mcpgw isn’t the answer:
Your “MCP server” is in-process, not a network service. Some agent frameworks expose tools through in-process function calls rather than a separate MCP server. mcpgw can’t sit between two parts of the same process. Look at agent-framework-level instrumentation.
You want to audit MCP traffic but cannot tolerate any added latency. mcpgw adds about 1ms p50 and 5ms p99 in our benchmarks. If your latency budget is sub-millisecond, mcpgw is too costly. Most agent workflows are not.
You’re at a scale where a custom solution pays for itself. If you have 500+ MCP servers and dozens of platform engineers, the integration economics flip — you can afford to build something perfectly fitted. mcpgw’s value is for teams whose time-to-policy is measured in days, not in headcount-quarters.
For everyone else, the default answer is “yes, deploy mcpgw, start collecting audit data, write three deny rules, see what you learn in two weeks.” That deployment is small enough to roll back if it doesn’t pay off, and almost always does.
Related
- Architecture — what mcpgw does internally
- Quickstart — get to that two-week experiment fast