SRE Agent MCP Server

Table of Contents

• The Problem
• What SRE Agent Does
• Demo
• Architecture & System Design
• Project Structure
• Workers
• MCP Interface
• Dataset Scenarios
• Setup Instructions
• Environment Variables
• Running the Server
• Connecting from an MCP Client
• Example Queries
• Testing
• Troubleshooting
• Mandatory Features Implemented
• Custom Features Implemented
• Contributing
• License

The Problem

Production incident response is one of the most high-pressure, time-sensitive activities in software engineering. When a service goes down at 3 AM, an on-call Site Reliability Engineer (SRE) is paged and must answer a cascade of questions under extreme time pressure:

• What is actually broken? Is it a single endpoint, an entire service, or a cascading failure across multiple systems?
• What changed? Was there a recent deployment, a configuration change, or an infrastructure event that correlates with the start of the incident?
• Where is the evidence? Logs, metrics, and traces are scattered across different observability platforms. The engineer must query each one individually, mentally correlate timestamps, and piece together a timeline.
• What does the runbook say? Most teams maintain runbooks for known failure modes, but finding the right runbook and following its steps while simultaneously investigating is cognitively demanding.
• What is the fix? Once the root cause is identified, the engineer must decide on remediation: rollback a deployment, scale infrastructure, toggle a feature flag, or apply a hotfix. Each option carries risk.

This process is slow, error-prone, and mentally exhausting. Studies show that Mean Time to Resolution (MTTR) for production incidents averages 1-4 hours across the industry, with a significant portion of that time spent on the investigation phase rather than the actual fix. During an outage, every minute costs money: lost revenue, SLA violations, customer churn, and engineering productivity drain.

The core challenge is that incident triage is fundamentally a multi-step reasoning task that requires gathering evidence from multiple sources, forming hypotheses, testing them against data, and arriving at a root cause. Today, this reasoning happens entirely in the engineer's head, with no structured framework to guide the investigation or prevent cognitive shortcuts that lead to wrong conclusions.

Why Existing Tools Fall Short

Current incident response tooling addresses individual pieces of the puzzle but not the investigation workflow itself:

• Observability platforms (Datadog, Grafana, New Relic) are excellent at storing and visualizing data, but they don't reason about what the data means or guide investigation.
• Alerting systems (PagerDuty, OpsGenie) notify the right person, but provide no investigation support beyond the initial alert context.
• Runbook tools (Confluence, Notion) store institutional knowledge, but there's no automated way to match symptoms to the right runbook or verify that its steps are being followed.
• ChatOps bots (custom Slack bots) can query individual data sources, but lack the ability to plan a structured investigation or synthesize findings across sources.

What's missing is an intelligent orchestration layer that can

... View full README on GitHub