Category guide

What is an MCP gateway?

An MCP gateway is a single endpoint that sits between AI agents and the Model Context Protocol servers they call. Agents connect to the gateway; the gateway connects onward, applying access control, injecting credentials, and recording every call.

Read the field guide See Dome’s MCP gateway

Why Dome

Why use Dome for an MCP gateway?

If one team needs governed access to a handful of MCP servers, a gateway is the right size of answer. Dome is for the enterprise AI platform team that has to say yes to everyone, and still be able to show what happened.

Which means the tool is not the only thing under governance. The agent is a registered identity. The person it acts for is part of the authorization decision. Model calls run under the same rules and land in the same audit trail. One object model, one rule language, one record. How that works.

The problem

Direct connections do not scale

One developer with one MCP server does not need a gateway. An enterprise with an estate of agents does, and for reasons that show up in a specific order.

First it is credentials. Every agent holding its own token for every server means rotation is a project and revocation is a guess. Then it is access: permissions granted per agent, in per agent places, with no way to answer which agents can reach a given system.

Then it is evidence. When someone asks what an agent did last Tuesday, the answer lives in whichever logs each server happened to keep. A gateway exists to make those three problems one problem, solved in one place.

Capabilities

What an MCP gateway does

One endpoint

Agents connect to the gateway rather than to each MCP server. Adding or replacing a server is a configuration change, not a redeploy of every agent that uses it.

Access control

Which agent may see which tools, and call which of them. Server-level control is common; tool-level and argument-level control is not.

Credential isolation

The upstream credential lives at the gateway and is injected at egress, so the agent never holds it. This is the difference between rotating one secret and rotating every agent.

Transport bridging

Local stdio MCP servers, remote streamable HTTP servers, and REST APIs described by OpenAPI, presented to the agent as one uniform surface.

Response handling

Inspecting and filtering what comes back, so a permitted call cannot return data the caller should not see. Governing outputs, not just inputs.

Audit

A record of every call: which agent, which tool, which arguments, allowed or denied, and under which rule. Useful only if it attributes the call to an identity.

Choosing

Where MCP gateways differ

Most of them list the same capabilities. The differences that matter are underneath the list.

Server-level or tool-level control

Granting an agent access to a whole MCP server is the easy version. Most servers expose many tools with very different blast radius, so the useful question is whether policy can name an individual tool, and the arguments it is called with.

Whose identity reaches the decision

An agent almost always acts on behalf of a person. Passing that person's token through to the backend solves the credential problem. It does not mean the gateway's own authorization decision considered who they were, which is what stops the agent becoming a privilege-escalation path.

Whether model traffic is governed too

Tool calls are half of what an agent does. The other half is model calls, which carry the spend and most of the data leaving your estate. A gateway that governs only MCP leaves that to a second system with its own rules and its own logs.

Deterministic policy or configuration

Rules that live in a policy language can be reviewed, versioned, tested against real traffic, and rolled back. Rules that live in a settings screen usually cannot.

Attributed audit

Logs record that something happened. An audit trail records who did it, under which rule, and what the outcome was. Compliance work needs the second one.

Hosted or self-managed

Where the gateway runs decides what data crosses your boundary and which team operates it. Both models are legitimate; the constraint usually comes from somewhere other than engineering.

The landscape

Who builds MCP gateways

A short, honest map of the category. Products are described by shape rather than by feature list, because shape is what stays true.

Product	What it is	Best suited to
MintMCP	Managed hosting for MCP servers with team access control and tool-call monitoring.	Giving a team's coding assistants governed access to a sprawl of MCP servers, without running anything yourself.
Docker MCP Gateway	A container-native runtime primitive. Governs by isolation, signed images and interceptors.	Developers and single-tenant setups already standardized on containers.
Kong AI Gateway	API-management lineage extended to MCP, using the same routes, consumers and plugin chain.	Organizations already running Kong who want MCP on that fabric.
Dome	An agent operations platform. The MCP gateway is one control point of three, alongside model traffic and agent identity.	Enterprise platform teams running agent services for the whole business: many agents, many teams, tools and models both in scope, one audit trail.

Last updated 11 August 2026, based on publicly available information about these products. Spot something out of date? Tell us and we will correct it.

Evaluating

Questions worth asking

01Can policy name an individual tool, or only the server it came from?
02Does the authorization decision see the user the agent is acting for?
03Where do model calls go, and who governs them?
04Can you test a policy change against real traffic before shipping it?
05Does the audit record attribute the call to an agent identity?
06Who holds the upstream credential, the gateway or the agent?

How Dome approaches it

Routing in service of governance

Most products in this category began as routing and added governance afterward. Dome began at the other end, and it changes what the gateway is for.

A gateway that exists to route treats policy as a filter on traffic. A gateway that exists to govern treats the tool as one object among several that the same rules have to reach. That is the difference between knowing a call happened and being able to say who made it, on whose behalf, under which rule, and what came back.

So Dome’s MCP gateway, the Tool Gateway, is one control point of three. The agent is a registered identity with a lifecycle. The person it acts for is part of the authorization decision rather than a token passed downstream. Model calls are governed by the same rules and land in the same audit trail. One object model, one rule language, one record.

The tool is an object, not a route

Rules name individual tools and the arguments they are called with, at scopes from the organization down to a single agent. Simulated against replayed traffic before rollout, versioned through CI/CD.

The caller is in the decision

Authorization is acts-as: evaluated over the agent identity and the person it acts for, together, with their live directory claims. Offboard someone and every agent acting for them stops.

It composes, it does not replace

Dome runs alongside the IdP, secrets store, SIEM and CI/CD you already operate. Several products above are complementary rather than alternatives, and are treated that way.

Read the field guide Explore the Tool Gateway Get started

Agents Need to Talk to Your Systems is a 22-minute field guide to the Tool Gateway: connecting a system, composing a catalog, shaping reach, and governing what comes back. No form, no gate.

FAQ

Common questions

What is an MCP gateway?

An MCP gateway is a single endpoint that sits between AI agents and the Model Context Protocol servers they call. Rather than each agent connecting directly to each MCP server with its own credentials, agents connect to the gateway, and the gateway connects onward: applying access control, injecting credentials at egress, filtering responses, and recording every call.

Why not let agents call MCP servers directly?

Direct connections mean every agent holds its own credentials, access is granted per agent rather than centrally, and nobody has a complete record of which agent called what. It works for one developer and one server. It does not survive an estate of agents across several teams.

How is an MCP gateway different from an API gateway?

An API gateway routes requests between known services on fixed paths. An MCP gateway sits in front of a reasoning system that decides at runtime which tool to call and with which arguments, so the decision has to be made per call, in context, rather than configured per route in advance.

Does an MCP gateway govern model calls as well?

Usually not. MCP governs the tool channel. Model calls typically go straight from the agent to the provider, outside the gateway's control path. Governing both under one policy language and one audit trail requires a platform that treats the model as a first-class object, not only the tool.

Is Dome an MCP gateway?

Dome's Tool Gateway is an MCP gateway, and is part of the overall Dome platform. It governs tools, models, agent identity and the caller an agent acts for, under one rule language with a single audit vocabulary across all of them.

Which MCP gateway should I choose?

MCP Gateways tend to have a similar featureset, but often only focus on control of tools. Dome is for enterprise AI platform teams building agent services for the rest of the business: dozens of agents across many teams, tool calls and model calls both in scope, agents your customers drive as well as agents you build, and a security function that expects one answer to who did what, on whose behalf, and under which rule.