The Model Context Protocol (MCP) gateway is now generally available (GA) as part of the Red Hat Connectivity Link 1.5 release, and natively integrated into the Red Hat AI portfolio. This follows a successful technology preview, and expands Red Hat's enterprise AgentOps capabilities to govern AI agent tool traffic at scale. We've added new features, including gateway isolation, stateless session support, prompts and resources support, MCP guardrails, and security hardening to make it ready for production use.
Gateway and MCP server isolation
You can cater to different teams and tenants in your organization by isolating MCP agent traffic. There are 2 ways to do this. The first is to delegate a completely separate gateway instance, including the MCP gateway components (the router and broker). This approach keeps the traffic isolated from each other all the way through to the back-end MCP server.
The second way is to use a shared gateway, providing isolation from the gateway listener level down. Separate MCP gateway components are still used, which keeps the traffic isolated after the gateway routing logic is triggered. This allows the core gateway infrastructure to be shared with different endpoints for sets of MCP servers behind a single gateway endpoint (for example, /mcp-team-a and /mcp-team-b).
Prompts and resource federation
The gateway now federates MCP prompts from upstream servers alongside tool-calling capabilities. Prompts are prefixed the same way as tools and are accessible through prompts/list and prompts/get through the gateway. Authorization filtering supports prompts using the allowed-capabilities JWT claim. A virtual server can scope prompts with the spec.prompts field on the MCPVirtualServer resource, verifying that AI agents are constrained to authorized system prompts and context.
Resource federation currently covers the resources/list and resources/read methods for prefixed ui:// resources, primarily on the stateful path. Like tools and prompts, you can filter resources based on authorization rules to govern the enterprise data surfaced to agents.
Progressive tool discovery
As the number of tools behind a gateway grows across enterprise MCP catalogs, returning everything in a single tools/list response becomes impractical and degrades LLM context efficiency. In the upstream project, we added progressive tool discovery with 2 built-in meta-tools: discover_tools and select_tools in an earlier release. With the GA of MCP gateway, this feature is now available in Red Hat's AI gateway product, Red Hat Connectivity Link.
First, discover_tools returns lightweight metadata (server names, categories, hints, and tool names without schemas) so an agent can browse what's available. Then select_tools scopes the stateful session to a working set of tools, sending a notifications/tools/list_changed event so the agent refreshes its view. Because this feature relies on sessions and state, it's only available for the stateful protocol version at this time.
Operators can annotate their MCPServerRegistration resources with category and hint fields to make servers discoverable. For example:
2026 stateless protocol support
The MCP specification published a new protocol version (2026-07-28) that introduces a stateless HTTP transport, enabling serverless and horizontally scalable AI agent workloads on Red Hat OpenShift. The MCP gateway now supports both the previous 2025 protocol versions (2025-11-25, 2025-06-18, 2025-03-26), and this new 2026 version simultaneously on a single endpoint. Clients can negotiate the protocol version, and the gateway routes accordingly. This allows older MCP servers to continue to expose tools through the old protocol alongside newer MCP servers that support the stateless protocol. The /mcp path auto-negotiates, while a dedicated /mcp/stateful path forces the older protocol version.
Observability and auditing
The router now emits a structured audit log entry for valid tools/call requests for security auditing, which complements Red Hat AI's OpenTelemetry and MLflow integrations for end-to-end agentic tracing. Each entry is logged at the INFO level with audit=true and carries the calling user (the JWT sub claim) if available, the tool and server names, the response status, and request and session identifiers:
Entries are emitted both when a call reaches the backend and when the router rejects it early (for example, on a session init failure or unknown server).
A number of metrics have been added to the MCP broker component to give insights into backend MCP server connections. The broker now exposes Prometheus metrics on a dedicated scrape endpoint (9090 by default). 5 new metrics cover upstream discovery health, tool inventory, connection stability, and response sizes:
- mcp_broker_discovery_total (counter): Discovery attempts per upstream server
- mcp_broker_discovery_duration_seconds (histogram): Duration of discovery calls
- mcp_broker_tools_discovered (gauge): Current tool count per server
- mcp_broker_upstream_connection_failures_total (counter): Connection failures per server
- mcp_broker_tools_list_response_bytes (gauge): Size of tools/list response per server
All metrics rely on server_name as the primary label, bounded by the number of MCPServerRegistration resources, to avoid cardinality explosion. Additional labels are added conservatively where they make sense. For example, a status label on the mcp_broker_discovery_total metric.
NeMo guardrails integration
The MCP gateway now natively integrates with NeMo guardrails, the default guardrail service across Red Hat AI. It works by checking the MCP tools/call request and response bodies, enforcing active safety policies before tools execute. For requests, it verifies the payload before the underlying gateway proxy sends it to an MCP backend. For responses, it screens returned data before it is sent back to the client, which helps prevent prompt injection attacks or sensitive data exfiltration. This happens independently of authentication or authorization.
To use the integration, you must install NeMo, and configure the endpoint you want content sent to. A specific list of config IDs (for different check types) can be configured for applying to all gateway traffic. You can also configure a list of config IDs for each MCP server, should you want additional checks to apply on some servers (server config IDs are additive). This configuration is a Secret with annotations on the MCPGatewayExtension and MCPServerRegistration resources, for example:
Console plug-in UI
Red Hat's AI gateway product, Red Hat Connectivity Link 1.5, introduces the new Connectivity Link MCP gateway console plug-in (developer preview). With the new console plug-in, teams can create, configure, and visualize both MCP gateways and servers while interactively testing server capabilities directly from Red Hat OpenShift Console. You can set up new MCP gateways and register their MCP servers with step-by-step workflows. An overview page gives you the ability to manage your MCP Gateway resources, and provides a window into the status and health of your MCP gateways and registered servers .
An MCP inspector experience has been built into the console to allow you to connect to your MCP gateway as a client would, including configuring an authentication header. Tools and prompts can be listed in this inspector view. You can read individual prompts in detail, and inspect individual tools and the calls made to them. This provides a built-in way to test and troubleshoot your MCP gateway configuration and agent tool calls completely within OpenShift Console, bridging platform administration with the AI engineer and developer experience in Red Hat AI.
Finding out more
To install and configure your gateway for MCP traffic, read the latest MCP gateway documentation.
Additionally, you can explore the MCP Catalog blog to discover more enterprise tools.
/)
