Microsoft MCP Gateway: Four Surfaces in One Name

Short answer: There is no single Microsoft product called an MCP gateway. The name covers four surfaces: MCP servers exposed by Azure API Management, the AI Gateway tier of API Management, the AI-gateway governance Microsoft Foundry applies to agent tools, and the open-source microsoft/mcp-gateway proxy for Kubernetes. If your estate already runs API Management, that is the surface you meet first.

Key takeaways

• "Microsoft MCP gateway" names a category, not a SKU: two surfaces live in Azure API Management, one in Microsoft Foundry, and one is an open-source proxy you run yourself.
• API Management can expose a managed REST API as a remote MCP server or pass through an existing one; the result is an API resource of type MCP that inherits products, policies and role assignments.
• The AI Gateway tier adds a control plane built around models, MCP servers and tools, with policy cards instead of XML, but it is in public preview with a short region list.
• Foundry's AI-gateway governance routes new agent MCP tools through a connected API Management gateway; it does not retrofit existing tools, and it does not log tool traces.
• Decide the credential boundary first and the surface second: an API-shaped product learning a session-shaped protocol has limits, and several MCP capabilities are still unsupported.

---

microsoft mcp gateway: the four surfaces that share the name

The phrase is singular; the thing it names is not. Microsoft ships four MCP-related gateway surfaces, and which one you meet depends on where you already run. Three route MCP traffic through an Azure API Management instance, and the fourth is a different product with a similar name.

Surface	What it is	Where the endpoint lives	Status when this page was written
MCP servers in Azure API Management	A managed REST API, or an existing MCP server, exposed as a remote MCP server resource of type MCP	the API Management gateway host	supported in the tiers that support MCP servers
AI Gateway tier of API Management	A managed control plane organised around models, MCP servers and tools	a per-resource gateway host with tool-server paths	public preview
Foundry AI-gateway tool governance	Microsoft Foundry routing agent tool traffic through a connected API Management gateway	the Foundry tool configuration points at the gateway URL	preview
microsoft/mcp-gateway	An open-source reverse proxy and lifecycle manager for MCP servers on Kubernetes	a cluster ingress you operate	open source, self-hosted

The first surface is the one most Azure teams already hold a licence for. API Management supports remote MCP servers as a native resource type, so an MCP server is not a bolt-on: it is an API of type MCP, and it inherits the products, policies and role assignments the instance already uses for HTTP APIs. The second is the newer thing — a purpose-built tier whose control plane is structured around models, MCP servers and tools, and whose policies are configured as cards rather than XML. The third is not a gateway but a governance flow: Foundry can route the MCP tools an agent uses through an API Management gateway connected to the Foundry resource. The fourth is the outlier, an open-source reverse proxy for MCP servers in Kubernetes, and the one surface Microsoft does not operate for you.

What Azure API Management exposes today, and how an MCP server is modelled

The API Management support defines the vocabulary the rest of the stack uses, so it is worth reading first. The documentation describes remote MCP server mode and gives two built-in ways to expose one. The first is to take a REST API already managed in API Management and expose it as an MCP server, at which point the selected API operations become MCP tools. The second is to take an existing MCP-compatible server — the documentation names LangChain, LangServe, Azure Logic Apps and Azure Functions as examples — and expose it through API Management as a passthrough server. In both cases the result is an API Management API resource of type MCP, and the operations you expose become the tool surface a client sees.

Modelling an MCP server as an API resource means everything API Management already does with an API becomes available to it: policies attach the way they attach to a regular API, products bind so subscription-based access works unchanged, and the resource can be managed from code — the REST API, ARM templates, Bicep, the Azure CLI and Terraform — so it can be created in CI and reviewed rather than clicked together in a portal.

The capability boundaries are stated plainly, and they matter more than the marketing. For MCP servers exposed from managed REST APIs, API Management supports MCP server tools but not MCP resources or MCP prompts. For external MCP-compatible servers, tools and resources are supported but prompts are not. API Management does not support MCP server capabilities in workspaces. The tiers that support MCP servers are enumerated in the secure-access article, which lists Developer, Basic, Basic v2, Standard, Standard v2, Premium and Premium v2. If your plan depends on prompts or resources, that sentence is the one to read first — and the current documentation, not this page, is the authority.

The apigee ai gateway phrase, read on an Azure estate

"AI gateway" is a category word, and the same intent is searched under whichever vendor a team happens to know. This page does not review those other products; the cluster's vendor pages do that, and the definition of the object itself lives on the what is an MCP gateway page. What is useful here is narrower: when the search is for an AI gateway and the estate is Azure, which Microsoft surface answers it.

Two of the four surfaces above are AI-gateway products in the ordinary sense. The AI Gateway tier of API Management is the managed, model-and-tool-shaped control plane: applications call a gateway endpoint instead of each provider or tool backend directly, the gateway authenticates the runtime access key in the api-key header, evaluates the policies that apply to the target model or tool, routes the request using the configured backend credentials, and returns the response with OpenTelemetry logs and metrics attached. Foundry's AI-gateway governance is the narrower flow that puts an API Management gateway in front of the MCP tools an agent uses, so authentication, rate limits, IP restrictions and audit logging are enforced at one entry point without changing the MCP server or the agent code.

Read together, the Azure answer is that you already own the gateway and the work is deciding what to put behind it. The practical test is simple: if the gateway must front models, models plus tools, or MCP tools only, that choice alone narrows the Microsoft surface to one or two.

aws llm gateway, cross-cloud models, and what the Azure gateway still fronts

A recurring reason teams search for a gateway under another cloud's name is that their models are not all in one place. The Azure AI Gateway tier is built for that, and its documentation says so: in the public preview it publishes Foundry-hosted models including OpenAI, Anthropic and Mistral, alongside models hosted in AWS Bedrock, Google Vertex AI, OpenAI and Anthropic. A guided wizard imports Foundry models, and other providers are added by configuring a connection with the backend authentication set on that connection. All published models are then reachable under the same stable endpoint, with applications continuing to use the OpenAI-compatible or Anthropic request shapes they already speak.

That is the substantive point behind the cross-cloud query. A gateway that could only front its own cloud's models would be a vendor lock with extra steps; one that fronts models across clouds makes a mixed estate consistent in a single place. The documentation stays honest in the other direction too: the AI Gateway tier runs in your subscription and your Entra tenant, and telemetry can be sent to destinations you control, so adopting it does not move the models or the logs into a vendor's account. The sibling page on the aws MCP gateway owns the AWS-native shape; this page's claim is narrower — an Azure gateway can publish models hosted in AWS without the application knowing.

For an MCP plan the cross-cloud fact changes the question from which cloud to which gateway owns the tool surface. MCP servers are reached by URL, and the AI Gateway tier federates a remote MCP server by URL, an OpenAPI specification, or a built-in connector, so the tool backends can sit anywhere reachable. The gateway decides the routing, the authentication to each backend and the per-asset policy; where the compute sits behind it is a detail the client never sees.

best mcp gateway: the checks that separate candidates

The head phrase's results are dominated by ranked lists, and the reason this page does not add another one is that the useful question is not which product wins but which property the decision turns on. Once the candidates are Microsoft surfaces, four checks do most of the work, and two of them are not features at all.

Check	What to ask	Why it decides the choice
Tool surface fidelity	Does the gateway expose tools only, or tools plus resources and prompts?	MCP clients differ; a gateway that drops resources or prompts silently changes what an agent can do
Identity boundary	Where does the caller's credential live, and where does the backend's?	If either credential crosses a boundary you do not control, the gateway is an exfiltration path
Per-asset policy	Can a limit apply to one tool or model, or only to the whole gateway?	Blast radius is set by the narrowest unit a policy can name
Lifecycle and exit	Can the gateway be created and changed from code, and a tool removed without redeploying everything?	The gateway you cannot version is the gateway you cannot audit

The first check is where the Microsoft surfaces already diverge: API Management states that REST-backed MCP servers support tools but not resources or prompts, and external MCP servers support tools and resources but not prompts, so a client that depends on prompts is not served today. The second is the identity model, treated below. The third is the unit of policy: the AI Gateway tier applies policies per asset, which the documentation frames as making clear which controls protect each model or MCP server. The fourth is whether the resource is code-manageable, and API Management's MCP servers qualify.

Two sibling pages are the next stop when a shortlist is not Microsoft-only: truefoundry owns the managed-middle question and composio owns the connector-catalogue shape. This page's contribution is the test, not a ranking.

bifrost mcp gateway and the open-source option Microsoft also ships

Not every Microsoft-shaped MCP gateway is a managed Azure service. The microsoft/mcp-gateway repository is an open-source reverse proxy and management layer for MCP servers, and its README describes a data gateway for routing traffic to MCP servers with session affinity and a control plane for managing the MCP server lifecycle. Servers are represented as adapters; a tool gateway router is itself an MCP server that routes tool execution to the registered tool server; and the whole thing targets Kubernetes, using StatefulSets and headless services with a distributed session store for production.

This is the surface to reach for when the MCP servers already live in a cluster. The gateway authenticates with Azure Entra ID and authorises through application roles, with read access for the resource creator and configured roles and write access restricted to the creator or an administrative role, and the sample deployment provisions the Azure infrastructure with Bicep templates. Two honesty notes come straight from the repository: the agents-and-sessions subsystem is a preview intended for evaluation and single-pod deployments rather than multi-tenant production, and session affinity exists precisely because MCP conversations are stateful and a naive round-robin proxy would break them mid-stream.

Self-hosting trades a managed SLA for control of the topology: a managed gateway puts the routing decision inside a service you configure, while the open-source proxy puts it inside a workload you operate. The litellm MCP gateway page owns the self-hosted-exit question for the model-routing side; here the point is that Microsoft's own open-source proxy is a legitimate member of the stack and is often left out when "Microsoft MCP gateway" is read as a synonym for API Management.

A gitlab ai gateway question is really an identity question

Whichever platform's name appears in the search, the part of an AI gateway that most often decides a design review is the identity boundary, and the Microsoft answer is worth stating on its own. API Management treats inbound and outbound access as two separate problems. Inbound, an MCP client can present an API Management subscription key, which API Management validates; or it can present an OAuth token or JWT issued by Microsoft Entra ID, validated by API Management, with the documentation showing the token-validation policy and the protected-resource-metadata approach for advertising the resource and its scopes. Outbound, API Management uses its credential manager to inject an OAuth 2.0 token for the backend calls an MCP tool makes, and it recommends managed identity where available so no secret is stored.

That split is the thing to copy into any MCP gateway design: the caller's credential proves who is calling, the backend credential proves the gateway to the tool server, and the two must not be the same object. The Microsoft surfaces differ in how much of this they hand you. Classic API Management MCP servers reuse subscriptions, products and policies, so the access model is the one your API team already administers. The AI Gateway tier issues runtime access keys sent in the api-key header, and its documentation warns that a key is gateway-scoped — it reaches every model and tool — so least privilege must come from policy and per-asset configuration rather than key scoping. Foundry's AI-gateway governance accepts several MCP-server authentication methods, including managed identity, key-based, custom OAuth identity passthrough and unauthenticated, and its security guidance is to keep shared credentials in a project connection and to review which headers are forwarded to backends.

The credential question also explains why other platform names keep appearing in searches. A gateway is attractive partly because it centralises credentials, and that is only safe if the gateway sits inside the trust boundary you already defend. On Azure that boundary is the Entra tenant and the subscription, which is why the AI Gateway tier's documentation makes a point of running the resource in your subscription and tenant.

ibm mcp gateway and discovery: catalogs, the registry and API Center

The last piece of the Microsoft stack is not a gateway at all but the layer that decides what a gateway is allowed to serve. Discovery turns a pile of MCP servers into a catalog an agent can choose from, and Microsoft splits it across two places. Inside the AI Gateway tier, approved models, MCP servers and tools are published for application teams, and the documentation describes the operating model as central control with team self-service: a platform group connects approved assets and publishes them, application teams test them in a console and build against them without routing every change through the centre, and the platform group keeps the guardrails and the usage picture. Foundry adds a tool catalog, where MCP servers can be added from the catalog or as a custom tool, with reuse through public and private catalogs.

Azure API Center is the broader inventory layer, and it is where enterprise discovery usually lands. Its documentation covers configuring how APIs are authenticated — API keys or OAuth 2.0 authorisation — associating those configurations with API versions, managing access for designated users or groups through access policies, and storing secrets in Azure Key Vault under the role-based access control model, with the API center using a managed identity to reach the vault. For an MCP rollout that is the difference between a gateway that routes traffic and a platform that can answer which tool servers exist, who may call them, and where the credential came from. The kong MCP gateway page owns the gateway-as-catalog view from another angle; the Microsoft version is that the catalog is a separate service from the gateway.

The trade-offs of using API Management as your MCP gateway

This is the decision most Azure teams actually face, because the API Management instance already exists. Using it as the MCP gateway is usually right, for a reason that has nothing to do with MCP: the instance already sits inside the network boundary, already holds the certificates, already logs to the destinations the security team reviews, and already has an access model the organisation understands. Adding an MCP server to it is a resource creation, not a new platform, and the server can be declared in the same Bicep or Terraform as the rest of the estate.

The trade-offs are equally concrete, and they fall into three groups. The first is preview status: the AI Gateway tier is in public preview, available in a short region list at the time of writing, offered at no cost during the preview with pricing to be announced later, and subject to change before general availability, so a production dependency on it needs a fallback plan and a reading of the current documentation rather than this page. The second is protocol fidelity: API Management's MCP support does not cover resources or prompts for REST-backed servers, does not cover prompts for external servers, and does not cover MCP server capabilities in workspaces. The third is governance reach: Foundry's AI-gateway governance routes only new MCP tools created in the portal that do not use managed OAuth, existing tools are not automatically mediated, AI gateways do not log tool traces, and policies for governed tools are applied in the Azure portal rather than from the Foundry portal.

There is a design-level trade-off underneath those three, and it is the one to raise in an architecture review. API Management is API-shaped; MCP is session-shaped, with stateful streamed connections, which is why the open-source microsoft/mcp-gateway ships session affinity and a distributed session store as first-class features. Choosing API Management as the MCP gateway is a bet that the gateway's job is policy and identity and that session routing is not needed or is handled elsewhere — reasonable for many estates and unstated for too many.

Microsoft-class identity: how our own gateway names a caller

An identity chain is worth trusting only if every hop can be named, so here is ours. backend/smartgate/core/auth.py accepts a caller two ways. The external path takes the Authorization: Bearer header, hashes the raw key, and looks the digest up in api_keys where key_hash matches and revoked_at is null; a hit yields a key_id and a team_id, and a miss is a 401. The internal path trusts an x-team-id header from the Next.js bridge and carries no key at all.

core/api_key_hash.py is the reason a key can be verified without being stored: the digest is a SHA-256 over the configured salt and the raw key, the same value the Next side computes, so only the hash ever reaches a table. core/auth_middleware.py is a pure ASGI middleware — deliberately not the framework's buffering base class, because that would break MCP's streamed responses. Once a request is authenticated it writes team_id and key_id onto the request state, binds the tenant into a context variable, and only then evaluates the rate limit, answering a refusal with a 429 that names which scope refused.

core/request_context.py is how that identity travels without being threaded through every function call: context variables carry the team, route, transport, key id and trace id, the audit hook reads them back into the log record through audit_context_params, and require_team_id turns a missing tenant into a 400 rather than a silent success.

Where SmartGate fits

SmartGate is an MCP-native algorithm gateway, which puts it on the other side of the design bet above: MCP is the primary surface rather than a resource type grafted onto an API product, making it a complement before a replacement for an Azure team. Azure API Management and its AI Gateway tier are strongest where the estate is Azure-shaped and the job is to expose, authenticate and observe tools the platform team owns; SmartGate is strongest where the job is to control what an agent does with tokens as it calls tools — capping spend before the call and keeping an audit trail of who called which tool. The five capabilities — research, context, memory, control and pipeline — are driven by seven algorithm primitives, two of which a token-budget conversation reaches for first: the budget guard, with check, count and record against a hard ceiling, and the context gate that compresses material before it reaches the model.

The operational limits that matter when you run the two side by side are the monthly token cap, the requests-per-minute limit per key, the audit-log retention window and the team key count; all four move with the plan, and the live table is the authority rather than this page. Billing is the deliberate part: the platform is paid for as a platform, and a saving share is taken only once it has saved enough to clear a floor, so the cost is meant to be self-funding rather than a flat rent.

How to get started

1. Name the one MCP client you must onboard and the one policy you must enforce on its first day; that pair decides the surface before any product comparison starts.
2. If the MCP servers are in a cluster you operate, evaluate the open-source proxy first, because self-hosting is the shortest path to session affinity.
3. If the servers are REST APIs already managed in Azure, create one MCP server from a single API and expose one operation as a tool — the smallest test of the API Management path.
4. Read the current Microsoft documentation for the tier, the region list and the supported MCP capabilities before committing, because the preview surface is moving. When the question moves from routing tools to controlling what the agent spends on them, start free with an MCP-speaking client, then read the pricing page once real call volume tells you which tier you need.

Limitations

This page is a reading of Microsoft's documentation on 2026-10-03, not a benchmark and not a substitute for that documentation. The two most important surfaces it describes — the AI Gateway tier and Foundry's AI-gateway tool governance — are in preview, so their regions, limits, pricing and supported MCP capabilities can change before general availability, and a decision taken from this page alone will age faster than the products will. Every claim about a Microsoft capability is attributed to a documentation URL under Sources; where the documentation was silent on a figure, this page says so rather than supplying one.

The page deliberately does not evaluate any vendor other than Microsoft: the section headings name search phrases, not products under review, and the cluster's vendor pages own those platforms. It also carries no code excerpt, so it makes no line-numbered or implementation-level claim about any codebase, and it is not a migration guide — moving between a self-hosted proxy and API Management has consequences this length cannot responsibly cover.

Sources

• Microsoft Foundry — Govern MCP tools by using an AI gateway (preview), for the routing path, the required connection to API Management, the MCP-server authentication methods and the preview limitations.
• Azure API Management — AI Gateway tier (preview) overview, for the model-and-tool control plane, the tool-server endpoint shape, the three backend sources, the policy cards and the runtime key model.
• Azure API Management — Overview of MCP servers in API Management, for the two ways to expose an MCP server.
• Azure API Management — Expose a REST API as an MCP server, for the REST-backed flow and the tools-versus-resources-and-prompts boundary.
• Azure API Management — Expose and govern an existing MCP server, for passthrough servers, the transport types and the MCP version requirement.
• Azure API Management — Manage MCP servers programmatically, for the MCP resource type, tool sub-resources, policies and product binding.
• Azure API Management — Secure access to MCP servers, for inbound key and token validation, outbound credential-manager injection and the supported tiers.
• Azure API Center — Configure API access, for the inventory, authentication-configuration and access-policy layer.
• Microsoft — microsoft/mcp-gateway, the open-source reverse proxy and control plane for MCP servers on Kubernetes.
• Secondary coverage — InfoQ, used only to corroborate the preview's region list and best-effort availability.
• The Model Context Protocol — specification, for the protocol version and transport vocabulary the Microsoft documents reference.
• Demand figures are this project's own paid measurement (US, twelve-month window), recorded in search_volume.json and research_brief.md; the Microsoft behaviour above was read from the documentation pages listed here on 2026-10-03.

Method note

This page carries no code excerpt, and that is a recorded finding rather than an omission. The slice matcher recorded 0 of 7 sections pinned for this project, with 7 no-slice verdicts and no abstentions: rule A found no unique local symbol for any of the seven section phrases, and the remote candidate lookups it ran returned generic container and helper symbols from an unrelated codebase rather than a symbol this page could quote. A pinned generic would have given the page the shape of a verified article with none of the substance, so every section above is written from Microsoft's published documentation, which is the house rule for an unpinned section. No code, batch fingerprints, auction data or internal hosts appear here.

The slice run for this page recorded 0 of 7 sections pinned, 0 abstention(s) and 7 no-slice verdict(s); BLOCKS is empty because rule A found no unique symbol for any section phrase, as the Method note above explains.