Guides
What is an MCP gateway, and does your company need one?
Harriet Team · · 5 min read
An MCP gateway is one controlled point between your AI assistants and the MCP servers they call. As of November 9, 2026, the Model Context Protocol is the standard way to connect Claude, ChatGPT and other assistants to business systems, and a gateway is how a company decides which of those connections are allowed, who can use them, and what gets logged.
What is MCP, in plain terms?
The Model Context Protocol is, in the words of its own documentation, “an open-source standard for connecting AI applications to external systems.” Anthropic open-sourced it on November 25, 2024. An MCP server is a small program that hands an assistant tools, like “search the CRM” or “draft an email in Outlook”, and it can run on someone’s laptop or on a remote host.
That is why MCP spread so fast. One person can connect an assistant to almost anything in an afternoon. It is also why IT teams get nervous, because every one of those servers is code that can reach company data.
What does an MCP gateway do?
A gateway sits in front of the MCP servers and does four jobs.
- Decides access. Which teams can use which connectors, often driven by your directory groups.
- Checks the connector. Looks at a server before it runs and blocks the risky ones.
- Holds the credentials. Keeps tokens out of people’s config files and scopes them to what the tool needs.
- Records the calls. Logs who ran which tool, with what input, and what came back.
What we see with mid-size companies is that the hard part is rarely getting access to an AI assistant. It is letting teams connect it to the systems they work in without IT becoming the bottleneck for every connector. A gateway is how you say yes once and keep saying yes safely. In Harriet that approval happens once, centrally, and the connector then reaches every team it was approved for. Our post on how to find shadow AI covers what happens when there is no approved route.
What risks does an MCP gateway cover?
The risks are documented in the protocol’s own specification, not guessed at.
- Untrusted tool descriptions. The spec says tool annotations “should be considered untrusted, unless obtained from a trusted server.”
- Tool poisoning. Invariant Labs showed in April 2025 that instructions can be hidden in a tool’s description, where the model reads them and the user does not.
- Token passthrough and over-broad scopes. The MCP security best practices page forbids passing tokens straight through, and warns that a token with wide scopes lets an attacker move across systems.
- Local server compromise. A server running on a laptop runs with that person’s permissions.
A gateway does not make these go away. It gives you one place to check servers, scope tokens and see what happened. Harriet’s scan flags the same signals, such as a hardcoded token or calls routed through an outside service.
What are the main MCP gateway options in 2026?
Most options come from API gateway and cloud vendors, and are built for engineering teams routing their own traffic.
| Option | How it describes itself | Open source |
|---|---|---|
| Docker MCP Gateway | ”open source solution for orchestrating” MCP servers | Yes |
| IBM ContextForge | An AI gateway, registry and proxy in front of MCP servers | Yes, Apache 2.0 |
| Kong Enterprise MCP Gateway | ”a single, secure entry point for AI clients” | No, part of Kong AI Gateway |
| Portkey MCP | ”A unified layer to access and govern MCP tools” | Partly, with managed and self-hosted options |
| Azure API Management | Exposes and governs MCP servers, tools only | No, paid Azure tiers |
| Cloudflare MCP server portals | Puts several MCP servers behind one endpoint | Not stated |
Each description is taken from the vendor’s own page. If you have a platform team that already runs Kong or Azure API Management, extending what you have is usually the shortest path.
What if you are not an engineering company?
Then the question is less about routing traffic and more about who approves a connector and who can use it. For a company where most AI users are in finance, operations or sales, the gateway needs to come with the connectors already hosted.
That is how we built it in Harriet. We host the MCP servers and connectors, and every skill and connector is scanned and threat-scored before a team can use it. Risky ones are held until a person approves them. The tool safety page shows what gets checked.
Access follows your directory groups, so a connector approved for finance is available to finance and nobody else. Every prompt, connector and tool call is logged and exportable, which is what a security review asks for. Harriet Desktop, Claude Desktop and cloud workspaces all reach their tools through the same AI gateway.
Where there is no ready-made connector, for example a custom connector to send email from an Outlook outbox, our engineers build one as part of the deployment.
Harriet brings together a unified AI platform, a deployment team and a strategy so that your company becomes AI-native. Book a call and bring the connector you would hesitate to approve.
