MCP Gateway
An MCP (Model Context Protocol) Gateway, also called an MCP proxy, is a reverse proxy that sits between MCP clients — AI agents and IDE assistants — and the MCP servers that expose tools and resources to them. It presents a single endpoint, routes each request to the correct MCP server, and applies governance such as access control, credential injection, and rate limiting before traffic reaches any server.
NetScaler® MCP Gateway extends these capabilities to Kubernetes. NetScaler Kubernetes Gateway Controller watches Kubernetes resources and programs NetScaler to front your MCP servers, so you configure and manage the gateway using Kubernetes-native resources — without manual CLI or GUI configuration on the NetScaler instance.
Overview
When to use MCP Gateway
-
Your AI agents and assistants need a single governed entry point to many MCP servers.
-
You want to route to MCP servers by a request header, so onboarding a server is a route change rather than a firewall change.
-
You want the upstream API token held at the gateway instead of in the MCP server workload or the client.
-
You need to control which MCP servers an agent may reach, cap tool usage with rate limits, and export per-transaction records.
-
You manage gateway configuration as Kubernetes manifests through GitOps workflows.
Deployment options
The Gateway Controller supports two NetScaler form factors depending on where your MCP clients run:
| Deployment | Form factor | Use when |
|---|---|---|
| In-cluster | NetScaler CPX | MCP clients run inside the Kubernetes cluster. The front end can be HTTP or HTTPS (TLS termination) and the virtual IP address is the CPX pod IP |
| External | NetScaler VPX / MPX / BLX | MCP clients run outside the cluster. The front end can terminate HTTPS/TLS at the edge and the virtual IP address is a static or IPAM-allocated address |
Architecture
The Gateway Controller sits in the control plane. It watches Kubernetes resources and programs NetScaler — it is not in the traffic path. MCP requests flow directly from the client to NetScaler and on to the MCP server.
Each request lands on a single content switching (CS) virtual server that fronts the gateway. The CS virtual server switches on the routing header to a per-server load balancing (LB) virtual server, which forwards the request to the backend MCP server:
client -> NetScaler CS virtual server -> per-server LB virtual server -> backend MCP server
Key Kubernetes resources
| Resource | Defined by | Purpose |
|---|---|---|
GatewayClass |
Gateway API (upstream) | Binds the Gateway to the NetScaler controller (CPX or VPX/MPX/BLX) |
Gateway |
Gateway API (upstream) | Defines the listener that fronts MCP traffic and carries the front-end MCP profile |
mcproute |
NetScaler CRD | Header-based routing rule that matches a request to one MCP server and forwards it to the backend service |
mcpprofile |
NetScaler CRD | MCP proxy settings — a FRONTEND reverse-proxy profile on the Gateway, or a BACKEND forward-proxy profile on the route |
GatewayClass and Gateway are standard Gateway API resources. mcproute and mcpprofile are NetScaler-specific CRDs (group citrix.com/v1) installed with the Gateway Controller and are not portable to other Gateway API implementations.
Note:
Routing keys on the
x-netscaler-target-mcp-server request header, with the value <server>.mcp.example/. The trailing slash is required. The controller compiles the header match to a content switching policy that takes the part of the header before the first slash and checks whether it contains the route value (a substring match, not a prefix match). Without the trailing slash, there is nothing before a slash to check, so the request does not match the route and falls through to the gateway default.
Platform support (CPX vs VPX)
Both form factors support the core MCP Gateway capabilities. The one difference is client authentication: the AAA-governed OAuth 2.1 path is available on external NetScaler (VPX/MPX/BLX) only.
| Capability | NetScaler CPX (in-cluster) | NetScaler VPX/MPX/BLX (external) |
|---|---|---|
| Header-based routing | Yes | Yes |
| Host / URL replacement | Yes | Yes |
| ExternalName backends | Yes | Yes |
| Server access control | Yes | Yes |
| Tool-based rate limiting | Yes | Yes |
| OAuth 2.1 client authentication | No | Yes |
| Gateway credential injection | Yes | Yes |
| Splunk observability | Yes | Yes |
Important:
OAuth 2.1 client authentication (the AAA-governed authentication path) is available for MCP only on external NetScaler VPX/MPX/BLX. It is not available for MCP on NetScaler CPX. Use a VPX/MPX/BLX deployment when clients must authenticate to the gateway.
Related topics
Reference
For MCP Gateway configuration at NetScaler level, see MCP Gateway.