What an MCP gateway does, and when your MCP servers need one

An MCP gateway is a proxy that sits between your agents and the MCP servers they call. It keeps one register of approved servers and resolves the caller's identity on every request. It checks each tool call against policy and holds the upstream credentials, so the agent never does. It also meters calls and spend, and writes one audit line per call. Bigcircle builds the register, the credential vault, the check before the call and the record outside the agent on the systems we ship, and a gateway holds them once more than one agent or team depends on them.

Key facts

Definition

An MCP gateway is one front door between agents and MCP servers that owns the controls every server shares: the server register, the caller's identity, the per-call policy, the upstream credentials, the limits and the audit line.

How Bigcircle does it

1. On Solarpunk, Bigcircle injects each credential from an encrypted vault at execution time, and the agent acts only through tools someone registered.
2. On Skionis, Bigcircle gives the agent no general shell, and an engineer approves an architecture diagram before a change applies to the AWS account.
3. Bigcircle keeps the record's own permission check and the confirmation of an irreversible action in the system of record, outside the gateway.

Comparison

An API gateway decides on a path and a method, while an MCP gateway decides on a tool, its arguments and the caller, and pins tool descriptions the model reads as instructions.

Key number

In two stolen-key cases Wiz traced to an October 2026 vendor breach, one key carried about 800,000 calls over 30 hours and the other about 1.7 million over 13 hours.

Every MCP server you add repeats the same decisions. Who is calling, which tools may that caller use, which credential does the call carry, and where does the record go? Made separately in each server, those answers drift apart, and before long nobody can say which agent may reach which system without reading every server's code.

We met the cost of point-to-point wiring on Solarpunk, a desktop agent we built that reaches more than 100 tools. Wiring each service straight to the model held until roughly 30 tools. Past that, the model picked plausible tools from the wrong system with no sign in its output. Point-to-point wiring had a second cost, because a vendor changes a response and the break shows up somewhere unrelated, days later.

A gateway centralizes those decisions, and it also concentrates the risk. Wiz counted at least nine AI developer platforms that disclosed incidents in October 2026, and in every public account of them the attackers hunted stored environment variables, above all those that grant AI access. A gateway that holds every upstream key is the prize in that kind of hunt, so ask where it keeps the keys before you ask how good its policy engine is.

This guide starts with what an MCP gateway is and how it differs from an API gateway. It then lists what one should do in production, when you need one, and how to choose between open-source and managed options. It ends with what stays out of the gateway and how we place these controls on the agents we build.

The OAuth detail for a single server is in MCP authorization, and this guide links there rather than repeat it. Read that guide first if you are building one server, and this one when you are about to run several.

What is an MCP gateway?

Treat an MCP gateway as a reverse proxy that understands MCP. Claude, ChatGPT, Copilot, Cursor and your own agents connect to one endpoint. The gateway knows which servers are registered and sends each tool call to the server that owns the tool. It attaches that server's credential on its own side and returns the result, so every request passes the same checks whichever client sent it.

The figure shows the request path. Blue marks the controls every server shares, which belong in the gateway, and orange marks the part that never moves into it.

Keep the gateway and the consolidation layer apart, because they solve different problems. A gateway passes each server's tools through one door. The consolidation server in how to design MCP tools rewrites them into fewer tools shaped around the questions people ask. It also decides which source answers which question.

Run the gateway in front of every server, and put a consolidation server behind it wherever several sources answer the same question. A gateway that re-exports every vendor tool under one name brings back the long list that broke tool choice on Solarpunk. Filter the list per caller, or put search in front of it, before the combined list passes about 30 tools.

A gateway is also not your identity provider and not the record's own permission check. It asks your identity provider who the caller is, and the question of whether this person may change this record stays with the system that owns the record. The section on what stays out of the gateway covers that line.

MCP gateway vs API gateway: what carries over?

Keep your API gateway, and do not treat it as an MCP gateway because it can proxy the endpoint. TLS, authentication at the edge, rate limits by caller and request logs all carry over, along with the habits of a team that already runs one.

The unit of policy does not carry over. An API gateway decides on a path and a method. An MCP gateway has to decide on a tool, its arguments and the person asking, for a request whose path never changes.

The table lists the differences that change what you build, all under the 2026-07-28 MCP specification.

Read the last row first if you are evaluating a gateway written before July 2026. MetaMCP, an open-source gateway, keyed its session store only on the client-supplied mcp-session-id header through version 2.4.22. A caller holding another tenant's id could list and run that tenant's tools, and MCP server testing has the CVE detail and the test that catches it.

Ask any gateway how it binds state now that the header is gone, because a gateway that still keys anything on a connection is carrying the same design forward.

Pin tool definitions at registration for the same reason the change row exists. Store a hash of each tool's name, description and schema when the server is approved, and treat a changed hash as a new registration that goes back through review. A server you approved last month can tell the model something new today without changing its version. A proxy that forwards whatever the server lists has approved that change on your behalf.

What should an MCP gateway do in production?

Give the gateway eight jobs, and name an owner for each before the first server is registered. The table maps each job to a dated example from a product or a system we built. The product rows are each company's own account of what it offers on that date, so they show the control exists in the market and are not a test of it.

Resolve the identity on every request, and never let the gateway connect once as the person who installed it. A gateway that reuses the installer's token for everyone still passes each server's audience check, the test that a token was issued for that server, because the token really was, and every user then reads the installer's data. Multi-user agent memory and credential isolation covers that failure, and AI agent permissions covers what each identity should be allowed to do.

Store the upstream credentials as if the gateway is the first thing an attacker will look for, because it is. Wiz's 30 October write-up on the October incidents traced two stolen enterprise keys to one vendor breach. One key carried about 800,000 calls over 30 hours and the other about 1.7 million over 13 hours, together likely over $100k at list price. The first unauthorized call came within 30 minutes of the credential access.

Keep the keys in a vault, not in the gateway's environment variables, and mint short-lived tokens where the upstream system allows it. Northflank's instruction to its customers on 30 October was to assume every environment variable had been decrypted and rotate every secret. A gateway gives you one place to do that rotation, which is the upside of the concentration.

Set the per-caller limit and the spend ceiling so a stolen credential trips them in the first hour, not at the end of the month. The specification still requires each server to rate-limit tool calls, so keep that limit as well, because the gateway's limit is a second line and not a replacement. Return a typed refusal when a limit trips, so the agent waits rather than switching to a worse source to get its answer.

Write the policy in the gateway's code, because a prompt rule is not a guardrail you can count on. Write the audit line from the gateway, not through a tool in the agent's catalogue, and keep the token out of it. The fields for an allow and a refusal are in MCP authorization, and the gateway should write the same line for every server behind it.

Ship that line into the same observability stack as the agent's trace, keyed by the trace id the request carried. AI agent monitoring depends on that join, because a refusal in the gateway log and an empty answer in the agent trace are the same event seen by two owners.

Use the suspend switch as an operational control and test it like one. The 2026-07-28 revision removed sessions, so every request carries its own token and there is no session to drain. A suspension written at the gateway applies to the next request, and a quarterly drill should prove that it does.

Do you need an MCP gateway?

Skip the gateway while one team runs one or two servers for one client. Put the check before the call and the audit line inside the server, and pin its contract in CI. At that size a gateway is one more service on the request path, with an owner, an on-call rota and its own failure modes. It buys you a register with two entries in it.

Add one when any of these becomes true. A second team wants its own server, or a second client such as Copilot joins Claude. A server holds a credential to a system with customer data, or you want to run a server you did not write. Regulated data sits behind any server, or the tools across your servers pass about 30.

Each of those turns a decision made once per server into one you will otherwise make differently in each server. Count the triggers you already meet, and plan the gateway before the next server ships rather than after the third.

The second team is the trigger we would watch most closely. In Sierra's July 2026 account of its company-wide gateway, the payoff was that permissioning, auditing and legal review happened once rather than once per team. Without a gateway, the second team builds a second permission model and a second audit format, and the third team has to pick one.

Run the gateway as production infrastructure from the first day it carries traffic. Every agent call depends on it, so it needs the same deployment, monitoring and failover as your API gateway. Alert on its refusal rate and its error rate separately, because a broken gateway that refuses everything looks like every agent refusing at once.

How do you choose an MCP gateway?

Pick the gateway that fits your identity provider, your hosting and the servers you run, because there is no best MCP gateway in general. Ask every candidate the same questions, open-source and managed alike, and stop on the first one it cannot answer.

1. Does it resolve the caller from your identity provider on every request, or connect once as the installer?
2. Where does it store upstream credentials, and can you rotate all of them in one step?
3. Can a policy read the tool's arguments, or only the tool's name?
4. Does it filter tools/list per caller and mark that list private?
5. Does it pin tool definitions and flag a change before the model sees it?
6. Does it write a line for every refusal as well as every allow, in a format your stack can read?
7. Can you suspend one agent or one server without a deploy?
8. Which MCP revision does it implement, and how does it bind state without sessions?

Docker's MCP Gateway is the open-source gateway behind Docker Desktop's MCP Toolkit, which runs it in the background once the toolkit is on. It is MIT-licensed, and Docker's documentation positions it as a central proxy between clients and servers that manages configuration, credentials and access control. It runs each server in an isolated container with restricted privileges, network access and resources, injects the credential when it forwards a call, and keeps logs and call traces.

Profiles decide which servers a client sees, and the binary also runs on Docker Engine without Desktop. The version inside Docker AI Governance was invite-only as of 2 November 2026. Start with it when you want third-party servers contained and configured in one place, and ask it question 1 as you would ask any gateway.

Choose an open-source gateway when it has to run inside your own network and you have a team to patch it. Read the release history before the feature list. MetaMCP's latest release on 2 November 2026 was still 2.4.22, from 19 December 2025. That is the version the two CVEs from September 2026 cover, so a team running it had nothing to upgrade to.

Choose a managed gateway when the governance team needs the controls in the table soon and you accept the vendor's hosting. OmniTrust launched Halo, with an MCP gateway, on 30 October 2026. Salesforce added a kill switch and spend limits to its Agent Fabric control plane on 27 October. Check each against the eight questions, and against which of your clients it supports today.

Build your own when the policy depends on business data no product can read. Sierra built its own, and its team added a REST extension mechanism to replace server tools that did not fit how people worked, and to remove the ones it judged unsafe. A built gateway is the most work to own, so choose it only when the policy you need reads records that no product on the market can reach.

What stays out of the gateway?

Keep the record's own authorization in the system of record. The gateway sees a tool name, its arguments and a caller, and it does not see the workflow state behind them. On Beeline's own account, its early-access MCP lets a person approve a step only when the step is waiting on that person. The check runs inside the application, next to the state. A gateway rule that tried to copy it would be a second, staler version of the same check.

The token detail stays with each server too. A protected MCP server checks that the token was issued for it and must not pass the caller's token through to the service behind it. Put that check in the server even when a gateway sits in front, so a request that bypasses the gateway is still refused. MCP authorization covers the per-run token, the refusal shape and the record of each outcome.

Keep confirmation of an irreversible action in the system that owns the record. On its own account, Board's preview keeps approving, locking and committing a plan on Board's own screens. Beeline asks for confirmation before an action that cannot be undone, such as rejecting a candidate. A gateway prompt shows a person a tool call, and a person deciding on a refund or a rejection needs to see the record. Human in the loop for AI agents covers what that approver should see and how the system enforces the decision.

Test a server before it is registered, not after. Register a server only when its contract tests pass, using the CI contract in MCP server testing. Send a changed tool definition back through the same tests. The gateway then serves only tool lists someone has already checked.

Leave skills and other host-side code out of the gateway's model of the world. A skill folder loads into the host and runs with the host's privileges, so no MCP gateway sees it until it calls a tool. Skills vs MCP covers that split, and the rule that a skill names the tool and stops.

How Bigcircle puts the controls outside the agent

Three agents we built already do a gateway's jobs inside their own runtime: the register, the credential, the check before the call and the record. The design below moves in front of the servers without changing.

On Solarpunk we built one uniform tool layer, where every tool is a typed contract with declared inputs, outputs and side effects. The agent can act only through systems someone registered. We stopped giving the model the registry, and each step queries it for the few contracts it needs. Credentials sit in an encrypted vault on the user's machine and are injected into the tool adapter at execution time, so the model is called as a reasoning service and never holds the keys.

Solarpunk also keeps a trace per run, from the goal and the tools discovered through each call to the final state of the application. Comparing the agent's claimed completion with that state catches work that never finished, which is the check a gateway's audit line cannot make by itself.

On Skionis, a DevOps agent we built for a live AWS account, we treat the agent as untrusted. It acts only through purpose-built tools that wrap the provider's APIs. There is no general shell and no path from a plan step to an arbitrary API call.

A validation loop checks each template against the account before an engineer sees it, and we measured template errors before deploy falling from around 10% to 4% across its introduction. An engineer approves an architecture diagram before the change applies, and one record links the request to every resulting resource.

On an insurance voice agent we built, the policy, claim, payment and endorsement tools carry permission checks and required disclosures in the tool contract. A request that fails escalates to a person and does not degrade into something close. On a current engagement for a telecom marketing platform, we scope each agent to the entitlements of the person it acts for. Prompts stay a user-experience layer that no policy check depends on, and deploying a campaign sits behind an approval gate.

Across more than one agent, move those controls out of each runtime into one gateway in front of the servers. The registry, the vault, the per-call check and the record then serve every agent and every client the same way. Building that tool layer is our MCP server development work, and the per-call policy and approval checkpoints are our AI guardrails work.

Common questions

What is an MCP gateway?#

An MCP gateway is a proxy between AI agents and the MCP servers they call. Every client connects to one endpoint. The gateway serves only registered servers, resolves the caller on each request and checks each tool call against policy. It attaches the upstream credential on its own side, limits calls and spend, and writes an audit line for every allow and refusal.

Is an MCP gateway the same as an API gateway?#

No. Both handle authentication at the edge, rate limits and routing, but an API gateway decides on a path and a method. An MCP gateway has to decide on a tool, its arguments and the caller, and filter the tool list per caller. It also resolves tool names that clash across servers and notices when a tool description changes, because the model reads that description as an instruction.

Is there an open-source MCP gateway?#

Yes. Docker's MCP Gateway is open source under the MIT license. It runs each MCP server in an isolated container with restricted privileges and injects credentials when it forwards a call. MetaMCP is another open-source gateway. Check the release history of any open-source gateway before you adopt it, and confirm how it binds state now that the 2026-07-28 specification removed sessions.

What is the Docker MCP Gateway?#

The Docker MCP Gateway is Docker's open-source proxy between MCP clients and MCP servers. It starts each server in a container when a tool is needed and restricts its privileges, network access and resources. It injects the credential the server needs, and logs and traces calls. Profiles decide which servers a client can see, and Docker Desktop's MCP Toolkit runs it in the background.

Does an MCP gateway handle OAuth for MCP servers?#

It can hold the upstream credentials and attach them on its own side, so the agent never carries them. It should not pass the caller's token through to a server, which the MCP specification forbids. Each protected server should still check that a token was issued for it, so a request that bypasses the gateway is refused.

Where should credentials live when agents call MCP servers?#

In a vault the gateway or the server reads at the moment of the call, and never in the prompt, the agent's environment or the gateway's environment variables. Mint short-lived tokens where the upstream system allows it, and make rotating every upstream key one step, because a gateway that holds every key is the first place an attacker looks.

What is the best MCP gateway?#

The one that fits your identity provider, your hosting and your servers, so ask each candidate whether it resolves the caller on every request and where it stores credentials. Ask whether policy can read tool arguments, whether it filters and pins the tool list, and whether it logs refusals. Then ask whether you can suspend one agent without a deploy, and which MCP revision it implements.

Further reading

• Model Context Protocol, Key changes in 2026-07-28. Protocol sessions and the Mcp-Session-Id header removed, lists that no longer vary per connection, required Mcp-Method and Mcp-Name headers, and trace context in _meta.
• Model Context Protocol, Streamable HTTP transport, revision 2026-07-28. Headers mirrored for gateways, and the rule that an intermediary enforcing policy on them rejects older versions.
• Model Context Protocol, Tools and Caching, revision 2026-07-28. Tool lists that vary by authorization, name prefixes for aggregating proxies, untrusted annotations, the server's duty to rate-limit, and public versus private cache scope.
• Docker, MCP Gateway documentation and the docker/mcp-gateway repository, MIT license, checked 2 November 2026.
• Board, Meet Board MCP: Governed Planning for Your AI Ecosystem, 30 October 2026. Preview: nothing exposed by default, every call audited and rate-limited, the caller's identity resolved on every request.
• Beeline, Beeline MCP: Connecting AI assistants and agents to workforce programs, early access from 31 October 2026. Signed-in user identity, workflow state enforced in the application, confirmation before irreversible actions.
• OmniTrust, OmniTrust Launches Halo, a Unified AI Governance Platform, press release via PRNewswire, 30 October 2026. Model and MCP gateways, credentials kept out of agents, suspending agents, budgets.
• Salesforce, Salesforce Expands Agent Fabric to Automatically Stop Runaway Costs and AI Agent Failures, 27 October 2026. Agent Kill Switch and Model Wallet generally available that day; Agent Evals in beta from November 2026.
• Wiz, "Black October" for AI Developer Platforms, 30 October 2026. Nine platform incidents, stored environment variables targeted, and the two stolen-key cases.
• Northflank, Security incident status page, 30 and 31 October 2026. Rotate every secret, and audit logs turned on for all customers.
• Sierra, Building Sierra's MCP Gateway: An engineering iceberg, 22 July 2026. One gateway for the company, the REST extension mechanism, and user versus service-account identity.
• MCP authorization, how to design MCP tools, MCP server testing, Skills vs MCP, AI agent permissions, human in the loop for AI agents, AI agent monitoring and multi-user agent memory and credential isolation.
• The Solarpunk build, the Skionis build and the insurance voice agent build.
• MCP, tool calling, prompt injection, observability and guardrails.