PodWatcher MCP Server: Kubernetes Incident Triage for AI Agents

PodWatcher MCP Server exposes live Kubernetes incident data to AI agents over the Model Context Protocol. It is built for platform teams, SREs and managed service providers who want an agent to answer operational questions about a cluster reliably: what is broken, in which namespace, since when, and whether it is getting worse.

The difference is the quality of what the agent receives. PodWatcher has already classified, deduplicated and ranked the incidents server-side, so the agent is handed a short list of what actually needs action, not raw logs it must parse for itself.

PRE-TRIAGED DATA, NOT RAW CLUSTER NOISE

Incidents arrive classified by container exit code and Kubernetes condition rather than by keyword matching. P1 covers CrashLoopBackOff, OOMKilled, SIGSEGV, SIGILL, ImagePullBackOff, ErrImagePull, Evicted, Node NotReady and exceeded Job backoff limits. P2 covers CPU throttling, memory pressure, CoreDNS degradation, HPA scale ceilings and workload availability breaches. Because the ranking is done in the cluster, an agent spends its context on the three things that matter instead of several hundred objects that do not.

NOISE SUPPRESSION THAT HAS BEEN MEASURED

A per workload cooldown of 300 seconds suppresses duplicate reports of the same crash loop, and is bypassed immediately when the exit code changes because that indicates a new failure rather than a repeat. Multi pod P2 events are batched into a single item, and application level noise is muted while an infrastructure event is in progress. In a load test on Amazon EKS, PodWatcher absorbed 120 simultaneous crash events across three waves over a 20 minute window while staying at 87Mi of its 512Mi memory limit, with no memory growth, no restarts and no watch stream errors. Deduplication reduced those 120 events to a small batch.

FOUR TOOLS WITH DECLARED SCHEMAS

check_readiness confirms PodWatcher has established its Kubernetes API watch loop, and distinguishes an unreachable instance from one that timed out, so an agent never reasons over absent data.

get_incidents returns open and recently resolved incidents as structured JSON carrying reason, restart count, namespace, workload, pod, node and event timestamp. Filter by priority for immediate action items, or by namespace to scope a single application or migration wave.

get_metrics parses the Prometheus endpoint into a key/value dictionary, including podwatcher_alerts_dispatched_total, podwatcher_p1_alerts_dispatched_total, podwatcher_webhook_failures_total, podwatcher_alert_queue_depth and podwatcher_leader_election_is_leader.

get_entitlement_status reports the AWS Marketplace entitlement state for PodWatcher on the cluster as ACTIVE, NOT_SUBSCRIBED, TRIAL_LIMIT_REACHED or UNAVAILABLE.

SIGNALS FOR AI AND INFERENCE WORKLOADS

PodWatcher discovers inference engines automatically by image pattern, including vLLM, Triton Inference Server, Text Generation Inference, Ray and KServe, with no labels or annotations required. It exposes time to first token, token throughput, success rate and discovered workload counts, so an agent can monitor the health of the AI workloads running alongside standard applications.

POST MIGRATION STABILIZATION

Incident volume peaks in the period just after a workload lands on Kubernetes, and an unattended crash loop can turn a completed cutover into a rollback. Namespace filtering scopes triage to the wave currently in flight, priority filtering surfaces only what needs action now, and the Prometheus counters give a quantitative view of whether the cluster is stabilising. That is evidence a migration exit criterion can actually be written against.

SECURITY AND ACCESS MODEL

Access is read-only. The server issues no writes to the Kubernetes API and holds no cluster credentials of its own. It reads podwatcher over cluster-internal HTTP, by default targeting service address podwatcher-svc:8080, which is not exposed outside the cluster. Every tool returns a readable error object on failure rather than raising. Responses are produced on request rather than streamed. The server is deployed as a Helm chart into the same namespace as podwatcher with its own ServiceAccount. Any MCP-compliant client can connect.

REQUIREMENTS

This MCP server is free. It requires a running PodWatcher deployment in the target cluster, reachable over cluster-internal HTTP. PodWatcher runs on Amazon EKS, AKS, GKE, GKE and on-premises clusters, and is available separately on AWS Marketplace.