An MCP gateway is not a proxy

As of April 2026, most teams asking about “MCP gateways” are really asking about three different problems wearing the same name. This post is a brief field guide to which problem you have, and why the answers are not interchangeable.

The three problems people call “MCP gateway”

A transport multiplexer terminates many MCP server connections behind one address. Useful for hosting, mostly invisible to clients.

A policy gateway enforces auth, tenancy, rate limits, and prompt-injection defenses across multiple MCP servers. This is what enterprises usually mean.

A tool catalog aggregates tool definitions from many servers and presents them as one. Useful when an LLM client cannot speak to N servers directly.

WYRE’s gateway is all three, but they are designed and reasoned about separately.

Why “proxy” is the wrong mental model

A proxy forwards bytes. A gateway makes decisions. The decisions in an MCP gateway are not at the byte level — they are at the tool-call level. Which tools is this tenant allowed to see? Is this argument inside policy? Did a prior tool result poison the next tool call?

Reaching for a proxy library at this layer makes the next six months of feature work harder.

What we’d build first if we started over

Tool-call policy first. Auth second. Multi-server aggregation third. The first one constrains every later decision; we wish we’d locked it down earlier.