# MCP Gateway: Microsoft's Kubernetes-Native Reverse Proxy for MCP Servers

> An open-source C# application from Microsoft that sits between AI clients and Model Context Protocol servers in Kubernetes, providing session-aware routing, a RESTful control plane for server lifecycle management, Entra ID authentication, and a React management portal. It is the production-grade deployment layer that a standalone MCP server does not provide.

**microsoft/mcp-gateway** — MCP Gateway is a reverse proxy and management layer for MCP servers, enabling scalable, session-aware stateful routing and lifecycle management of MCP servers in Kubernetes environments.

- Repository: https://github.com/microsoft/mcp-gateway
- Website: https://microsoft.github.io/mcp-gateway/
- Stars: 855 · Forks: 93
- Language: C#
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-mcp-gateway

## What Problem MCP Gateway Solves and Who Needs It

A single MCP server running in a container is straightforward to deploy. The problem emerges at scale. When a team operates ten or twenty MCP servers for different tools and agents, they face three operational gaps. First, there is no standard way to route traffic between clients and servers with session affinity: every request with the same session ID must reach the same server instance. Second, there is no lifecycle management layer: deploying, updating, or removing a server requires direct Kubernetes manipulation. Third, there is no centralized access control: each server implements its own authentication or relies on network perimeter security. MCP Gateway fills all three gaps. It provides a data plane for routing and a control plane for lifecycle management, both behind Entra ID authentication and role-based access control. The architecture is designed for Kubernetes using StatefulSets and headless services for the session routing backend.

## Two Planes: Control for Lifecycle, Data for Routing

The control plane exposes a RESTful API for managing adapters and tools. An adapter is the gateway's representation of an MCP server. The core operations are:

```
POST /adapters
GET /adapters/{name}/status
GET /adapters/{name}/logs
PUT /adapters/{name}
DELETE /adapters/{name}
```

Tool registration follows the same pattern at the /tools scope. Each tool registration includes the container image, the MCP tool definition (name, description, input schema), the execution endpoint, and deployment configuration. The data plane exposes two routing paths. Direct access goes through /adapters/{name}/mcp as a streamable HTTP connection to a named server. Dynamic tool routing goes through /mcp and reaches the Tool Gateway Router, which is itself an MCP server that reads all registered tool definitions and routes execution requests to the correct server based on tool name. Multiple router instances run behind the gateway for scale and session affinity.

## Session-Aware Stateful Routing and the Distributed Session Store

MCP is a stateful protocol. A client that opens a session with a server cannot have subsequent requests routed to a different server instance; the context would be missing. MCP Gateway enforces session affinity by reading the session_id from incoming requests and routing all requests sharing that ID to the same server instance. In production mode, the session store is distributed (the README describes this as a stateless reverse proxy with a distributed session store), which allows the gateway itself to run as multiple replicas without each replica having exclusive knowledge of which session maps to which backend. In development mode the README indicates a simpler local configuration is available. The Kubernetes deployment uses StatefulSets and headless services to give each backend replica a stable network identity, which is required for affinity-based routing to work reliably.

## Authentication: Entra ID, RBAC, and the mcp.admin Role

The gateway supports two access modes. In development mode it runs without authentication, with an optional identity switcher in the management portal for testing different role assignments. In cloud mode it uses Microsoft Entra ID (formerly Azure Active Directory) for bearer token authentication. The authorization model has two roles. The mcp.admin role grants full read and write access to all resources. A configurable requiredRoles set (for example mcp.engineer) grants read access to resources; when requiredRoles is empty, only the resource creator and mcp.admin principals can read a resource. Write access for non-admin principals is limited to resources they created. The documentation for configuring Entra ID app roles is in docs/entra-app-roles.md. The management portal mirrors the same access control: each listing call filters to the resources the signed-in user is allowed to see.

## Agents and Sessions Preview and the Tool Gateway Router

The Agents and Sessions feature is an opt-in preview that activates only when a FoundrySettings:Endpoint is configured. An Agent in this context is a metadata record: a system prompt, a model name, and an allowed tool list. A Session is a single run of an agent that streams events over Server-Sent Events. The /sessions/run endpoint starts a session and the /sessions/{id}/messages endpoint continues it. These features run LLM-driven agents on top of the registered MCP tools, making MCP Gateway not just a routing layer but a partial agentic runtime. The Tool Gateway Router is a separate MCP server instance that the gateway hosts and which reads all registered tool definitions to perform intelligent routing. This means that a client connecting to /mcp does not need to know which underlying server implements a given tool; the router resolves it at request time.

## Limitations: Azure Dependency and Deployment Complexity

The identity layer is Entra ID only. Teams that do not use Azure Active Directory or that need to support non-Microsoft identity providers have no documented alternative authentication path. The project requires Kubernetes for the session-aware production deployment; the README mentions a local development option but the production architecture assumes Kubernetes, StatefulSets, and headless services. There are no GitHub releases, so there is no versioned stable release. Adopters should pin to a specific commit for stability. The Agents and Sessions feature requires an Azure AI Foundry endpoint, making that feature exclusive to Azure. The management portal is a React SPA served by the gateway itself; it depends on the same authentication configuration and cannot be replaced with a third-party portal.

## Compared to a Standalone MCP Server and Licence Terms

The alternative to MCP Gateway is running each MCP server individually with its own endpoint, letting each client maintain direct connections without a centralized routing layer. This works fine for a single agent and one or two tools, but breaks down when multiple agents need to share the same tools, when session affinity is required across server restarts, or when access control needs to be enforced without per-server implementation. LiteLLM, which some community questions compare to MCP Gateway, is a proxy for LLM API calls rather than an MCP routing layer; the two tools address different parts of the infrastructure stack. MCP Gateway is MIT-licensed, which permits commercial use and modification. The project includes a SECURITY.md and a CODE_OF_CONDUCT.md, indicating a Microsoft open-source project with active governance policies. The last push was on 2026-09-11.

## Conclusion

MCP Gateway is the right infrastructure choice for teams deploying multiple MCP servers in a Kubernetes environment and needing centralized session management, access control, and operational visibility. It is not a fit for a single-server setup, a development laptop, or a team that does not use Azure or Entra ID for identity. Before adopting, verify that the Agents and Sessions preview feature is appropriate for your use case: it requires an Azure AI Foundry endpoint and is opt-in, not enabled by default. The tool registry and dynamic routing make this useful beyond a single-vendor context, but the control plane REST API and identity layer are Azure-native. The project is MIT-licensed. The last push was on 2026-09-11.

## FAQ

### What is the difference between an MCP proxy and an MCP gateway?

A proxy forwards requests transparently without managing server lifecycle or session state. MCP Gateway adds a control plane for deploying and updating MCP servers, session-aware routing that keeps all requests with the same session ID on the same server instance, and Entra ID authentication with role-based access control.

### What does MCP Gateway do?

MCP Gateway routes traffic from AI clients to the correct MCP server with session affinity, manages the deployment lifecycle of MCP servers through a REST API, enforces access control via Entra ID and configurable roles, and provides a React management portal for operations.

### How does MCP Gateway compare to an MCP registry?

An MCP registry is a catalog of available servers and tools. MCP Gateway includes tool registration and a Tool Gateway Router that routes to registered tools, but its primary function is active traffic routing and lifecycle management rather than static discovery. The README uses separate /adapters and /tools scopes to distinguish server management from tool registration.

## Sources

- [Issues](https://github.com/microsoft/mcp-gateway/issues)
- [License: MIT](https://github.com/microsoft/mcp-gateway/blob/main/LICENSE)
- [microsoft/mcp-gateway on GitHub](https://github.com/microsoft/mcp-gateway)
- [Project website](https://microsoft.github.io/mcp-gateway/)
- [README](https://github.com/microsoft/mcp-gateway/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-mcp-gateway