The Model Context Protocol (MCP) makes it possible to give large language models (LLMs) access to a diverse set of data sources so they can reason and arrive at data-driven conclusions. In complex Red Hat OpenShift environments, MCP can serve as a standardized, strategic bridge between these models and our intricate data layers. This is the first step towards transitioning to proactive observability horizontally within an organization, where AI acts as a functional extension of site reliability engineering (SRE) teams.
The obs-mcp
component, now integrated into MCP server for Red Hat OpenShift, helps bring that vision closer to reality. Traditional observability workflows have long been plagued by a cognitive friction we call the manual correlation bottleneck. When a production incident occurs, engineers face the mental load of jumping between disparate systems, each with its own query language and conventions, like PromQL for metrics, LogQL for qualitative data, and TraceQL for distributed spans. They then have to manually stitch together an incident timeline while the clock ticks. By providing a structured interface, MCP-based tools allow AI agents to automate these correlations, transforming high-volume telemetry into a resource you can access via natural language conversations and then take action on.
The observability toolset
When it comes to observability, you’re always worried that you’ll need data you don't have. This drives organizations to increase the scope of data collection in an effort to improve resiliency, which leads to substantial growth in the volume of observability data. Comprehensive data sets are great news in theory, but LLM-based agents trying to parse them can be hamstrung and lose their reasoning capabilities due to an overwhelmed context window.
To prevent such situations, we must prioritize precision. obs-mcp
is engineered to guide LLMs so they query observability data following the patterns of an experienced SRE and take advantage of observability tools as intended in their original design. Built in Go, obs-mcp
acts as a standardized, secure bridge between AI clients and many cloud-native observability systems, including Prometheus, Thanos, Alertmanager, Grafana Loki, and OpenTelemetry Collectors.
obs-mcp
makes the following toolsets available to provide granular isolation of operational capabilities:
- Metrics: Provides the quantitative backbone for diagnostics. Running the
list_metrics
tool is a mandatory first step, and is followed by a series of steps touching Prometheus-compatible API endpoints, which require the AI to discover existing metrics and their labelsets before querying. This enforces a discovery-first model, preventing inefficient data retrieval and unnecessary token use. - Traces: Interacts with Grafana Tempo to enable complex TraceQL queries, allowing agents to navigate distributed system call hierarchies across spans and isolate latency bottlenecks.
- Logs: Leverages Grafana Loki for qualitative analysis of system events across the cluster. (Note: This is a work in progress that will be released soon.)
- OpenTelemetry Collector: Provides configuration assistance that helps the user compose their collection pipelines and transforms exactly as they need to, without running into versioning issues or misconfigurations in production.
obs-mcp
does not aim to merely provide raw API connectivity. The philosophy behind it is that LLMs should query observability data like an experienced SRE would: with absolute specificity, testing hypotheses and staying within strict data guardrails. To prevent models from choking on massive data dumps, the project features a collection of tightly constrained tools and built-in prompt strategies that force the AI to be surgical. The goal is to find the needle in the haystack, not to dump the haystack on your agent. Let’s take a dive into obs-mcp
‘s capabilities to see how it works.
Adaptive toolsets and granular isolation
Rather than exposing every backend simultaneously, obs-mcp
structures access into specific operational boundaries via the --toolsets
flag (e.g., metrics, logs, traces, otelcol). By setting up and selecting only the toolsets that they need, users can minimize the scope of what the LLM can see. The --toolsets
flag allows the LLM to meet the user where they are in their observability journey.
Operation integrity and guardrails
Agentic operations must never compromise platform stability. obs-mcp
acts as both a gatekeeper and an instructor, shaping how the AI interacts with your monitoring backends. One of the easiest ways for an LLM to break (and crash your monitoring backend) is for it to issue a blanket regex query—trying to pull every log line containing the word "error" across an entire enterprise Kubernetes cluster, for instance.
obs-mcp
enforces strict guardrails directly at the protocol level. For example, it interfaces natively with Thanos time series database (TSDB) status endpoints to analyze metric cardinality before executing a query. If an LLM attempts to pull a PromQL metric that exceeds safe limits (max-metric-cardinality
), or passes a broad regular expression, the guardrail intercepts it, returning a structured error. This teaches the LLM to refine its prompt and narrow its scope down to specific namespaces, pods, or workloads before trying again. Over time, the LLM learns from these errors how to interact more efficiently with observability data.
Note that guardrails that rely on TSDB status analysis require Thanos v0.40.0 or later. Older versions do not expose the /api/v1/status/tsdb
endpoint, which is a hard blocker for metric cardinality protections.
Core architecture: Go-native design for the enterprise
For enterprise environments, architectural integrity isn't just about features—it’s about the footprint. We have directly embedded obs-mcp
into MCP server for Red Hat OpenShift for ease of use. The latter is a Go-native implementation, which is a deliberate choice over command-line interface (CLI) wrappers or interpreted scripts. By interacting directly with the Kubernetes API, the server provides high performance and low latency with a zero-dependency footprint, eliminating the need to manage Node.js or Python runtimes on the host.
MCP server for Red Hat OpenShift includes a --stateless
mode, which is a vital design principle for cloud-native scalability. This enables the server to be horizontally scaled and load-balanced without requiring session affinity.
In dynamic OpenShift environments, static endpoint configuration can be brittle. MCP server for Red Hat OpenShift is designed to work with OpenShift cluster and monitoring APIs, helping an AI agent query the appropriate data sources as the environment changes. For metrics, it can use the Thanos Querier route for a global monitoring view and access Prometheus-based monitoring endpoints where appropriate.
Strategic outcomes: Transforming the operational lifecycle with obs-mcp
With MCP-based tools, human operators spend less time correlating data and become high-level decision-makers, supervising AI platforms that provide pre-correlated context.
This shift helps deliver value across three strategic areas:
- Incident triage: The MCP server can drastically reduce mean time to recovery (MTTR) by enabling the AI to automatically match disparate signals or correlate related data across a single signal—for instance, it could correlate a spike in 5xx errors with a node memory pressure event.
- Telemetry exploration and discovery: The MCP server democratizes access to complex query languages like TraceQL and PromQL, allowing non-experts to investigate their own distributed systems and distributed traces.
- Rapid deployment: Developers can use natural language prompts to debug deployments, validate OpenTelemetry Collector schemas, and check resource usage in real time.
All in all, because obs-mcp
is implemented via a lightweight, secure JSON-RPC standard that is supported by AI engineering platforms like Claude Desktop, Cursor, and many custom multi-agent frameworks, dev and operations teams can easily configure their systems to inspect production states. Whether it is automatically deciphering complex OpenTelemetry Collector configurations, correlating an Alertmanager firing notification with exact Loki logs, or querying an OpenShift cluster safely using native token authentication (auth-mode kubeconfig
), obs-mcp
turns a chaotic sea of telemetry into a clean, actionable stream of context.
The result is a workflow where the AI stops acting like a text bot guessing what’s wrong, and starts executing highly specific, data-efficient investigative steps—just like a human SRE on call.
The future of agentic operations
The MCP server for Red Hat OpenShift and obs-mcp
projects represent a new standard for human-machine interaction when it comes to observability tools in the Cloud Native Computing Foundation (CNCF) ecosystem. By bringing OpenShift observability to AI platforms via the Model Context Protocol, we are moving toward a future where clusters are self-diagnosing and AI assistants act as true partners in maintaining platform reliability.
We invite the community to explore obs-mcp
capabilities by leveraging MCP server for Red Hat OpenShift directly, and provide feedback to help us refine the future of AI-native operations.
Facts Only
* The Model Context Protocol (MCP) allows LLMs access to diverse data sources for reasoning.
* obs-mcp is integrated into the MCP server for Red Hat OpenShift.
* Traditional observability workflows suffer from a manual correlation bottleneck due to disparate system query languages.
* obs-mcp enables AI agents to automate data correlation across metrics, logs, and traces using natural language.
* obs-mcp provides toolsets for Metrics (querying Prometheus-compatible endpoints), Traces (interacting with Grafana Tempo for TraceQL), Logs (leveraging Grafana Loki), and OpenTelemetry Collector configuration assistance.
* The metrics tool requires an initial discovery step to find metrics and labelsets before querying.
* obs-mcp enforces guardrails, such as analyzing metric cardinality via Thanos status endpoints, to prevent harmful queries.
* The architecture is Go-native, embedded in the MCP server for OpenShift, offering high performance.
* The system includes a stateless mode for horizontal scaling.
* Strategic outcomes include reducing Mean Time to Recovery (MTTR) in incident triage, democratizing access to query languages, and enabling natural language debugging.
Executive Summary
The Model Context Protocol (MCP) provides a framework for granting large language models access to diverse data sources, aiming to enable data-driven reasoning. Within Red Hat OpenShift environments, MCP acts as a standardized bridge connecting LLMs and complex data layers. The obs-mcp component integrates into MCP server for OpenShift, addressing the manual correlation bottleneck in observability workflows by allowing AI agents to automate the stitching of disparate telemetry.
The obs-mcp toolset is engineered to guide LLMs to query observability data like an experienced Site Reliability Engineer (SRE), prioritizing precision over raw data dumps. It provides specific tools for accessing metrics, traces (via Grafana Tempo and TraceQL), logs (via Grafana Loki, in development), and OpenTelemetry Collector configuration assistance. This approach enforces a discovery-first model for metrics and employs guardrails to prevent LLMs from causing instability by limiting metric cardinality queries or broad pattern matching.
The architecture of obs-mcp is Go-native, embedded directly into the MCP server for Red Hat OpenShift, ensuring high performance and low latency through direct interaction with Kubernetes APIs. This setup includes a stateless mode for horizontal scalability and uses established monitoring systems like Prometheus and Thanos to provide global views while maintaining access tailored to dynamic cluster environments. The ultimate goal is to shift human operators from data correlation to high-level decision-making by providing pre-correlated context for incident triage, telemetry exploration, and rapid deployment.
Full Take
The central tension in the presentation lies between the promise of expansive AI reasoning capabilities and the necessity of operational integrity within complex systems. The argument is that without strict constraints, giving LLMs access to massive observability data risks overwhelming them, leading to inefficient or dangerous actions against production infrastructure. The solution proposed by obs-mcp addresses this by enforcing an SRE-like methodology: precision, hypothesis testing, and respecting platform boundaries.
The mechanism for achieving this—guardrails based on structural analysis (like metric cardinality checks) rather than mere textual filtering—suggests a necessary evolution in how AI interacts with infrastructure data. The system learns through failure feedback, which is critical. If an agent attempts to perform a sweeping operation, the system rejects it based on pre-defined platform constraints, forcing the model to adopt a more constrained, localized investigative approach. This moves the LLM from being a passive data parser to an active, constrained operator.
The implication for human agency is a shift in cognitive labor: moving from the tedious, manual process of stitching signals to supervising AI agents that execute highly specific, safe investigative steps. The pattern detected suggests a resistance to unconstrained LLM access in sensitive domains. Any attempt to bypass these guardrails by simply increasing data scope runs contrary to the core design philosophy, suggesting an inherent societal and operational need for safety mechanisms when deploying advanced automation near critical systems.
Bridge Questions: If the guardrails are effective at teaching agents restraint, how can the community define dynamic, context-aware guardrail policies that adapt based on the specific criticality and configuration drift of a particular OpenShift environment? What governance structures are required to ensure that the definitions of "safe" operational boundaries remain consistent across evolving cloud-native standards like OpenTelemetry? How does this structured approach facilitate trust when agents must make critical decisions based on incomplete or ambiguous context?
Sentinel — Human
This text reads like a piece of technical exposition, successfully linking complex observability tooling with AI reasoning via a newly defined protocol. It exhibits high internal coherence and domain-specific fluency, suggesting genuine subject matter insight.