Red Hat’s MCP Gateway Hits GA With Tool Discovery, Audit Logs and NeMo Guardrails

Published October 17, 2026 (IST) by the AgentStack News Desk. Facts were checked against Red Hat’s October 16, 2026 announcement, the upstream Kuadrant MCP Gateway documentation, and the project’s GitHub releases.

Red Hat made its Model Context Protocol gateway generally available on October 16, 2026, as part of Red Hat Connectivity Link 1.5 for OpenShift. The release moves the component out of technology preview and into Red Hat’s supported API management layer for agent tool traffic.

The GA build adds tenant isolation, stateless MCP protocol support, progressive tool discovery, structured audit logs, Prometheus metrics, and NVIDIA NeMo Guardrails checks on tool calls.

The AgentOps angle: the MCP gateway is turning into the place where platform teams log, filter, and police every agent tool call. This report draws on the Red Hat announcement, the upstream Kuadrant tool discovery guide, and the Kuadrant mcp-gateway repository, per our editorial standards.

What Red Hat Shipped in Connectivity Link 1.5

Connectivity Link 1.5 promotes the MCP gateway to general availability after a technology preview period. Red Hat describes the release as an expansion of its enterprise AgentOps capabilities for governing agent tool traffic at scale, with isolation, stateless sessions, prompts and resources, guardrails, and security hardening called out as the new production features.

The product is built on the open source Kuadrant MCP Gateway, an Envoy-based gateway that aggregates many MCP servers behind one endpoint and plugs into Istio and Kubernetes Gateway API policy for authentication, authorization, and rate limits.

GA feature	What it does	Caveat from the source
Gateway isolation	Separate gateway per team, or a shared gateway with per-team endpoints	Shared mode isolates from the listener level down
Stateless protocol	Serves MCP 2026-07-28 and three 2025 versions on one endpoint	/mcp/stateful forces the older protocol
Tool discovery	Two meta-tools browse and scope the tool catalog	Stateful sessions only for now
Prompt and resource federation	Prefixed prompts and ui:// resources through the gateway	Resources mainly on the stateful path
Audit logs and metrics	Structured tools/call log lines plus five broker metrics	Caller identity only when a JWT is present
NeMo Guardrails	Screens tool-call request and response bodies	Requires a separately installed NeMo service
Console plug-in	Create, view, and test gateways in OpenShift Console	Developer preview, below GA support

How Isolation and Protocol Negotiation Work

Red Hat offers two isolation models. A team can get a fully separate gateway instance, including its own MCP router and broker, which keeps traffic apart all the way to the backend server. A shared gateway instead splits traffic from the listener level down, with separate MCP components behind paths such as /mcp-team-a.

The shared model is the cheaper default, but the dedicated model is the one to pick when a regulator or tenant contract asks for hard separation.

Protocol support matters just as much. The MCP specification’s 2026-07-28 version introduced a stateless HTTP transport that suits serverless and horizontally scaled agent workloads. The gateway serves that version and the 2025-11-25, 2025-06-18, and 2025-03-26 versions on a single endpoint, routing each client by negotiated version.

Endpoint path	Behavior	When to use it
/mcp	Auto-negotiates the protocol version per client	Default for mixed fleets of old and new clients
/mcp/stateful	Forces the older stateful protocol	Clients that need tool discovery or stateful resources

Our MCP explained guide covers why stateless transport changes how servers scale. Teams comparing this release with other platform defaults can read our Kong vs AWS AgentCore vs Docker comparison and the wider MCP gateways list.

Why Progressive Tool Discovery Matters for Agents

Large MCP catalogs flood the model’s context with tool schemas, which costs tokens and hurts tool selection. Progressive discovery replaces the full list with two meta-tools. discover_tools returns server names, categories, hints, and tool names without schemas, and select_tools scopes the session to a chosen subset.

After a selection, the gateway sends notifications/tools/list_changed and the next tools/list returns full schemas for only the selected tools. The upstream guide adds a --discovery-tool-threshold flag. At the default of zero, every tool still appears; at a positive value such as 20, larger catalogs show only the meta-tools.

apiVersion: mcp.kuadrant.io/v1
kind: MCPServerRegistration
metadata:
  name: weather-server
spec:
  prefix: weather
  category:
    - data
    - environment
  hint: "Weather forecasts and historical climate data"
  targetRef:
    name: weather-server

Discovery quality depends on the category and hint metadata operators write, so vague hints lead agents to the wrong tools. The upstream docs cap categories at three items and hints at 256 characters. Both meta-tools only see tools that survive authentication and virtual server filtering, so an agent cannot discover a tool it is not allowed to call.

What the Audit Logs, Metrics, and Guardrails Add

Every valid tools/call now produces a structured log entry at INFO level with audit=true. Each line carries the calling user from the JWT subject claim when present, the tool and server names, the response status, and request and session identifiers. Calls that the router rejects early are logged as well.

level=INFO msg="tool call" audit=true user=alice@example.com tool=echo server=mcp-test/my-server status=200 request_id=<uuid> session=<id>

The broker also exposes Prometheus metrics on port 9090 by default. Five new series cover discovery attempts, discovery duration, tools discovered per server, upstream connection failures, and the byte size of each server’s tools/list response. All of them use server_name as the primary label to limit cardinality.

A sudden jump in tools discovered or tool list bytes for one server is a cheap early signal of tool sprawl or a changed upstream server. Red Hat positions the logs alongside its OpenTelemetry and MLflow integrations; our Claude Platform OpenTelemetry traces report and agent observability tools guide cover the tracing side.

NeMo Guardrails, the default guardrail service across Red Hat AI, now plugs into the gateway. It checks tools/call request bodies before they reach a backend and response bodies before they return to the client, aiming at prompt injection and data exfiltration. Operators set global config IDs and can add per-server checks through a Kubernetes Secret and annotations.

Screening runs separately from authorization, so it adds to access policy without replacing it. Recall the tool-layer bugs in our ToFu MCP server report: a guardrail on the response path is one more place to catch a poisoned tool output.

Why This Release Matters for AgentOps Teams

MCP gateways began as connection routers. This release shows the category absorbing governance work that platform teams used to build themselves: tenant isolation, per-call audit records, tool inventory metrics, and content checks. For OpenShift shops, it now ships as a supported product.

What to verify on day one

Start with one team on a shared gateway, route the audit log to your SIEM, and alert on broker connection failures before you add more servers. Treat the guardrail as a second layer and keep least-privilege tool scopes at the authorization layer.

• Confirm which clients still need /mcp/stateful for discovery or resources.
• Write specific category and hint metadata for every registered server.
• Set a discovery threshold once a virtual server exposes more than a few dozen tools.
• Track upstream releases; v1.0.2 shipped on October 16 with log redaction fixes.

# Illustrative Prometheus alert using the GA broker metrics (not a Red Hat default)
- alert: MCPUpstreamFailing
  expr: increase(mcp_broker_upstream_connection_failures_total[10m]) > 5
  labels: {severity: warning}
- alert: MCPToolSprawl
  expr: delta(mcp_broker_tools_discovered[1d]) > 10

For the wider stack, see our AgentOps tools map and LLM gateways guide.

The Upstream Project Behind the Product

The open source Kuadrant MCP Gateway is written mostly in Go under the Apache 2.0 license. It reached v1.0.0 on September 25, 2026, and v1.0.2 landed on October 16, the same day as Red Hat’s announcement, with a backport of log redaction fixes to the 1.0 release line.

Tool discovery first appeared upstream in the 0.7 tech preview release in June 2026, together with per-user tool listings and prompt federation. Upstream users get the same core features but handle patching and support themselves.

Limits and Open Questions

Several pieces are still short of production grade. The OpenShift Console plug-in, with its built-in MCP inspector, is a developer preview. Tool discovery and most resource federation depend on the stateful path, so teams moving agents to the stateless 2026-07-28 transport give up discovery for now.

Guardrails add latency and a NeMo service you must deploy and size. The announcement publishes no latency figures or Connectivity Link 1.5 pricing, so we have not verified overhead or cost.

What to Watch Next

Four follow-ups will show whether the gateway becomes the default control point for agent tools on OpenShift. The MCP project’s release plan targets its next specification version for December 15, 2026, with agent identity and enterprise security listed among the roadmap themes.

• Stateless discovery: whether discover and select tools gain a stateless path.
• Console plug-in: when the plug-in and inspector move from developer preview to GA.
• Guardrail overhead: published latency figures for NeMo checks on busy gateways.
• Spec alignment: how fast the gateway adopts the December specification changes.

Choosing what to put behind a gateway like this? Our 15 best MCP servers for enterprise teams guide sorts production servers by use case and governance controls.

Frequently Asked Questions

The Bottom Line

Red Hat’s GA release turns the MCP gateway into a governed control point for agent tool traffic on OpenShift, with audit lines, metrics, and guardrails in one supported product. The smart first move is a narrow pilot that proves the audit trail and discovery metadata before more teams and servers join.

We will update this story when Red Hat publishes full Connectivity Link 1.5 release notes, latency figures for guardrails, or a stateless path for tool discovery. Send corrections through our contact page.

Related coverage: MCP, AgentOps, MCP gateways, Kong vs AWS AgentCore vs Docker, MCP explained, and MCP server security bugs.