Retrieves the most recent deployments across all services, or filtered by a specific service name. Use this tool first during incident investigation to check whether any recent deployment correlates with an observed symptom. Each result includes service name, version, commit SHA, deployment time, and who triggered the deploy.

Retrieves error logs for a specific service within a time window. Use this to identify error messages, stack traces, and patterns after a symptom is observed. Filter by log level to focus on ERROR/FATAL entries during an incident. The "since_minutes" parameter looks back N minutes from the current simulation time (14:06 UTC).

Retrieves time-series performance metrics for a specific service: latency (ms), error rate (0–1), CPU usage (0–1), memory usage (0–1), and requests per second. Use this to identify performance degradation trends and correlate them with deployments or incidents. Look for sudden spikes in error_rate or latency_ms following a deployment.

Checks the current Kubernetes pod/container status for a service. Returns desired vs ready replica counts, restart count, pod phase (Running, CrashLoopBackOff, etc.). A pod_phase of "CrashLoopBackOff" combined with high restarts is a strong indicator of a bad deploy. Use this alongside get_service_metrics to assess service health during an incident.

Performs automated root cause correlation for a service exhibiting a given symptom. Internally cross-references recent deployments, error logs, and service metrics to produce a structured hypothesis: {likely_cause, confidence (0–1), evidence[]}. This is the primary reasoning tool — call it after collecting data with get_recent_deployments, get_service_logs, and get_service_metrics. Confidence above 0.7 suggests high certainty.

Submits a rollback request for a service to a target version. IMPORTANT: This tool does NOT immediately execute the rollback. It returns a pending_approval object with a rollback_id that must be reviewed and approved by a human operator before any deployment action is taken. Call analyze_root_cause first to confirm the target version is safe to roll back to. Required fields: service name and target_version (e.g., "v2.4.0").

Creates a new incident ticket and appends it to the in-memory incident registry. Use this when a new issue is detected that warrants formal tracking. Returns the generated ticket ID and the full incident object. IMPORTANT: This tool appends a new record — calling it twice creates two tickets. Check for existing incidents with the incident://current resource before creating a new one.

Appends a timeline entry to an existing incident record. Use this to log investigation findings, actions taken, or status changes during an ongoing incident. Requires a valid incident_id (e.g., "INC-2026-0042"). The message will be timestamped and attributed to "incident-commander-mcp".