What Is an MCP Gateway? Definition and How It Works

An MCP gateway is a single endpoint that sits in front of one or more MCP servers. Your AI client connects to the gateway instead of to each server. The gateway checks who is calling, routes the request to the right server, enforces which tools are allowed, and logs what happened. You manage those rules in one place.

What does an MCP gateway do?

The Model Context Protocol lets an AI app call tools on a server: query a database, read a report, send a message. Without a gateway, every client holds its own connection and its own credentials for every server. Add three servers and two clients and you maintain six setups.

A gateway collapses that into one connection per client. It does four jobs:

• Routing. The gateway receives a request and sends it to the right backend server. Some gateways merge the tool lists of several servers into one list.
• Authentication. The client proves who it is once, with an API key or an OAuth token. The gateway then holds the credentials each server needs, so those never sit in the client. See MCP authentication.
• Tool policy. You decide which tools each caller can see and call. Anything not on the list is refused.
• Logging. Every call is recorded, so you can answer "what did the AI do, and when?"

How does an MCP gateway work?

A request passes through the gateway in five steps:

1. The client opens a connection to the gateway URL and sends a key or token.
2. The gateway authenticates the caller and finds which servers and tools that caller is allowed to use.
3. The client asks for the tool list. The gateway returns only the allowed tools.
4. The client calls a tool. The gateway checks the call against policy, forwards it to the backend server, and returns the result.
5. The gateway writes a log entry for the call.

On the wire, the MCP specification defines two transports: stdio, where a client starts a server as a local subprocess, and Streamable HTTP, where the server is reachable over the network (transport spec, spec version 2025-06-18). Most gateways speak Streamable HTTP to the client. On the other side they either forward HTTP to a remote MCP server or start a local server over stdio and translate between the two. Because the client only ever sees the gateway, the servers behind it are not exposed directly.

What is the difference between an MCP server and an MCP gateway?

An MCP server exposes tools: it does the actual work, such as running a SQL query. A gateway does not provide tools of its own. It stands between clients and servers and controls access. The same protocol runs on both sides, so a client cannot tell the difference and does not need to.

TermWhat it doesSits whereControls access?

MCP server

Provides tools and runs them

Behind everything

Only its own login, if any

MCP gateway

One endpoint with routing, auth, tool policy and logs

Between client and servers

Yes, per caller and per tool

MCP proxy

Forwards traffic, often one server at a time or across transports

Between client and server

Usually not

MCP registry

A directory where you find servers

Outside the request path

No

The gateway and proxy labels overlap in practice. A plain proxy relays messages and may convert stdio to HTTP. A gateway adds policy and visibility on top. The page MCP gateway vs proxy goes through the cases. A registry only helps you discover servers. It never sees your traffic. See MCP registry.

What are examples of MCP gateways?

As of October 2026, these examples fall into two groups: software you operate, and services someone else operates.

• Docker MCP Gateway. Runs MCP servers in containers and manages their credentials and routing on your machine or infrastructure (Docker docs). You install and run it.
• LiteLLM. An open-source LLM proxy that also offers an MCP gateway feature, so teams already routing model traffic through it can add MCP servers with keys and access groups (LiteLLM docs). You host it.
• Cloudflare. Provides tooling to build and deploy remote MCP servers on its network, with OAuth support (Cloudflare docs). You write and deploy the code.
• Hosted gateways such as MCPifex. The provider runs the servers and the gateway, and you connect a client to a URL. Details are in the next section.

Each fits a different team. For a side-by-side, read best MCP gateways.

How does MCPifex work as a gateway?

MCPifex is a hosted gateway at https://mcp.mcpifex.com/mcp. In the portal you pick a server, save your own credentials, choose which tools are allowed and get an API key. Then you paste the one URL into Claude, ChatGPT, Claude Code or Cursor. Write tools start off. Calls to tools outside the catalog are refused, each session runs in its own process, and each instance has a call log. Nothing is installed on your side. See the gateway page or the quickstart.

When do you need an MCP gateway?

You probably do not need one if you use a single server on your own laptop and trust it with all its tools. Direct connection is simpler.

A gateway starts to pay off when any of these is true:

• You use more than one server or more than one AI client, and configuration is multiplying.
• A server has tools that can change or delete data, and you want some switched off.
• Several people share access and you want one place to grant and revoke it. See MCP for teams.
• You need a record of what the AI called.
• The server must be reachable from web clients like Claude.ai or ChatGPT, which need a remote URL rather than a local process.

A concrete case: a marketer connects Claude to Google Search Console and a PostgreSQL database. Without a gateway, each connection needs its own setup in each client, and the database server exposes every tool it has. With a gateway, the marketer adds one URL, turns on the read tools and leaves the write tool off. Later, teammates can work from the same shared workspace instead of repeating the setup, and the database login stays in one place.

What are the security considerations for an MCP gateway?

A gateway concentrates trust, so its security matters more than any single server. Points to check:

• Least privilege. Allow only the tools a job needs. Reads on, writes off until required.
• Credential handling. Prefer a gateway that keeps backend credentials server-side and gives clients a separate key you can revoke. The MCP authorization spec is built on OAuth 2.1 for HTTP transports (authorization spec, spec version 2025-06-18).
• Token passthrough. The spec warns against servers accepting tokens that were not issued for them. A gateway should validate tokens, not blindly forward them (security best practices, spec version 2025-06-18).
• Isolation. Separate sessions and users so one cannot read another's data.
• Prompt injection. A gateway cannot read intent. A malicious document can still steer the AI toward an allowed tool, so tool policy is your main limit. See prompt injection through MCP tools.
• Logging. Confirm you can see which caller invoked which tool, and that logs do not leak secrets.

Also treat the gateway itself as a single point of failure and a high-value target: if you self-host, you patch it.

How do you choose an MCP gateway?

Ask these questions in order:

1. Who runs it? Self-hosted gives control and costs operating time. Hosted removes the work and adds a provider to trust.
2. Is policy per tool? Per-server on/off is too coarse for servers with a mix of read and write tools.
3. Which clients connect? Check that it works with the clients you use, including web clients that cannot send custom headers.
4. What auth does it support? API keys are simple. OAuth fits team and enterprise sign-in.
5. Can you see calls? Look for per-caller logs.
6. Which servers are available? A gateway with no servers you need is just plumbing.

Sources

1. Transports, Model Context Protocol Specification (spec version 2025-06-18)
2. Authorization, Model Context Protocol Specification (spec version 2025-06-18)
3. Security Best Practices, Model Context Protocol (spec version 2025-06-18)
4. MCP Gateway, Docker Docs

← Back to glossary