An MCP gateway aggregates multiple MCP servers behind one endpoint, so an agent connects once instead of being configured with a dozen servers and a dozen credentials. It adds central authentication and authorisation, per-tool filtering, credential injection so developers never hold upstream secrets, and a call log for audit. Real options in August 2026 include the Docker MCP Gateway, IBM ContextForge, Portkey MCP Gateway, and TrueFoundry. The category is roughly a year old, aggregation is not part of the MCP specification, and the token-handling rules the spec does define are ones a careless gateway violates.
- An MCP gateway fronts tools. An LLM gateway fronts models. Different layers.
- The real problem it solves is credential distribution, not connectivity.
- Tool filtering matters more than aggregation: 200 tools in one context degrades tool choice.
- Aggregation is not in the MCP spec. Namespacing and filtering are per-vendor inventions.
- The spec forbids token passthrough. A gateway forwarding your token upstream is doing it wrong.
- Solo developer with three servers: you do not need this. Fifty developers with twenty servers: you do.
What it is and what it fixes
Without a gateway, every developer configures every MCP server locally: a GitHub server with their GitHub token, a Slack server with a Slack OAuth grant, a database server with credentials someone pasted into a config file. Multiply by twenty engineers and eight servers and you have 160 credential placements, no inventory, and no way to revoke anything centrally.
A gateway inverts that. One endpoint, one credential per client, and the upstream secrets live in the gateway.
before agent -> github-mcp (dev holds a GitHub token)
agent -> slack-mcp (dev holds a Slack grant)
agent -> postgres-mcp (dev holds db credentials)
... x 20 developers
after agent -> mcp gateway -> github-mcp
-> slack-mcp
-> postgres-mcp
(dev holds one gateway key; the gateway injects the rest)| Job | Why it matters |
|---|---|
| Aggregation | One endpoint in the client config instead of N. The visible feature, and the least important one. |
| Credential injection | The gateway holds OAuth tokens and API keys and attaches them per upstream server. Developers never see them. |
| Authorisation | Which user or team may reach which server, and which tools within it. |
| Tool filtering | Expose eight tools, not two hundred. This is a quality feature, not a tidiness one. |
| Audit logging | Who called what, when, with which arguments. The reason security teams fund these. |
The options in 2026
| Option | Shape | Notable |
|---|---|---|
| Docker MCP Gateway | Open source, MIT, 1,535 stars | Runs each MCP server in an isolated container with restricted privileges, network, and resources. Profiles (--profile) decide which servers a client sees. Built-in call tracing. The wider Docker AI Governance surface around it is invite-only. |
| IBM ContextForge | Open source, Apache 2.0, 4,341 stars | Gateway, registry, and proxy in front of MCP, A2A, and REST or gRPC APIs. The most "platform" of the open options, and correspondingly more to run. |
| Portkey MCP Gateway | Commercial, alongside its LLM gateway | Authenticates the agent's key or IdP token, checks whether that user may reach the server and the tool, injects the right upstream credential, proxies, and logs the full exchange. Supports external identity providers including Okta and Auth0. |
| TrueFoundry | Commercial, enterprise-focused | Sells a "virtual MCP server" abstraction: aggregate tools from several physical servers into one logical endpoint per use case, with OAuth 2.0 identity injection so an agent acts on behalf of a specific user. |
Two patterns are converging across all of them, and they are the features to compare on rather than the branding: namespacing, so two servers can both expose a tool called search without colliding, and virtual servers, where you assemble a curated tool set per team or per agent instead of exposing everything to everyone.
The authorisation problem, which is the interesting one
MCP's own specification is unusually specific about tokens for HTTP transports, and it is specific in ways that a naively built gateway violates. It is worth knowing the rules before you evaluate a vendor, because they make good evaluation questions.
- An MCP server is an OAuth 2.1 resource server. It must implement Protected Resource Metadata (RFC 9728) and return a
WWW-Authenticateheader on 401 pointing at that metadata. - Clients must send a resource indicator (RFC 8707) in both authorisation and token requests, naming the canonical URI of the server the token is for.
- Servers must validate the audience. A token issued for a different service must be rejected, not accepted because it happens to be valid.
- Token passthrough is explicitly forbidden. If the gateway calls an upstream API, it acts as an OAuth client to that API with a separate token. It must not forward the token it received from the client.
A related consequence: a gateway is a lovely place to put an audit log and a terrible place to put a token you did not intend to centralise. Aggregating twenty servers' credentials into one service means that service is now the highest-value target in your estate. Threat-model it like a secrets manager, because that is what it became.
When a team needs one, and the honest maturity read
You probably need one when
- More than roughly ten people are configuring the same MCP servers by hand.
- Any upstream credential is something you would have to rotate across many laptops if it leaked.
- Someone has asked which tools an agent is allowed to call, and you had no answer.
- You are hitting tool-count problems and want per-team curation rather than per-developer discipline.
You do not need one when
- You are one developer with three servers. Local config is simpler, faster, and has no failure mode you did not create.
- Your servers are all vendor-run remotes with OAuth. The credential problem you would be solving is already solved.
- You are hoping it will fix agent quality. It will not; filtering the tool list will, and you can do that in a client config today.
Questions people ask
What is an MCP gateway?
A single MCP endpoint that aggregates many MCP servers behind it. Clients connect once instead of being configured with each server individually, and the gateway handles authentication, decides which servers and tools each client can see, injects the upstream credentials, and logs every tool call.
What is the difference between an MCP gateway and an LLM gateway?
Layer. An LLM gateway sits in front of model providers and routes model requests. An MCP gateway sits in front of tool servers and routes tool calls. They solve analogous problems for different resources, and some vendors, Portkey among them, now sell both under confusingly similar names.
What are the best MCP gateways?
In August 2026 the credible options are the Docker MCP Gateway (MIT, container-isolated servers, profile-based tool filtering), IBM ContextForge (Apache 2.0, gateway plus registry plus proxy), Portkey MCP Gateway (identity-aware, injects upstream credentials, supports Okta and Auth0), and TrueFoundry (virtual server abstraction for enterprises).
Do I need an MCP gateway?
Not as an individual developer with a handful of servers: local configuration is simpler and adds no failure mode. You need one when many people configure the same servers by hand, when upstream credentials would be painful to rotate across laptops, or when someone needs to answer which tools an agent is permitted to call.
Is MCP server aggregation part of the MCP specification?
No. The specification covers the protocol and, for HTTP transports, an OAuth 2.1 authorisation flow with protected resource metadata, resource indicators, and audience validation. Aggregating several servers behind one endpoint, namespacing their tools, and filtering which are exposed are all vendor inventions, so implementations differ and migration between them is not a config change.
Should an MCP gateway forward my token to upstream servers?
No. The MCP specification explicitly forbids token passthrough: if the gateway calls an upstream API it acts as an OAuth client to that API with a separate token issued by that API's authorisation server. Forwarding the client token creates the confused-deputy problem the spec names directly, and it is a good question to ask any vendor.
Sources
Every figure above was read from these pages on August 2026. Vendors reprice without notice; if you find a stale number, tell us.
- MCP specification: authorization
- Docker MCP Gateway documentation
- docker/mcp-gateway on GitHub MIT, 1,535 stars, read 19 August 2026
- IBM/mcp-context-forge on GitHub Apache 2.0, 4,341 stars
- Portkey MCP Gateway documentation
- TrueFoundry MCP Gateway