Diagnose
What are the Diagnose tools for?
Nine read-only MCP tools cover Kubernetes and service troubleshooting: pod logs, cluster events, live provider metrics, manifests and deploy history. All sit at tier 0. The `diagnose_service` tool is the one-call triage entry point that assembles the other eight into a single answer.
Tools
| Tool | Access | Purpose |
|---|---|---|
diagnose_service | read | Diagnose an unhealthy Service in ONE call — start here instead of stitching four tools together |
get_k8s_manifest | read | Get the raw Kubernetes manifest (the full object as JSON) for one object |
get_k8s_resource | read | Get the live detail of one Kubernetes object (the structured view) |
get_live_metrics | read | Get current CPU/memory/network utilization for ONE resource, fetched on demand from the cloud provider right now |
get_pod_logs | read | Get recent stdout/stderr log lines from ONE pod container |
get_resource_metrics | read | Get CPU, memory, disk, and network utilization metrics for resources |
get_service_events | read | Get the deploy event history for one Service — the durable record of what was deployed, when, and why it failed |
list_k8s_events | read | List recent Kubernetes Events for a cluster — the warnings that explain failures |
list_k8s_resources | read | List live Kubernetes objects of one kind in a cluster |
Start with diagnose_service
diagnose_service exists so an assistant does not have to guess which of the other eight tools
to call. Given an unhealthy service it assembles the triage picture in one call:
recent events, pod state, logs, recent deploys. Reach for the specific tools when you already know what you
are looking for.
The specific tools
- Logs and events:
get_pod_logs,list_k8s_events,get_service_events(deploy history rather than cluster events) - State:
list_k8s_resources,get_k8s_resource,get_k8s_manifest - Metrics:
get_resource_metricsreads the stored series;get_live_metricsfetches on-demand from the provider
Stored metrics versus live metrics
The distinction matters when diagnosing. get_resource_metrics returns what ZopNight has
already ingested, which is fast and enough for trend questions. get_live_metrics calls the cloud
provider directly, which is slower but current, and is what you want when the question is “is
it happening right now”.
An assistant that reaches for stored metrics during an active incident can report a problem as resolved while it is still ongoing.
Read-only, including during an incident
Every tool here is tier 0. Diagnosis never requires write access. The tools that would fix
something (restart_k8s_workload, update_k8s_manifest, delete_k8s_resource) live in
operate at tier 3, deliberately separated so an org can let assistants investigate freely
while keeping remediation gated.
What it cannot do
Nothing here writes. An assistant can read every log line and manifest in a cluster and still
not restart a pod, because the fix belongs to operate at tier 3. If a diagnosis ends in “you
should restart this”, that is the tool boundary working as intended.
Diagnose tools: common questions
Can an assistant restart a pod after diagnosing it?
No. All nine tools here are tier 0. restart_k8s_workload, update_k8s_manifest and delete_k8s_resource sit in operate at tier 3, so a diagnosis that ends in "you should restart this" is the tool boundary doing its job.
Which tool should start a triage?
diagnose_service. Given an unhealthy service it assembles recent events, pod state, logs and recent deploys in one call, so an assistant does not have to guess which of the other eight to reach for.
Stored metrics or live metrics during an incident?
get_live_metrics, which calls the cloud provider directly: slower, but current. get_resource_metrics returns what ZopNight has already ingested, which is fine for trends and can report an ongoing problem as resolved.