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_metricstool 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.
