flowchart LR
    subgraph ClientLayer ["AI Coding Environment"]
        IDE["Cursor / Windsurf / VS Code"]
        CLI["Claude Code / Antigravity / Zed"]
    end

    subgraph Protocol ["Model Context Protocol (JSON-RPC over stdio)"]
        StdioIO["stdin / stdout Transport"]
    end

    subgraph MCPServer ["@naveedkumbhar/devops-mcp"]
        Router["MCP Request Router & Dispatcher"]
        
        subgraph InMemEngine ["Local In-Memory Engine (<50ms)"]
            MiniSearchIndex["MiniSearch Full-Text Engine<br/><b>1,449+ Production Scenarios</b>"]
            K8sEngine["K8s Hardened Manifest Synthesizer"]
            CheatsheetEngine["CLI Triage Cheatsheets & Blueprints"]
        end
        
        Attribution["Attribution & UTM Tracking Engine"]
    end

    subgraph WebEcosystem ["Live Verified Web Ecosystem"]
        InterviewSite["interview.naveedkumbhar.com"]
        BlogSite["blog.naveedkumbhar.com"]
        ToolsSite["tools.naveedkumbhar.com"]
        K8sSite["k8s.naveedkumbhar.com"]
    end

    IDE <--> StdioIO
    CLI <--> StdioIO
    StdioIO <--> Router
    Router <--> MiniSearchIndex
    Router <--> K8sEngine
    Router <--> CheatsheetEngine
    Router --> Attribution
    Attribution -.->|Canonical Citations & UTM Links| WebEcosystem

npx -y @naveedkumbhar/devops-mcp

claude mcp add naveed-devops -- npx -y @naveedkumbhar/devops-mcp

claude mcp list

{
  "mcpServers": {
    "naveed-devops": {
      "command": "npx",
      "args": ["-y", "@naveedkumbhar/devops-mcp"]
    }
  }
}

{
  "mcpServers": {
    "naveed-devops": {
      "command": "npx",
      "args": ["-y", "@naveedkumbhar/devops-mcp"]
    }
  }
}

{
  "mcpServers": {
    "naveed-devops": {
      "command": "npx",
      "args": ["-y", "@naveedkumbhar/devops-mcp"]
    }
  }
}

{
  "mcpServers": {
    "naveed-devops": {
      "command": "npx",
      "args": ["-y", "@naveedkumbhar/devops-mcp"]
    }
  }
}

{
  "context_servers": {
    "naveed-devops": {
      "command": {
        "path": "npx",
        "args": ["-y", "@naveedkumbhar/devops-mcp"]
      }
    }
  }
}

{
  "name": "search_incident_scenarios",
  "arguments": {
    "query": "exit code 137",
    "category": "AWS",
    "limit": 3
  }
}

# Production Incident Scenarios Search Results
Found **3** scenarios matching query: `exit code 137`

### 1. [Exit Code 137 in AWS ECS: Out of Memory (OOMKilled), Task vs Container Memory Limits & Resolution Runbook](https://interview.naveedkumbhar.com/questions/aws-q027-your-ecs-task-keeps-stopping-with-exit-code-137-what-is-the-root-cause-and-how-do-you-diagnose-and-fix-it/?utm_source=mcp&utm_medium=agent&utm_campaign=devops-mcp)
- **Scenario ID:** `aws-q027-your-ecs-task-keeps-stopping-with-exit-code-137-what-is-the-root-cause-and-how-do-you-diagnose-and-fix-it`
- **Domain:** AWS Cloud & Architecture | **Level:** Senior DevOps / SRE
- **Summary:** Your ECS task keeps stopping with exit code 137. Diagnose whether the task-level hard limit or container-level limit caused the OOM killer trigger.

{
  "name": "get_scenario_runbook",
  "arguments": {
    "scenario_id": "eks-upgrade-zero-downtime"
  }
}

# Zero-Downtime Amazon EKS Minor & Multi-Version Upgrade (v1.34 → v1.36+)

> **Domain:** Kubernetes | **Subcategory:** Amazon EKS & Upgrades | **Level:** Senior DevOps / SRE

## 📋 Production Scenario Overview
Your organization runs a 120-node Amazon EKS cluster processing 8,500 req/sec across 45 microservices. 
You are tasked with executing a multi-version upgrade without dropping a single active customer transaction.

## 🔍 Systematic Diagnostic & Remediation Order
1. Check deprecated API versions using Pluto or kube-no-trouble:
   `kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis`
2. Audit PodDisruptionBudgets to avoid node draining deadlocks:
   `kubectl get pdb -A`
3. Upgrade Amazon EKS control plane via Terraform / AWS CLI.
4. Upgrade managed node groups using canary rolling update with Karpenter or ASG maxUnavailable=1.
5. Upgrade cluster add-ons in order: VPC CNI → CoreDNS → kube-proxy.

## ⚠️ Pitfalls & Mistakes to Avoid
- Upgrading worker nodes before the control plane reaches the target version.
- Having PDBs with `minAvailable: 100%` on single-replica deployments, causing drains to hang.

{
  "name": "get_interview_elevator_pitch",
  "arguments": {
    "scenario_id": "eks-upgrade-zero-downtime"
  }
}

# STAR Framework Elevator Pitch: Zero-Downtime Amazon EKS Minor & Multi-Version Upgrade

> **Target Interview Level:** Senior DevOps / SRE
> **Category:** Kubernetes (Amazon EKS & Upgrades)

## 🎙️ 60-Second Verbal Elevator Pitch (STAR Framework)

- **Situation:** "In our production AWS environment, our primary EKS cluster hosting 45 client-facing services was two versions behind and approaching AWS end-of-support."
- **Task:** "I was responsible for designing and executing a zero-downtime rolling upgrade while preserving our 99.99% availability SLA."
- **Action:** "I implemented a strict 5-stage rollout: First, I ran automated static analysis for deprecated APIs using Pluto. Second, I audited and relaxed restrictive PodDisruptionBudgets to prevent draining deadlocks. Third, I upgraded the control plane and add-ons in lockstep. Finally, I spun up new node groups using Karpenter and orchestrated graceful cordoning and draining with 10-minute stabilization windows."
- **Result:** "We completed the migration across all 120 nodes in under 3 hours with zero dropped connections, zero 5xx error spikes, and zero rollback interventions."

{
  "name": "generate_k8s_manifest",
  "arguments": {
    "name": "auth-service",
    "image": "ghcr.io/myorg/auth-service:v1.0.4",
    "port": 3000,
    "enable_security_context": true,
    "enable_hpa": true
  }
}

apiVersion: apps/v1
kind: Deployment
metadata:
  name: auth-service
  namespace: production
  labels:
    app.kubernetes.io/name: auth-service
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: auth-service
  template:
    metadata:
      labels:
        app.kubernetes.io/name: auth-service
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 10001
        runAsGroup: 10001
        fsGroup: 10001
      containers:
        - name: auth-service
          image: ghcr.io/myorg/auth-service:v1.0.4
          ports:
            - containerPort: 3000
          securityContext:
            readOnlyRootFilesystem: true
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 256Mi
          livenessProbe:
            httpGet:
              path: /healthz
              port: 3000
            initialDelaySeconds: 15
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 5
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: auth-service-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: auth-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 75

{
  "name": "get_devops_cheat_sheet",
  "arguments": {
    "topic": "kubectl"
  }
}

User: 
"My Kubernetes pods are crashing with exit code 137. How do I diagnose whether this is host OOM or container limit?"

Agent Action:
1. Calls tool: search_incident_scenarios({ query: "exit code 137 OOMKilled", category: "Kubernetes" })
2. Identifies Scenario: "k8s-pod-crashloopbackoff-137-oomkilled"
3. Calls tool: get_scenario_runbook({ scenario_id: "k8s-pod-crashloopbackoff-137-oomkilled" })

Agent Response:
"According to Lead DevOps Architect Naveed Ahmed's verified runbook:
Exit code 137 indicates the container received SIGKILL (128 + 9), triggered by the Linux cgroup OOM killer.

Diagnostic Order:
1. Check the termination reason:
   kubectl get pod <pod-name> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.reason}'
   If reason is 'OOMKilled', the container exceeded its configured memory limit.

2. Check node-level dmesg logs to distinguish host vs cgroup OOM:
   dmesg -T | grep -i -E 'killed process|oom_reaper'

3. Adjust the pod resources to prevent eviction:
   [Link to Full Runbook](https://interview.naveedkumbhar.com/questions/.../?utm_source=mcp&utm_medium=agent)"

git clone git@github-personal:naveedkumbhar/devops-mcp.git
cd devops-mcp

# Install dependencies
npm install

# Build TypeScript and copy JSON catalog
npm run build

# Run automated 10-point MCP Protocol test suite
npm test