MCP Gateway: What It Does, When You Need One, and What Still Belongs in the Server

As companies go from one MCP server to twenty, gateways and registries promise one endpoint, one login and one audit log. They solve real problems, and they can't fix a server that trusts every token. Here is how to tell what you need.

Hugo Matthaey

Hugo Matthaey

Oct 17, 2026

A gateway arch receiving connections from several assistant hubs on one side and fanning out to locked servers on the other, with a filter grid sorting tool tokens inside

An MCP gateway sits between AI clients and your MCP servers: one endpoint for Claude, ChatGPT, Cursor or your agents, sign-in through your identity provider, rules on which servers and tools each user sees, and one log of every call. An MCP registry is the catalog of approved servers that a gateway enforces. Both exist because MCP adoption went from one experimental server to dozens per company, each with its own URL, login and permissions, and security teams want one place to control and audit them. They solve real problems. They don't replace security in the servers themselves: a gateway can't fix a server that accepts any token, which is exactly what LiteLLM's MCP endpoint did this year. Below: what a gateway does, when you need one, the 2026 options, and what still belongs in the server.

What a gateway does

  • One endpoint. Clients connect once, instead of being configured for every server.
  • Identity. Users sign in with your identity provider, and the gateway passes or exchanges credentials for each server.
  • Access rules. Which users and groups can reach which servers, and sometimes which tools.
  • Tool filtering. Each user or client gets only the tools they need, which also keeps the model's context small.
  • Logging and audit. One record of who called which tool, when, and with what result.
  • Traffic controls. Rate limits, and on some products scanning of tool descriptions and responses.

A registry answers "which servers exist and are approved", with owners and descriptions, so people stop installing random servers from the internet.

When you need one

You probably need a gateway when:

  • you run, or allow, more than a handful of MCP servers;
  • several teams or external clients connect, with different permissions;
  • your security team needs one place for access rules and logs;
  • people are installing third-party MCP servers you haven't reviewed.

You probably don't yet when:

  • you have one or two servers you build or control;
  • the users are your own staff, signing in with your identity provider;
  • the servers already do OAuth, per-tool permissions and logging.

At that size, a gateway adds a moving part without removing any work, because the servers still need to be secure.

The options in 2026

The market is young and moving fast, so treat this as a map, not a ranking:

  • Managed: Cloudflare's MCP server portals, part of Cloudflare One, put several MCP servers behind one endpoint, with Cloudflare Access identity policies deciding which servers each user sees.
  • Open source, self-run: agentgateway, a Linux Foundation project, and MCP gateways from Docker, Microsoft and IBM, which a platform team deploys itself.
  • From API gateway vendors: Kong and others have MCP registry and gateway features, some still in preview.

Evaluate against your own needs: which identity provider, whether you need per-tool filtering or only per-server access, where logs must go, and who will run it.

What still belongs in the server

Whatever sits in front, each MCP server must:

  1. Check every token itself: issuer, audience (minted for this server) and expiry. A gateway in front doesn't make an unchecked token safe.
  2. Apply the user's own permissions to the data, read from your database on each call, not a service account that sees everything.
  3. Separate reads from writes, and refuse writes from read-only callers before the tool runs.
  4. Treat a session ID as a label, never a credential.

The year's MCP incidents were all server-side: LiteLLM's MCP endpoint accepted any bearer token, and Grafana's MCP server accepted session IDs it had never issued. We covered both in MCP security in 2026.

How we run ours

Our own setup follows the "controls in the server" model, because we build and run the servers:

  • One server, many tools. Our operations server exposes 91 tools from several modules through one endpoint, so clients connect once. How that works.
  • Tool lists filtered per caller. The server can resolve each caller's role and return only the tools that role should see, which is the gateway's tool-filtering job done in the server.
  • Per-tool scopes derived from each tool's read or write annotation, with roles re-read from the database on every call, in our CRM's MCP server.
  • Open-source conformance tests for the authentication path, in rflkt/mcp.

For a client with many servers and teams, we would put a gateway in front of servers built this way, not instead of it.

Related: MCP security in 2026, how to build an MCP server, and Claude connectors explained.