MCP gateways ranked / What is an MCP gateway

What an MCP gateway is and when you need one

An MCP gateway is a proxy between AI agents and the MCP servers they use. It decides who may call which tool, with which credential, and keeps a record of every call.

Last reviewed

The short answer

The Model Context Protocol (MCP) is an open protocol that lets AI applications call tools and read data through MCP servers. An MCP gateway is a single entry point in front of those servers. Clients such as Claude, Cursor, ChatGPT or your own agents connect to the gateway instead of to each server. The gateway then:

  • authenticates the person and the agent behind each request,
  • supplies the credential the downstream tool needs, so clients never hold it,
  • decides whether this tool call, with these arguments, is allowed,
  • records the call and its result, and
  • presents one combined list of approved tools to the client.
Agents connect to one gateway, which connects to MCP serversIDE agentChat clientInternal agentCode hostTicketingDatabaseMCP gatewayWho is calling?Which credential?Is this call allowed?Record itAGENTS AND CLIENTSMCP SERVERS
Every request passes one point that knows the user, holds the credential, applies policy and logs the result.

What happens without a gateway

In the default setup each client is configured with each MCP server directly. A local server runs as a process on the user's machine over stdio; a remote server is reached over Streamable HTTP. Credentials sit wherever the client put them: a config file, an environment variable, a token cache.

That works for one developer. With ten people, four clients and twenty servers it means:

  • Connections multiply. Every client-server pair is configured separately, so a change to one server is a change in every config that uses it.
  • Tokens spread. Personal access tokens and API keys end up copied into files on laptops, often with broader scopes than the task needs.
  • No one place to say no. There is no point where you can block a destructive tool, require approval, or revoke one person's access across every client.
  • No shared record. Each server logs (or doesn't) in its own way, and few tie a call back to the person and agent that made it.
  • Unknown servers. People install MCP servers from public registries and repositories without review. Security can't govern what it can't see.

What an MCP gateway does

Identity on every call

The gateway signs users in through your identity provider and attaches a verified user and agent identity to each request. That is what makes per-person policy, revocation and audit possible. More in MCP OAuth and credential handling.

Credential brokering

Instead of every client storing tokens, the gateway runs the OAuth flow with each downstream service, keeps the resulting per-user tokens (or issues short-lived ones), and adds them at call time.

Policy

Because the gateway speaks MCP, it sees tool lists and tool calls, not just HTTP requests. It can hide tools an agent shouldn't see, block specific tools or arguments for a group, and hold risky actions for human approval.

Audit and observability

A single point of passage means one consistent log of who called what, with which arguments and result, and one place to emit traces and metrics (ideally OpenTelemetry) into the tools your team already uses.

Threat detection

Some gateways inspect tool descriptions, requests and responses for MCP-specific threats such as tool poisoning, prompt injection and data exfiltration.

Discovery and a catalog

The more complete products also find MCP servers in use outside the gateway and publish a catalog of approved ones, so the governed path is also the easy one.

When direct connections stop being enough

You need a gateway when any of these is true:

  1. More than one person shares a server. You need to know which person made each call and to revoke access one person at a time.
  2. Agents can write. Once tools can merge code, change records, send messages or move money, you need rules at tool-call level and, for some actions, a human in the loop.
  3. Tokens live on laptops. If removing a leaver means hunting for tokens in config files, the credentials belong in a gateway.
  4. Someone will ask "who did this?" Security reviews, incident response and compliance audits need an attributable record you can export.
  5. You don't know what's installed. If MCP servers are appearing in client configs without review, you need discovery as well as a gateway.
A rule of thumbIf MCP is still one engineer's experiment, a local gateway such as Docker's keeps servers contained. Once it is a team or company rollout, choose a gateway that scores well on authentication, credentials and policy in the ranking.

What an MCP gateway isn't

  • Not just an API gateway. An API gateway routes HTTP. An MCP gateway understands tools, tool lists and tool calls, which is where agent risk lives. Some API gateways add MCP support; check how deep it goes.
  • Not an LLM gateway. LLM gateways route model requests (prompts and completions) between model providers. Several products do both, but they are different jobs.
  • Not a replacement for least privilege downstream. A gateway enforces policy on the way in; downstream systems should still grant the minimum scopes.

Kinds of MCP gateway

  • Local gateways run beside one user's client and contain servers on that machine (Docker MCP Gateway, Lasso MCP Gateway).
  • Open-source proxies you deploy and configure as infrastructure (agentgateway, IBM ContextForge, Microsoft MCP Gateway).
  • API gateways with MCP support that extend existing API management to MCP (Kong AI Gateway).
  • Platforms that combine a gateway with identity, catalog, policy, audit and discovery (Runlayer, Obot).

See how each one scores in MCP gateways ranked.