# What is an MCP gateway?

> An MCP gateway is a service between MCP clients and several MCP servers. What the spec says it must handle, what it adds, and what it cannot fix.

Source: https://www.honeyhive.ai/learn/mcp-gateway (updated 2026-11-07)

An MCP gateway is a service placed between MCP clients and several MCP servers, so that connecting, authorizing and logging tool calls happen in one place instead of in every client. The [MCP specification](https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices) does not define the term. It defines an "MCP proxy server" and describes proxy architectures with their risks, and that is the part of the spec a gateway has to live within.

The spec gives a way to judge any gateway: what it must validate, which tokens it may touch and what it adds to the attack surface. For the protocol itself, see [the Model Context Protocol](/learn/model-context-protocol).

## What the spec already assigns to someone

A gateway does not create new duties. It moves existing ones to a shared place, and the spec says who owns each.

| Duty | What the spec says | Where a gateway fits |
|---|---|---|
| Token validation | Servers must [validate](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization) that access tokens were issued specifically for them as the intended audience | A gateway that presents itself as an MCP server to clients is that server, and must do this check |
| Upstream credentials | A server calling upstream APIs uses a [separate token](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations) from the upstream authorization server and must not pass through the client's token | The gateway holds or obtains its own upstream credentials |
| Input and access control | Servers [must](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) validate tool inputs, implement access controls, rate limit invocations and sanitize outputs | A gateway can enforce these centrally, but each server is still responsible for its own |
| Confirmation and audit | Clients [should](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) prompt for confirmation on sensitive operations, show inputs before calling and log tool usage for audit | The client still owns confirmation. A gateway can keep a shared log |
| Caching | List results must carry a `cacheScope` of "public" or "private", which [controls](https://modelcontextprotocol.io/specification/2026-07-28/changelog) whether shared intermediaries may cache the response | A gateway is a shared intermediary, so it has to respect the scope |
| Trace context | The 2026-07-28 revision [documents](https://modelcontextprotocol.io/specification/2026-07-28/changelog) OpenTelemetry trace context propagation conventions for `_meta` keys (`traceparent`, `tracestate`, `baggage`) | A gateway can pass trace context through so one trace spans client, gateway and server |

## Tokens are the hard part

The spec's most specific warnings about intermediaries concern credentials.

Token passthrough is, in the spec's words, an [anti-pattern](https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices) where an MCP server accepts tokens from a client without validating that they were issued to it and passes them to the downstream API. The spec lists what goes wrong: rate limiting, request validation and traffic monitoring downstream can depend on the token audience and get bypassed, the server cannot tell clients apart, downstream logs show a different identity, and a token accepted by several services lets an attacker who compromises one reach the others. A gateway that forwards the user's token to every server behind it is token passthrough at scale.

The confused deputy problem is the second one. The spec [defines](https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices) an MCP proxy server as one that acts as a single OAuth client to a third-party API, and says the attack becomes possible when four conditions hold together: a static client ID, dynamic client registration, a consent cookie set by the third party, and no per-client consent at the proxy. Proxies that act this way must implement per-client consent. The 2026-07-28 revision also [deprecates](https://modelcontextprotocol.io/specification/2026-07-28/changelog) dynamic client registration in favor of Client ID Metadata Documents, though it remains available for backwards compatibility. A gateway that fronts third-party APIs with one shared OAuth client matches that description.

The MCP roadmap shows the gap is still open. Its maintainers [write](https://modelcontextprotocol.io/development/roadmap) that authorization assumes a person with a browser at consent time, that callers are increasingly agents, and that existing servers lean on pasted API keys and long-lived refresh tokens. The roadmap lists DPoP, workload identity federation and token exchange as work in progress, and says it reflects current thinking rather than firm commitments. See [AI agent identity](/learn/ai-agent-identity) for the identity side.

## Tool sprawl is a separate problem

Anthropic's engineers [wrote](https://www.anthropic.com/engineering/code-execution-with-mcp) in November 2025 that most MCP clients load all tool definitions upfront into context, and that with thousands of tools an agent processes hundreds of thousands of tokens before it reads a request. The same post says every intermediate result must pass through the model.

A gateway sits where a tool list could be narrowed, since clients get tools from `tools/list`, which the spec [says](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) supports pagination. Whether to filter there is a design choice, not something the spec asks for. The roadmap points the other way as well: it [lists](https://modelcontextprotocol.io/development/roadmap) progressive discovery as a priority, where clients learn a server's tools as they need them instead of ingesting the full catalog. Both approaches address the same cost, so decide which layer should own it.

## What a gateway cannot fix

- **Untrusted servers stay untrusted.** The spec says clients [must](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) treat tool annotations as untrusted unless they come from trusted servers. A gateway that merges many servers into one list makes it harder for a client to tell which server a tool came from, so keep that origin visible. The tools spec [says](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) clients or proxies that aggregate tools from several servers should handle name collisions, for example by prefixing tool names with a server identifier. For the attacks this covers, see [MCP security](/learn/mcp-security).
- **A gateway concentrates credentials.** The spec describes a local proxy that spawns servers over stdio, and [warns](https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices) that a stolen proxy authentication token can give an attacker remote code execution with the user's privileges. It recommends sandboxing spawned processes and logging all stdio usage.
- **People still approve risky calls.** The tools spec says there [should](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) always be a human in the loop with the ability to deny tool invocations. A gateway sits behind the client, so approval stays a client feature. See [human in the loop](/learn/human-in-the-loop-ai).
- **It adds a hop to operate.** Every gateway is one more service to secure, scale and debug, and the spec's duties above still apply to it.

## Do you need one

This table is a rule of thumb built from the sources above, not part of the spec.

| Situation | Suggestion |
|---|---|
| One client, one local stdio server | No gateway. The [client launches](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports) the server as a subprocess |
| Several remote servers, one team | A gateway can centralize audit logs and rate limits. Check that it validates audience and does not pass tokens through |
| Many users or agents, third-party APIs behind the servers | A gateway only if it can give each caller a distinct identity upstream, since passthrough and shared OAuth clients are the failure cases above |
| Tool lists grow into the hundreds | Test filtering or progressive discovery against your own agent before choosing where to put it |

The same question comes up for model calls. For that case, see [LLM gateway](/learn/llm-gateway), and for how MCP differs from a plain API, [MCP vs API](/learn/mcp-vs-api).

## Tracing MCP calls through a gateway

A gateway log shows that a call happened. It does not show why the agent made it. HoneyHive's docs on [tracing MCP servers and clients](https://docs.honeyhive.ai/v2/tracing/mcp-tracing.md) describe two routes: OpenInference auto-instrumentation, which the docs mark as experimental, and `@trace` decorators, which they recommend for production. With `@trace` you add details such as tool name, arguments, errors and retries through `enrich_span`. For the general practice, see [distributed tracing](/learn/distributed-tracing) and [LLM observability](/learn/llm-observability).

## FAQ

### What is an MCP gateway?

A service placed between MCP clients and several MCP servers, so access control, routing and logging happen in one place. The MCP specification does not define the term; its [security page](https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices) defines the nearest thing, an MCP proxy server.

### Is an MCP gateway part of the MCP specification?

No. The authorization and security pages of the spec do not use the word. The spec does describe proxies, and it requires that [servers never accept tokens](https://modelcontextprotocol.io/specification/2026-07-28/basic/security_best_practices) not issued to them, which applies to any gateway that acts as a server.

### Can a gateway forward the user's token to the MCP servers behind it?

No. The authorization spec [says](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/security-considerations) the access token used at an upstream API is a separate token from the upstream authorization server, and the MCP server must not pass through the token it received from the client.

### Does a gateway make MCP tools safe?

No. Servers still must validate inputs and enforce access controls, and clients must treat tool annotations as untrusted unless they come from trusted servers, according to the [tools spec](https://modelcontextprotocol.io/specification/2026-07-28/server/tools). A gateway adds a place to enforce rules. It does not replace those duties.

### Do I need an MCP gateway for one local server?

Usually not. The spec [describes](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports) stdio as the client launching the server as a subprocess, which has no network hop to put a gateway on. The case for one grows with the number of servers, users and remote endpoints.