MCP Gateway vs MCP Server: What's the Difference?
Short answer: an MCP server exposes one product's capabilities to AI agents. An MCP gateway sits in front of many servers and presents them as a single endpoint, adding the cross-cutting things no single server can provide: shared auth handling, one catalog, an audit trail, and (in some gateways) memory. A server is a door into one tool. A gateway is a keyring.
And here is the sentence that causes all the confusion, so let's face it immediately: from your agent's point of view, a gateway IS an MCP server. Your client connects to it exactly the way it connects to any server, sees a tools list, and calls tools. The difference is entirely in what stands behind the endpoint.
What an MCP server is
An [MCP server](/blog/what-is-an-mcp-server) is a program that speaks the Model Context Protocol on behalf of one system: your CRM, a database, a browser, a directory. It advertises that system's actions as tools (search_contacts, run_query, create_ticket), executes calls against the real backend, and handles that one system's authentication.
One server, one system, one slice of capability. The vendor builds it once and every MCP-capable agent can use it. That is the whole point of the standard.
What an MCP gateway is
An [MCP gateway](/blog/what-is-an-mcp-gateway) does not wrap a product. It wraps your collection of servers. You connect your servers to the gateway once, and your agents connect to a single gateway endpoint. Behind that endpoint the gateway merges the tool catalogs (namespaced, so github__search and crm__search stay distinct), stores and applies each upstream's credentials, routes every call to the right server, and logs what happened.
The mechanism doing the heavy lifting is federation, which we unpacked separately in [MCP federation explained](/blog/what-is-mcp-federation). The gateway is the product around that mechanism, and the extras are where gateways differ: credential vaults, per-connection revocation, audit trails, and in our case a memory layer.
The side-by-side
| MCP server | MCP gateway | |
|---|---|---|
| Represents | One product or system | Your whole set of connected servers |
| Who builds it | The tool's vendor (or community) | An infrastructure provider, or you self-host one |
| Auth | That product's login | Brokers credentials for every upstream |
| Tools list | Fixed by the product | Composed, changes as connections change |
| Adds | Capability | Management: one endpoint, policy, audit, sometimes memory |
| You need one when | You want an agent to use that tool | Servers, credentials, or clients have multiplied |
Why the confusion exists, and the mental model that resolves it
The confusion is baked into the protocol's elegance: MCP composes. A gateway implements the server side of the protocol toward your agent while acting as a client toward every upstream server. Same interface, different role. So "is it a server?" has two true answers: technically yes (that is why any MCP client can connect to it without special support), functionally no (it represents your infrastructure, not a product).
The mental model that sticks: a server is a door, a gateway is a keyring. Doors belong to buildings; the keyring belongs to you. Nobody confuses their keyring with a door, even though both are involved in getting inside.
The naming mess in the market does not help, to be fair. Some products called gateways front model APIs rather than tools, which is a different animal entirely; we sorted that one out in [MCP gateway vs LLM gateway](/blog/mcp-gateway-vs-llm-gateway).
Which one do you actually need?
Start with servers, always. If your agent needs to reach your project tracker, what you need is that tracker's MCP server, and you can check [whether it has one](/blog/does-your-app-have-an-mcp-server) in two minutes. One or two servers on one machine need no gateway at all.
The gateway question arrives with multiplication: more servers, more machines, more teammates, more credentials. When configs drift between clients, when keys live in too many files, when nobody can say what the agent did last week, the missing piece is not another server. It is the keyring. Our honest checklist for that moment is in [do you need an MCP gateway yet](/blog/do-you-need-an-mcp-gateway).
Since we build one: [Tulimoa's gateway](/gateway) is a federating endpoint with an encrypted credential vault, per-connection revocation, an audit trail, and built-in memory tools, EU-hosted, in early beta and not self-serve yet. The distinction in this article stands regardless of whose gateway you evaluate.
Frequently asked questions
Is an MCP gateway just a big MCP server?
To your client, it looks like one, which is the clever part: no special client support needed. Architecturally it is the opposite of "just": it is a client of many servers on one side and a server to your agents on the other, with auth, routing, and policy in between.
Can I use MCP servers without a gateway?
Absolutely, and with one or two servers you should. Direct connections are simpler. Gateways earn their place when servers, credentials, clients, or teammates multiply.
Does a gateway replace the servers behind it?
No. The gateway routes to real servers; it does not reimplement them. If your CRM has no MCP server, a gateway cannot conjure one, though some gateways bridge plain APIs as a workaround.