Source-linked AI summary
ARGUS: MCP-Grounded Root Cause Analysis for Kubernetes Incidents
Ergi Senja, Seyed Mohammad Reza Razavi Zadegan, Philipp Leitner
TL;DR
Kubernetes incident response is fragmented across heterogeneous monitoring signals, while existing LLM-based RCA systems depend on bespoke data-access layers. ARGUS standardises live observability access through read-only MCP servers and evaluates the resulting Slack-based assistant using fault injection, rubric scoring, and practitioner interviews. It identifies the correct root cause in all ten scenarios, but diagnostic reliability and trust exceed those of its recommended fixes.
Problem
Kubernetes incident response requires correlating metrics, logs, container state, and messaging signals across multiple tools, while existing LLM-based RCA systems rely on non-reusable custom data-access layers.
Method
ARGUS connects a commercial LLM to live Kubernetes observability through standardised read-only MCP servers and evaluates it with ten fault-injection scenarios, rubric-based summary scoring, and interviews with six on-call engineers.
Results
ARGUS named the correct root cause in all ten scenarios, while rubric and interview findings placed the principal weaknesses in recommended fixes rather than diagnosis.
Takeaways & Limitations
ARGUS supports a diagnostic-first design principle in which command-proposing capability is treated as a separate, explicitly authorised function.
Takeaways & Limitations
The evaluation is preliminary, uses one organisation, ten configuration-focused scenarios, one commercial LLM, and six interview participants, limiting generalisation.
Abstract
from arXiv · showhide
Kubernetes incident triage requires correlating signals from metrics, logs, container state, and messaging systems across multiple monitoring tools, a fragmented workflow that slows diagnosis and contributes to alert fatigue. Large language models (LLMs) have shown promise for automated root cause analysis (RCA), but existing systems rely on custom, system-specific data access layers that cannot be reused across organisations. We present ARGUS, an MCP-grounded RCA assistant that connects a commercial LLM to live Kubernetes observability data through standardised MCP servers covering Kubernetes state, Prometheus metrics, Loki logs, and NATS messaging, and delivers structured diagnostic summaries inside the Slack incident channel where on-call engineers already work. We conduct a preliminary evaluation of ARGUS using three complementary methods: controlled fault injection across ten Kubernetes incident scenarios, rubric-based scoring of the resulting RCA summaries on three dimensions, and semi-structured interviews with six on-call engineers at an industrial partner. ARGUS named the correct root cause in all ten scenarios with an aggregate MCP success ratio of 0.91. Practitioners trusted the diagnostic output but consistently expressed scepticism toward the recommended fixes. Our central finding is a diagnostic/prescriptive asymmetry: ARGUS reliably identifies what went wrong, but is perceived as less reliable or trustworthy at specifying what to do next. This pattern can be observed across all three evaluation methods, and has important implications for future autonomous agentic incident handling systems.
1 Introduction
ARGUS addresses fragmented Kubernetes incident diagnosis by grounding a commercial LLM in live observability data through standardised MCP servers and delivering structured summaries in Slack. Its preliminary evaluation reports reliable root-cause identification but asymmetric practitioner trust in recommended fixes.
- Motivation: Kubernetes incidents propagate across metrics, logs, container state, and messaging infrastructure, forcing engineers to correlate signals across multiple monitoring tools.This fragmentation increases cognitive overhead and contributes to alert fatigue.
- Motivation: Without live system state, LLMs may confuse the current incident with pre-training patterns and produce plausible but factually incorrect diagnoses.
- Approach: MCP provides a standardised client-server boundary for structured LLM tool access, enabling sanctioned read-only operations and adding data sources without changing agent code or prompts.
- Contribution: ARGUS connects a commercial LLM to live observability data through four read-only MCP servers and delivers structured diagnostic summaries as Slack thread replies.
- Contribution: ARGUS uses MCP as its sole data-access mechanism, requires no model fine-tuning, and can extend to new data sources by deploying additional MCP servers.
- Contribution: The evaluation finds reliable root-cause identification but systematically questioned recommended fixes, motivating separate treatment of diagnostic depth and command-proposing capability.
2 Background & Related Work
ARGUS builds on LLM-based RCA and structured retrieval while targeting the interoperability limits of bespoke data-access pipelines. Its positioning combines MCP access, Kubernetes focus, ChatOps delivery, structured prompting over live evidence, and multi-method evaluation.
- Background: MCP separates an agent’s reasoning from server execution, while read-only server exposure makes unavailable write operations structurally impossible.
- Related Work: Earlier metric-based RCA methods surface candidate service relationships but cannot incorporate unstructured logs and events or produce natural-language explanations.
- Related Work: Existing LLM-based RCA systems use bespoke handlers, deployment-specific procedures, or custom fusion pipelines that require system-specific engineering to extend.
- Related Work: OpenDerisk provides broader multi-agent SRE coverage and production scale, whereas ARGUS focuses on portable Kubernetes RCA in Slack with read-only diagnosis and multi-method evaluation.
- Structured Prompting and Retrieval: ARGUS combines structured diagnostic prompting with retrieval-augmented historical context for RCA over live evidence.
- Positioning: No prior system in the comparison combines standardised MCP access, Kubernetes focus, ChatOps delivery, structured prompting over live evidence, and multi-method evaluation.
3 ARGUS System Design
ARGUS asynchronously processes Slack alerts through a four-stage diagnostic pipeline, grounding an iterative ReAct agent with retrieved context and read-only MCP observability access. Guardrails, evidence-locking, and deterministic confidence labels constrain investigation and reporting.
- Architecture Overview: ARGUS separates a Slack application and AI diagnostic agent with NATS JetStream, allowing alerts to enter a sequential four-stage pipeline.The stages are context retrieval, MCP-based evidence gathering, report generation, and delivery.
- MCP Observability Access: Four read-only MCP servers expose distinct Kubernetes observability layers, while read-only credentials make cluster modification structurally impossible.
- MCP Observability Access: The system supports Kubernetes state inspection, PromQL and LogQL execution through Grafana, and NATS JetStream introspection with credential-bounded account visibility.
- Extensibility: Adding a data source requires deploying an appropriately credentialed MCP server and restarting the agent, without changing agent code or prompt structure.
- Context Retrieval: ARGUS enriches alerts with runbooks, similar historical incidents, and subsystem-specific context files before investigation begins.
- ReAct Loop & Prompt Strategy: The ReAct loop iteratively selects evidence, executes MCP calls, observes results, and continues or submits a report under fixed diagnostic stages and evidence-locking rules.
- Guardrails and Output: Tool budgets, call deduplication, fallback handling, and deterministic confidence rules constrain execution and tie confidence to MCP success and non-MCP corroboration.
4 Evaluation Methodology
The preliminary evaluation combines design-science development with ten controlled Kubernetes fault scenarios, rubric scoring, and interviews with six on-call engineers. It examines evidence retrieval, summary quality, and practitioner perceptions while explicitly limiting claims of generalisability.
- Evaluation Design: ARGUS was developed through three design-science cycles, with the third conducting the summative evaluation reported in the paper.
- Scope: The evaluation is preliminary and limited to one industrial site, a small scenario set, and a small participant group, so it is intended to establish feasibility rather than generalisable performance guarantees.
- Research Questions: The evaluation addresses evidence retrieval, RCA summary correctness, evidence backing, operational usefulness, and engineers’ perceived impact on reaching an actionable hypothesis.
- RQ1: Fault Injection: Ten controlled fault-injection scenarios in a Kubernetes cluster cover pod, workload, autoscaling, scheduled-job, and messaging-related incident types.
- RQ2: Summary Quality: RCA summaries are scored on Correctness, Evidence Backing, and Actionability using a structured rubric.
- RQ3: Practitioner Perception: Six purposively sampled on-call engineers with varied Kubernetes experience, AI-tool familiarity, and seniority evaluated OperatorBrief usefulness, clarity, and impact on time-to-hypothesis.
5 Results
ARGUS consistently identified incident root causes, while evaluation exposed a recurring gap between reliable diagnosis and trustworthy recommended fixes. Interviews further showed that access boundaries, output density, and evidence-quality signalling shaped practitioner trust and use.
- RQ1: Evidence Retrieval: 0.91 aggregate MCP success ratio across ten fault-injection scenarios, with the correct root cause named in all ten.Eight scenarios achieved full expected-evidence coverage; partial coverage arose from RBAC and credential failures.
- RQ1: Evidence Retrieval: The three KubeDeploymentReplicasMismatch scenarios matched distinct injected faults, showing diagnosis depended on retrieved specifications and events rather than alert-name pattern matching.The faults involved an invalid image tag, a failing readiness probe, and an invalid busybox size suffix.
- RQ1: Evidence Retrieval: Seven failed calls reflected infrastructure limits—node RBAC, NATS credential gaps, and an API-group denial—but failures were surfaced and alternative evidence supported diagnosis.The agent recovered the KubeNodeNotReady and NatsMirrorDrift cases through other retrieved signals; the denied StorageClass lookup was incidental.
- RQ2: Summary Quality: 83.3% exact pre-consensus inter-rater agreement and Gwet’s AC1 of 0.81 indicated substantial agreement despite skewed rubric labels.Cohen’s κ was 0.36, while adjudication changed nine cells after domain-expert review.
- RQ2: Summary Quality: The only Not met rubric cells concerned Actionability, whereas no Correctness or Evidence Backing cell received Not met.Failures ranged from vague connection checks to a command targeting the wrong image registry.
- RQ2: Summary Quality: Adjudicator downgrades revealed outputs that appeared correct but were not operationally actionable, exposing a gap between stated correctness and what responders could actually do.Examples included unsupported Vault checks, an incorrect ECR command, and a diagnosis missing a ConfigMap reference.
- RQ3: Practitioner Perception: All six practitioners used the diagnostic core for their first hypothesis, but all questioned Recommended Fixes, supporting a diagnostic/prescriptive asymmetry.Participants preferred read-only operation initially and considered capability expansion only after sustained exposure to correct outputs.
- RQ3: Practitioner Perception: Four interviews linked failures to MCP-access boundaries rather than reasoning defects, with AWS coverage identified as the most valuable extension.An ECR lifecycle policy example showed that incomplete evidence could leave the brief incomplete without making that incompleteness visible.
6 Conclusion
ARGUS grounds a commercial LLM in live Kubernetes observability data through standardised MCP servers and evaluates it with a three-method preliminary study. It identifies root causes reliably, but recommended fixes remain less reliable and trusted, motivating broader coverage, verified prescriptions, and stronger evaluation.
- ARGUS is a Slack-integrated, read-only RCA assistant that grounds a commercial LLM in live Kubernetes observability data through standardised MCP servers.
- 10 scenarios: ARGUS named the correct root cause in all ten, with an aggregate MCP tool success ratio of 0.91.
- ARGUS reliably identifies what went wrong, but its recommended fixes are the least reliable and least trusted part of its output.
- Future work should extend MCP coverage, ground fixes in verified live state, use graduated approval workflows, and replicate the evaluation across runs, settings, organisations, and models.