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

An MCP server exposes the tools of one system, for example GitHub or a database. An MCP gateway stands in front of many MCP servers, APIs and functions. It presents them to agents as one endpoint. It adds authentication, access rules for each person, credential storage and an audit trail. A single server does not provide these.

Does one developer need an MCP gateway?

Usually not. One person with personal tools and no sensitive data can configure MCP servers locally. A gateway is useful when several people share the same systems, when credentials must not stay on laptops, or when someone must answer which agent did what for which person.

How much latency does an MCP gateway add?

This depends on the gateway and where it runs. We measured our own gateway on 5 October 2026. It added 29 milliseconds at the median for each tool call inside the same cluster. This covers authentication, authorization, tool resolution and the audit record. A typical real tool call takes about one second, thus the overhead is about 3 percent.

Is an MCP gateway the same as an API gateway?

No. An API gateway stands in front of your own HTTP APIs for clients that you control. An MCP gateway stands in front of tools for AI agents that act for people. It must know the person, the tools that the person may call, and the credentials for the upstream services. Some API gateway vendors now add MCP features.

Can an MCP gateway expose a REST API that has no MCP server?

Yes, if the gateway converts OpenAPI or Swagger specifications. The gateway reads the specification and turns each operation into a typed tool. In our test of 300 public specifications from apis.guru, 299 converted, and every operation became a tool. A small function in Node.js or Python covers a service without a specification.

What should an MCP gateway record for audit?

For every tool call: the person, the agent that acted for the person, the server, the tool, the time, the arguments or a redacted form of them, and the outcome. Calls that a rule blocked must also appear. The record must leave the gateway as a signed, machine-readable stream to the SIEM that your security team uses.

What Is an MCP Gateway?

Short answer: An MCP gateway is a server between AI agents and the tools that they call over the Model Context Protocol. Agents connect to the gateway one time. The gateway authenticates the person behind the agent. It decides which tools the person may use. It holds the credentials for the upstream services. It forwards each call and records who did what.

The problem a gateway solves

MCP gives an agent a standard way to call tools. Each MCP server exposes the tools of one system: GitHub, a database, Slack. For one person on one laptop, a configuration file is sufficient. The file lists the servers and contains the API keys.

The same setup fails for a team:

Credentials spread. Each person copies the same API keys into their own files. To rotate one key, you must find every copy.
Access is not selective. An agent that can reach a server can call every tool on it. The stored key decides the rights, not the person.
Nobody can answer the audit question. No record ties an action to a person, an agent and a time.
Setup repeats. Twenty people, ten servers and four agents give 800 configurations. They drift apart.

A gateway moves these four tasks from the laptops to one location.

What a gateway does

The core tasks are the same in every product. The depth differs.

One endpoint. Agents connect to one MCP server URL. The gateway shows each caller the tools that the caller may use, from every server behind it.
Identity. The agent authenticates to the gateway. Most products use OAuth, as the MCP authorization specification describes. The gateway ties the session to a person through the identity provider of the company, over SAML or OIDC. SCIM tells the gateway who joined and who left.
Credentials. API keys and OAuth tokens for the upstream services stay in the gateway, encrypted, for each person or each team. The agent never sees them.
Access control. Rules say who may see which server and which tool, by person, team or token claim. Better gateways also evaluate rules on the call itself. One example: block a delete call with a production path in its arguments. Gatana calls this the tool firewall.
Audit. The gateway records every tool call with the person, the agent, the server, the tool, the time and the outcome. It streams the records to a SIEM.
Adaptation. Systems without an MCP server become tools too. A gateway can read an OpenAPI or Swagger specification and turn each operation into a tool. It can run a function in Node.js or Python as a tool.
Efficiency. Hundreds of tools behind one endpoint cost tens of thousands of prompt tokens for each request for the tool list alone. Gateways answer this with tool search and with code mode. In code mode, the agent writes a short script against the tools and does not call them one by one.

What a gateway is not

Not an API gateway. An API gateway such as Kong or Cloudflare stands in front of HTTP APIs for clients that you wrote. It knows routes, rate limits and API keys. It does not know the person behind an agent or the meaning of a tool. Several API gateway vendors now add MCP features. This is a reasonable route if you already operate one of them.
Not an agent framework. The gateway does not plan, reason or orchestrate. It is infrastructure that any MCP-capable agent calls.
Not only a catalog. A list of approved servers is useful. A list without enforcement still leaves credentials on laptops and calls unrecorded.

When a team needs one

You need a gateway when at least one of these statements is true:

More than a few people use agents against shared systems.
Credentials for those systems must not stay in files on laptops.
A security or compliance team must see what agents did, for each person.
Access must follow the identity provider. A person who leaves the Okta group must lose the tools on the same day.
Agents must reach internal APIs and private services without exposure to the internet.

You do not need a gateway when one developer uses personal tools on their own data. Local configuration is correct there. A gateway only adds a hop.

What a gateway costs

A gateway adds a network hop and some work for each call. Measure the cost. Do not estimate it.

Latency. We timed our own gateway on 5 October 2026, from a probe inside the same cluster. A call through the gateway took 30.3 milliseconds at the median. The same call made directly took 1.4 milliseconds. The difference, about 29 milliseconds, covers authentication, authorization, tool resolution and the audit record. A real tool call takes about one second at the median. The overhead is thus about 3 percent. The method and the raw data are on the measurements page. Other gateways differ. Ask each vendor for a measurement, not a claim.

Tokens. The larger cost is often context, not latency. Every tool definition that the agent receives costs prompt tokens on every request. On a task over 10,000 records, direct tool calls used 1.33 million prompt tokens for each run. Code mode used 30,458 tokens, 44 times fewer, with the same model and the same correctness check. The full benchmark has all three tasks, including the small one where both modes cost the same.

Coverage. A gateway that converts specifications saves the work of writing MCP servers. We sampled 300 public OpenAPI and Swagger specifications from apis.guru. 299 converted into tools after we repaired four defects in our own converter. Details and the per-specification data.

The options, by where they run

The products differ most in who operates them and where the data is. The table groups them that way. The descriptions follow the pages of the vendors as of October 2026. Examine them before you decide. We make Gatana, thus weigh our row accordingly.

Where it runs	Examples	Fits when
On the machine of the developer, for one person	Docker MCP Gateway	One developer, local tools, no shared identity or audit necessary
Open source that you install and operate	Microsoft MCP Gateway, IBM ContextForge, Obot, lunar.dev MCPX, Bifrost	A platform team wants to operate it, read it and change it
Commercial platforms, hosted by the vendor or installed in your cloud	TrueFoundry, MintMCP, Composio, Gatana	A team wants SSO, audit and credential handling without building it. Gatana Cloud runs in the EU; Enterprise customers self-host it on Kubernetes
API gateways with MCP features	Kong, Cloudflare, Tyk, Traefik Hub, Zuplo	The organization already operates one of them for its APIs

How to evaluate a gateway

These questions separate the products quickly:

Does every call contain the identity of the person? Or does the gateway call upstream with one shared service account?
When a person is removed in the identity provider, when do they lose access? Immediately through SCIM, at the next login, or never?
Where are credentials stored? How are they encrypted? Who at the vendor can read them?
Can you write a rule on tool arguments? Or can you only permit and deny whole tools?
Which fields does the audit record contain? How does it reach your SIEM?
Can the gateway turn an OpenAPI specification or a function into tools? Or does every system need a hand-written server?
Where does the data live? Can you run the gateway yourself?
What is the measured latency for each call? Is the method published?

Where to go next

The gateway introduction in our documentation shows servers, tools and access in Gatana. The measurements page contains every number in this guide, with the date, the method and the raw data. We revise it when we measure again.