Open Source MCP Gateway: Projects to Know and What to Check

Open source MCP gateways exist, but they differ widely in scope. Docker’s is a local proxy that runs servers as containers, Microsoft’s is a Kubernetes reverse proxy with a control plane, and BusinessMCP’s repository is a set of hardening utilities rather than a gateway. Before adopting any, read the README for limits, then audit it against your own requirements.

What “open source gateway” can mean

The label hides three very different artefacts:

• A runnable gateway. You deploy it and point clients at it.
• A framework or library. You build a gateway from parts.
• Utilities for gateway authors. Security helpers you embed in your own code.

Mixing these up wastes weeks. A team that wants a drop-in gateway and installs a utilities library will find nothing to run.

Projects described by their own documentation

Project	Category	Licence and status as stated	Distinguishing facts
Docker MCP Gateway	Runnable local proxy	Described as open source; the documentation also says it is part of Docker AI Governance and invite-only	Starts servers on demand in isolated containers, injects credentials, logging and call tracing, profiles
Microsoft mcp-gateway	Runnable Kubernetes gateway	MIT	Stateless request routing, REST control plane for servers and tools, Entra ID auth, /portal/ management UI, Redis or Cosmos DB for metadata
BusinessMCP mcp-gateway	Utilities for gateway authors	MIT, with no gateway included	SSRF guard, upstream error classification, tool namespacing, transport fallback

All details come from each project’s own pages as read on 2026-10-14. Verify before relying on them; releases move quickly.

Reading the Docker documentation carefully (see also our full Docker MCP Gateway explainer)

Docker describes its gateway as a proxy between AI clients and MCP servers that centralises configuration, credentials and access control. It launches the server a tool belongs to if it is not already running, applies security restrictions, then returns the result through the gateway. Logging and call tracing are built in. It works automatically with Docker Desktop’s MCP Toolkit, or can be installed manually for Docker Engine by placing the docker-mcp binary in the CLI plugins directory.

The line to notice is availability. The same page says it is part of Docker AI Governance and is invite-only. “Open source” and “freely available to everyone today” are not the same claim, so read the current page and, if you need it, ask.

Reading the Microsoft repository carefully

The Microsoft project is a reverse proxy and management layer targeting Kubernetes. Its README describes a data plane that routes requests to adapter endpoints and a tool gateway router, and a control plane that manages adapters and tools through REST APIs. Authentication uses Entra ID bearer tokens with application roles that separate read and write access. Local deployment goes via Docker Desktop and cloud deployment via AKS with Bicep templates.

Two cautions from the README itself: this version requires clients speaking the 2026-07-28 MCP revision and does not support legacy initialisation or transport sessions, and an agents and sessions subsystem is described as preview and meant for single-pod deployments. If you have older clients, check compatibility first.

The utilities route

The BusinessMCP repository is the odd one out, and its README is candid about it: it contains hardening utilities extracted from the vendor’s production gateway, not the gateway. Its pieces are useful if you are writing your own:

• an SSRF guard that checks whether a URL or IP is public and fails closed on input it cannot parse;
• an upstream error classifier that sorts failures into reasons such as authentication required, timeout or blocked host;
• tool namespacing that prefixes tool names with the server name and adds a hash when truncation is needed;
• a transport helper that tries streamable HTTP and falls back to SSE.

It also lists its own limits: no external audit, and a DNS-rebinding time-of-check/time-of-use window left open. We cite that not to criticise it but because it is the right level of disclosure. You should expect every project to say what it does not do.

Key takeaway: an open source project earns trust by listing its own limits. If a README claims enterprise-grade security with no caveats, read the issues page next.

An audit checklist before adoption

1. Licence. Confirm permission for your use, and read any extra terms.
2. Activity. Look at recent commits, release cadence and how issues are answered.
3. Security policy. Is there a way to report vulnerabilities, and has anything been disclosed and fixed?
4. Dependencies. Count them and check how they are pinned.
5. Auth model. Which identity systems does it support, and are keys hashed at rest?
6. Credential handling. Where do upstream tokens live, and can they appear in logs?
7. Logging. What is recorded, and in what format can you export it?
8. Protocol version. Which MCP revisions are supported, and what breaks on older clients?
9. Operations. What do you need to run it: Kubernetes, a database, a cache?
10. Exit. Can you move your policies and logs elsewhere?

When open source is the wrong answer

If nobody on your team can operate the service, the licence is the least important fact. Self-hosting means patching, monitoring and being on call. For some teams a managed endpoint is the lower-risk choice, and self-hosted versus managed gateways walks through the trade-off. If your need is exposing business data to assistants, not running your own servers, see BusinessMCP’s hosted tool catalogue to judge what the managed route includes.

What open source does and does not give you

Three things come with an open project. You can read the code, so you can check how credentials are handled. You can fork it, so a vendor change in direction does not strand you. And you can run it where you like. Three things do not come with it. Nobody is contractually obliged to fix a bug on your timetable. Nobody has necessarily audited it. And nobody operates it for you.

Registration, namespacing and policy are where gateways differ most in practice, so read how each project handles them. We explain why in the article on MCP gateway registries: a gateway that cannot tell you what servers and tools it fronts, who owns them and when they changed will be hard to govern, however good its code looks. The same applies to protocol support. The Microsoft README’s note about requiring clients on a particular MCP revision is the sort of detail that decides whether a deployment works with the assistants your colleagues already use.

A practical pilot looks like this. Deploy the candidate in a test environment with two harmless servers. Create two keys with different policies. Confirm each key sees only what it should, call a hidden tool by name, break a server on purpose and read the error, then look for the whole sequence in the logs. A day of that tells you more than a week of reading feature lists. If you also want a hosted comparison point while you test, BusinessMCP’s explainer on what MCP hosting is describes the managed alternative and its stated limits, and its security guide is a useful reference list for the pilot whichever way you go.

Pairing a gateway with good practice

Whichever project you choose, the gateway is only one part of a safe setup. Pair it with a deny-by-default tool allowlist, per-caller keys and central logs, and follow the baseline in our security article. For a broader comparison across all routes, read the best MCP gateway guide.