incident-commander-mcp
# incident-commander-mcp
> **AI-powered incident management MCP server built for the NitroStack Hackathon.**
[](https://nitrostack.ai)
[](https://www.typescriptlang.org)
[](https://modelcontextprotocol.io)
---
## ⚠️ R12 Disclosure — Simulated Integrations
> **All data returned by this MCP server is entirely mocked and stored in-memory.**
>
> There are **NO** real connections to:
> - Kubernetes / container orchestration platforms
> - Grafana / Prometheus / any metrics backend
> - GitHub / GitLab / any version control system
> - PagerDuty / OpsGenie / any alerting system
> - Stripe or any payment processor
>
> This is a **demo** for hackathon evaluation purposes. The realistic-looking data is seeded
> with a purposeful incident scenario (deploy at 14:02 → error spike at 14:03) to demonstrate
> agent reasoning capabilities over MCP tools, resources, and prompts.
---
## Overview
`incident-commander-mcp` is a single MCP server built on the [NitroStack](https://nitrostack.ai) TypeScript framework
(`@nitrostack/core`). It exposes tools, resources, and prompts that enable an AI agent to:
1. **Investigate** production incidents by querying deployment history, error logs, and metrics
2. **Reason** about root causes using cross-correlated data
3. **Act** (with human approval) by requesting rollbacks or creating incident tickets
4. **Document** incidents via structured postmortem prompts
---
## Capabilities
### 🔧 Tools (8)
| Tool | Description | Annotation |
|------|-------------|------------|
| `get_recent_deployments` | Recent deployments, optionally filtered by service | `readOnly` |
| `get_service_logs` | Error logs for a service within a time window | `readOnly` |
| `get_service_metrics` | Latency, error rate, CPU/memory time-series | `readOnly` |
| `check_pod_status` | Kubernetes pod readiness and restart counts | `readOnly` |
| `analyze_root_cause` | Cross-correlates deploy + logs + metrics → hypothesis | `readOnly` |
| `trigger_rollback` | Submits a rollback request (**requires human approval**) | `destructive` |
| `create_incident_ticket` | Creates a new in-memory incident record | — |
| `post_status_update` | Appends a timeline entry to an incident | — |
### 📦 Resources (4)
| URI | Description |
|-----|-------------|
| `incident://current` | Active incident snapshot (JSON) |
| `incident://{id}/timeline` | Timeline for a specific incident |
| `deployments://recent` | Last 20 deployments across all services |
| `service://{name}/health` | Health snapshot for one service |
### 💬 Prompts (3)
| Prompt | Arguments | Description |
|--------|-----------|-------------|
| `root_cause_investigation` | `service`, `symptom` | Guides structured RCA with tool call sequence |
| `postmortem_report` | `incident_id` | Generates a blameless postmortem |
| `rollback_decision` | `service`, `target_version` | Risk/benefit analysis before rollback |
---
## Incident Scenario (Demo)
The seeded data tells a realistic story:
```
14:00 UTC — payment-service healthy: error_rate 0.2%, latency 45ms
14:02 UTC — payment-service v2.4.1 deployed (commit a3f8c21d)
14:03 UTC — Error spike: "Cannot read properties of undefined (reading 'stripeId')"
14:03 UTC — error_rate jumps to 28%, latency spikes to 320ms
14:04 UTC — Pods begin CrashLoopBackOff, 7 restarts
14:05 UTC — error_rate: 91%, latency: 1450ms, API Gateway circuit breaker opens
```
An agent reasoning over `get_recent_deployments` → `get_service_logs` → `get_service_metrics` →
`analyze_root_cause` should produce a hypothesis pointing to `v2.4.1` as the culprit with ~0.90 confidence.
---
## Quick Start
```bash
# 1. Clone / navigate to project
cd incident-commander-mcp
# 2. Install dependencies (already done by CLI)
npm install
# 3. Start development server
npm run dev
```
## Building for Production
```bash
npm run build
npm start
```
Built with [NitroStack](https://nitrostack.ai) ⚡
TDQS
Scored across 8 tools
Each tool targets a distinct data type or action: deployments, logs, metrics, pod health, root cause analysis, rollback, ticket creation, and status updates. There is no overlap in purpose, and the descriptions clarify the unique role of each tool.
All tool names follow a consistent verb_noun pattern with lowercase snake_case: get_recent_deployments, check_pod_status, analyze_root_cause, trigger_rollback, create_incident_ticket, post_status_update, etc. The naming convention is uniform and predictable.
With 8 tools, the server is well-scoped for incident management. It provides a balanced set of investigation, analysis, action, and documentation tools without unnecessary redundancy or overwhelming volume.
The tool set covers the core incident lifecycle: investigate (deployments, logs, metrics, pods), analyze (root cause), act (rollback), and document (create ticket, post updates). A minor gap is the lack of a tool to list or retrieve existing incident details, though the incident://current resource partially addresses this.