List ArgoCD applications with their health and sync status. Use this first to discover the application name to pass to get_live_diff or get_argocd_app_status when you don't already know it.

Get an ArgoCD application's health, sync status, last sync operation result, error conditions, and which managed resources are unhealthy or out-of-sync. Good starting point before drilling into get_live_diff or the underlying pods.

Compare an ArgoCD application's desired (git) state against what is actually running in the cluster, resource by resource. Reports drift as added/removed/changed spec fields, ignoring routine status/metadata noise (resourceVersion, managedFields, status subresource, etc). This is the tool for "did someone kubectl edit/patch something out-of-band" or "is the live pod spec what git says it should be".

List pods (optionally scoped by namespace, a raw label selector, and/or an ArgoCD app name — matched via the standard "app.kubernetes.io/instance" tracking label). Surfaces phase, restart counts, and the reason for any waiting/terminated container (CrashLoopBackOff, ImagePullBackOff, OOMKilled, etc) so unhealthy pods are visible at a glance.

Fetch recent logs for a pod (optionally a specific container). Set previous=True to get the logs of the last crashed instance of the container, which is usually what you want after a CrashLoopBackOff.

Run "kubectl describe" on any resource (pod, deployment, replicaset, service, ...) and return the raw text, including its event tail — useful for scheduling failures, probe failures, and admission errors that don't show up in get_events' short-lived event history.

Page through Kubernetes events in chronological order (oldest first). Pass involved_object to filter to events mentioning a pod/deployment/etc by name (substring match). Pass the next_cursor value returned by a previous call to continue from where you left off — useful for walking the event timeline around an incident without re-fetching everything.

Run a shell command inside a pod (or one of its containers, including an ephemeral debug container previously created with spawn_ephemeral_debug_container) and return its combined output. This is how you actually use a spawned debug container once it's running.

Attach an ephemeral debug container to a running pod via "kubectl debug" (e.g. to get a shell with tools a distroless/minimal app image lacks). The container sleeps for duration_seconds so it stays available; use exec_in_pod with the returned container name to run diagnostics against it (or against target_container's process namespace if target_container is set). Note: this mutates the live pod spec and the ephemeral container cannot be removed short of restarting the pod.

Look up Dynatrace entity IDs by (partial) display name, optionally filtered by type (e.g. "CLOUD_APPLICATION", "KUBERNETES_CLUSTER", "PROCESS_GROUP_INSTANCE"). Use this to bridge a Kubernetes pod/workload name to the Dynatrace entity ID that correlate_trace needs.

Given a Dynatrace entity ID (see find_dynatrace_entity), report its identity/tags plus any problems (with root cause and evidence) detected against it within the given timeframe (Dynatrace relative timeframe syntax, e.g. "now-2h", "now-1d"). This is the tool for "does the unhealthy deployment line up with a known Dynatrace problem".