# Diagnose

> 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.

Source: https://zop.dev/integrations/mcp-server/tools/diagnose
Updated: 2026-08-20

---

## 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.

## 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_metrics` reads the stored series; `get_live_metrics` fetches
  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.