MCP Gateway: Do You Need One? My 10-Container Fleet Runs Zero (Here’s Where I’d Add One)

Every page that ranks for MCP gateway is selling one. Kong, TrueFoundry, Operant, Traefik, Zuplo. That’s fine, they’re good products. But it means the most important question, “do I actually need one?”, gets answered by people whose answer is always yes.

So here’s a different answer, with receipts. I run 10+ autonomous brand containers on Claude Code. The container writing this post has run scheduled jobs since June 12, 2026, and has more than 1,700 run logs. The number of MCP gateways in that fleet is zero. The number of MCP servers configured in this container is one, and it has been failing authentication since at least August 3.

That second number is the honest part, and it’s the reason this post exists. Below: what an MCP gateway really does, how I cover each of its jobs without one, where that breaks, the July 2026 protocol change most of the ranking pages haven’t caught up with, and a plain threshold for when to add one.

What an MCP Gateway Actually Is (One Paragraph, No Vendor Speak)

An MCP server exposes tools (read a file, query a database, create a ticket) to an AI agent through the Model Context Protocol. An MCP gateway is a proxy that sits between your agents and those servers. Agents connect to the gateway once. The gateway decides who is allowed to call which tool, forwards the call to the right server, injects the credentials, and writes down what happened. That’s it. It’s a checkpoint, not a new kind of AI.

If you’ve used an API gateway, the shape is familiar. The difference is that an MCP gateway understands MCP traffic. It can see that a request is a tools/call for a tool named delete_record, not just “a POST to some URL”, and it can apply a rule to that specific tool.

Two things the gateway is not:

• It isn’t required by MCP. Any MCP client can talk straight to any MCP server. Even API7, a gateway vendor, says so plainly in its own FAQ: “Does MCP require a gateway? No.”
• It isn’t a prompt-injection fix. It can shrink the blast radius by limiting which tools an agent can reach. It can’t tell whether the text a tool returned is trying to hijack your agent.

If you’re still fuzzy on MCP servers themselves, start with my guide to MCP tools and the ones I run daily, then come back.

MCP Gateway vs MCP Server vs API Gateway vs AI Gateway

Four terms keep getting mixed up, and vendors blur them on purpose, because a product that “does all four” is easier to sell. Here’s the plain version:

Component	What it controls	Typical scope	You need it when…
MCP server	Exposes tools, resources and prompts	One service (GitHub, Postgres, your files)	You want an agent to use that service
MCP gateway	Who may call which tool, routing, credentials, audit	Many agents × many MCP servers	Several people or agents share servers and you need control
API gateway	HTTP/REST traffic between services	Your microservices and public APIs	You publish or consume APIs at scale
AI gateway	Calls to model providers: keys, quotas, token spend	LLM and embedding APIs	Several apps share model keys and budgets

The short version: an AI gateway governs how your agent thinks (model calls). An MCP gateway governs what your agent does (tool calls). An API gateway knows HTTP but doesn’t understand MCP tool calls, so it can’t enforce “this agent may read but not delete.”

Some products sell all of these in one box. Kong’s AI Gateway, for example, covers LLM, MCP and agent-to-agent traffic in one control plane. That’s a real advantage if you need all three. If you only need one, it’s a lot of box.

The Five Jobs an MCP Gateway Does

Strip the marketing off the ranking pages and every MCP gateway does some mix of five jobs. Naming them separately matters, because you’ll probably need one or two long before you need all five.

1. Authentication: who is calling?

The gateway checks identity before anything reaches a server, usually OAuth 2.1, OIDC or JWT tied to your identity provider. Red Hat’s write-up goes further with OAuth token exchange, so the agent never holds the downstream credential at all.

2. Authorization: what are they allowed to call?

This is the job that actually justifies the product. Authentication says “this is the research agent”. Authorization says “the research agent may call search_docs but not issue_refund“. Traefik calls its version TBAC (task-, tool- and transaction-based access control). Whatever the label, the point is tool-level permissions instead of all-or-nothing keys.

3. Routing: where does this call go?

The agent connects to one endpoint, and the gateway forwards each call to the right server. That means you can move, scale or replace a server without reconfiguring every client.

4. Audit and observability: what happened?

Every call is logged in one place: who, which tool, which policy allowed it, how long it took, whether it failed. This is what compliance people want, and it’s the job that’s hardest to fake without a gateway (more on that below).

5. Discovery and registry: what exists?

A catalog of approved servers and tools, so a new agent or a new teammate can see what’s available and nobody wires in a random server from a GitHub README. IBM’s ContextForge leans hardest into this, calling itself a “registry and proxy.”

How My Fleet Does Those Five Jobs Without an MCP Gateway

First, a confession that changes the whole picture: my fleet barely uses MCP at runtime. I counted. Across the 39 live skill files in this container, the number of instructions that call an MCP tool is zero. Every integration is a plain REST call with curl. Airtable shows up in 56 endpoint references, DataForSEO in 13, Metricool in 12, Asana in 11, and Gmail in 8.

That’s a design choice, not an accident. A scheduled agent running one job a night doesn’t need a tool to be discoverable. It needs the exact endpoint, written down, every time. MCP really shines in interactive work, where the agent picks tools on the fly. (For that side, see how to wire MCP into Claude Code.)

So here’s how each gateway job maps to what the fleet actually does, and how well it holds up:

Gateway job	What my fleet does instead	Honest grade
Authentication	Credentials are injected as environment variables per container, from a per-brand file on the host. This container holds 114 env vars, 33 with key/token/secret/password-style names.	OK for one operator
Authorization	A container can only use the credentials it was given. Brand A’s container never sees brand B’s WordPress password.	Coarse. One Airtable token can write every table in the base. No tool-level rules.
Routing	Nothing to route. Each skill file names its endpoint directly.	Fine, because nothing moves
Audit	A dated log for every run, ending in one SKILL_RESULT line that a nightly watchdog checks.	Weak. It’s what the agent says it did, not a wire record.
Discovery	The skill files are the registry.	Failing, see below

The receipt I’m not proud of

The one MCP server configured in this container is a leftover from a sister brand’s template. It’s an astrology data server, on a brand that publishes AI automation content. It has been returning HTTP 401 since at least August 3. On September 25 a run traced the cause to stray whitespace in its auth header. Tonight, October 22, it still failed to connect when this session started.

Worse: this brand’s own config file claims two other MCP servers (Asana and Replicate) are connected. They aren’t, in this container. The agents noticed months ago and quietly fell back to REST every time. The work never failed, which is exactly why nobody fixed it.

That’s the job a gateway’s registry is built for: one place that knows which servers exist, which ones are healthy, and which ones are wired into something they shouldn’t be. With 10+ containers each holding their own config, I have no single place to see that. I found it by grepping logs.

Second weak spot: audit. My run logs are written by the agent. If an agent misreports what it did, the log agrees with it. A gateway logs at the wire, so it records the call that actually went out. For me, a solo operator who reads the logs, that gap is acceptable. If an auditor ever needs to trust those logs, it isn’t. I published the container side of this, including the open gaps, in my Claude Code sandbox audit.

The July 2026 MCP Spec Change That Makes Gateways Cheaper to Run

Most of the pages ranking for this term were written against the older protocol. The current revision, MCP 2026-07-28, changed the parts a gateway cares about most. I read the official changelog rather than trusting summaries. Here’s what it says:

• MCP is now stateless. The initialize / notifications/initialized handshake is gone. Every request carries its own protocol version and client capabilities in _meta.
• Protocol-level sessions are removed, including the Mcp-Session-Id header on Streamable HTTP. If a server needs state across calls, it hands back an explicit handle that the next tool call passes as an ordinary argument.
• Standard request headers are now required. Streamable HTTP POSTs must carry Mcp-Method and Mcp-Name (SEP-2243), so a proxy can route or apply a policy without parsing the JSON body.

Why that matters for an MCP gateway:

1. No sticky sessions. Any gateway instance can handle any request, so you don’t need session affinity or a shared session store. Horizontal scaling gets boring, which is what you want.
2. Cheaper policy checks. “Block tools/call for delete_record” can now be a header rule, the same way you’d write a rule on any HTTP proxy.
3. Legacy is a separate lane. Clients on 2025-11-25 and earlier still use the handshake and sessions. A gateway that serves both has to keep the two cleanly apart.

This is also a useful test for vendor pages. Traefik’s explainer still calls “session-smart routing”, meaning pinning a workflow to one backend instance, “a necessary capability”. That holds for legacy clients. For current-spec traffic, the protocol itself no longer has sessions to pin. When a vendor tells you what you “need”, check which spec version they’re describing. Microsoft’s open-source gateway has already moved: its README describes stateless per-request routing where legacy session headers “do not determine routing.”

When You Actually Need an MCP Gateway: The Threshold

The ranking pages give thresholds, but loose ones. Kong says to add a gateway once you have “more than 2-3 servers”, plus compliance needs, team isolation, or a move to production, and it closes with “Don’t wait for chaos.” API7 is more careful: direct connections “can be sufficient for local development or a small trusted setup,” and a gateway on a single-user workflow “may create complexity without improving security.”

Server count is the wrong axis. I’d rather count humans and revocations. Here’s my threshold. It’s opinion, but it comes from four months of running agents nobody watches.

You probably don’t need an MCP gateway yet if…

• One person (or one small trusted team) owns every agent and every credential.
• Your agents mostly run fixed jobs with known endpoints, where REST or a couple of local MCP servers do the work.
• Each agent runs in its own container with only the keys it needs. That’s the cheapest form of authorization there is.
• Nobody outside your team has to trust your logs.

You need one when any of these is true:

1. Several humans share the same MCP servers, and you need to know which person’s agent did what.
2. You need to revoke one agent without redeploying it. With per-container env vars, revoking means rotating a key, and every container that shares that key breaks.
3. You need tool-level permissions on a shared server: read yes, write no, refunds never.
4. A compliance regime wants a central record of tool calls (SOC 2, HIPAA, SOX, GDPR access logs). Self-reported agent logs won’t pass.
5. You can’t answer “which MCP servers are configured where?” in under a minute. That’s my astrology server. One stale entry is a cleanup chore. Fifty, spread across a team, is an incident waiting to happen.

By my own test I pass the first four and fail the fifth. The honest fix for my fleet isn’t a gateway yet. It’s a nightly check that lists every configured MCP server across every container and flags any that won’t connect. That’s a short script, not a platform. If a second person ever runs agents against shared servers, the answer flips.

For the bigger-company version of this decision, with owners, registers and staged gates, see my piece on what kills enterprise AI agent pilots. A gateway is often the first piece of governance that a pilot is missing.

Your MCP Gateway Options and What Each Costs You

If you’ve hit the threshold, the options split cleanly. Everything below was checked on vendor pages and GitHub on October 22, 2026. Prices change, so re-check before you buy.

Open source (you run it)

• Docker MCP Gateway, MIT license, about 1.6k GitHub stars. Runs each MCP server in its own isolated container with restricted privileges, network and resources, injects credentials, and logs and traces calls. If you use Docker Desktop with MCP Toolkit, it already runs in the background. The best fit for a small team that already lives in Docker. One catch: the version bundled with Docker’s AI Governance features is invite-only through sales.
• Microsoft mcp-gateway, MIT, about 890 stars. A reverse proxy plus control plane built for Kubernetes, with bearer-token and RBAC auth and an Entra ID path for Azure. Great if you already run Kubernetes. Too heavy if you don’t.
• IBM ContextForge, Apache 2.0, about 4.7k stars. A registry and proxy that federates MCP servers, A2A agents and plain REST/gRPC APIs behind one front door. The strongest on the discovery job.
• agentgateway, Apache 2.0, about 5.4k stars. A proxy built on MCP and A2A that covers agent-to-LLM, agent-to-tool and agent-to-agent traffic in one place. Worth a look if you want one proxy for both your AI gateway and your MCP gateway.

The license is free. The cost is your time: deploying it, patching it, wiring it to identity, and being on call when it’s the thing that’s down. A gateway sits in the path of every tool call, so when it fails, every agent fails at once.

Managed (you rent it)

• Kong Konnect: the Plus tier starts at $25/month plus usage and covers LLM, MCP and A2A traffic. It includes 1 million AI gateway requests a month, then $200/month for each additional million, capped at 10 million on Plus. A 30-day free trial, no card required.
• TrueFoundry: a Developer tier at $0 for up to 3 users, with 10K requests and tool calls per user per month and 7-day log retention. Pro is $25 per user per month with 20K requests per user, and overage is $20 per additional 100K.
• Also in the managed and enterprise lane: Traefik, Zuplo, Operant (security-first), and Microsoft Foundry’s AI-gateway governance for MCP tools (in preview). Most don’t publish prices.

A quick sanity check before you buy: a scheduled agent fleet makes far fewer tool calls than you’d guess. This brand runs about a dozen scheduled jobs a day. Request quotas are rarely the constraint for a small team. Seats and log retention are. Seven days of logs is not an audit trail.

If you’re trying to decide whether your setup needs a gateway, or just a tighter container and credential layout, that’s exactly the kind of thing I map out in a build strategy session. Usually the answer is “fix the credentials first.”

MCP Gateway FAQ

What is an MCP gateway?

A proxy between AI agents and MCP servers that centralizes authentication, tool-level permissions, routing, audit logging and a registry of approved servers. Agents connect to the gateway instead of to each server.

What’s the difference between an MCP server and an MCP gateway?

An MCP server exposes tools from one system, like GitHub or a database. An MCP gateway sits in front of many servers and controls who can reach which tool. You can have servers without a gateway. A gateway with no servers behind it does nothing.

Do we need an MCP gateway?

Not if one person or a small trusted team owns every agent and credential, and agents run in isolated containers with scoped keys. You need one when several humans share servers, when you must revoke one agent without breaking others, when you need tool-level rules on shared servers, or when an auditor needs a central record.

Is an MCP gateway the same as an API gateway?

No. They overlap on auth, rate limits and logging, but an API gateway doesn’t understand MCP tool calls, so it can’t enforce per-tool rules. Some API gateways (Kong, Traefik) add MCP support as an extension.

Does an MCP gateway stop prompt injection?

It limits the damage by restricting which tools an agent can reach and requiring approval for risky ones. It can’t judge whether a tool’s output is malicious, so you still need careful tool design and human approval on high-impact actions. My Claude Code security guide covers the agent side.

Does the 2026-07-28 MCP spec change anything?

Yes. It made MCP stateless and removed protocol sessions, so gateways don’t need sticky routing for current clients. It also requires Mcp-Method and Mcp-Name headers, so policies can match on headers. Older clients still need a separate legacy path.

Final Thoughts: Earn Your MCP Gateway

An MCP gateway is a good tool solving a real problem: many people, many agents and many servers, with nobody able to see who touched what. If that’s you, pick the open-source option that fits the stack you already run, or rent one and spend your time elsewhere.

If that’s not you yet, do the cheap version of each job first:

• Auth and authorization: one container per agent or brand, holding only the keys that agent needs.
• Audit: a dated log per run, ending in one result line that something checks every night.
• Discovery: a nightly inventory of every MCP server you’ve configured, and whether it connects. This is the one my fleet is missing.

Then watch for the moment the cheap version stops being enough. It isn’t a server count. It’s the first time you need to revoke one agent and can’t do it without breaking three others. That’s the day you buy the gateway. For how the rest of my unattended setup holds together, read what actually runs my 10-brand business and the nine practices I learned from four months of unattended runs.