server-healthlisted

# Checking a server's health Two rules first, because getting them wrong wastes a turn: - **Servers are addressed by friendly name only.** Call `list_servers` first; the names it returns are the only valid `serverName` values. A hostname, an IP or an SSH string will not resolve, and you never get to see one. - **Ask before you assume.** `describe_capabilities` says what this session may actually do. Reading it beats discovering a boundary by tripping over it — a denied call is not a call to retry in a different shape. ## Order to work in 1. `list_servers` — get the name. 2. `get_server_metrics` — CPU, memory, disk, uptime, **failed units and listening ports**. This is usually the whole answer. Do not reach for `execute_command` to run `top`, `free` or `df`: the dedicated tool states its intent exactly, so the user's path rules apply precisely instead of being guessed at from a command string, and it is less likely to need an approval prompt. 3. `get_host_facts` — only when the question is what the server *is* rather than how it is doing: distro, arch, virtualisation, pending and security updates, reboot-pending. 4. `get_capacity_trends` — only when the question is about direction ("will it fill up"), not the current number. It forecasts over a window of days and answers in sentences, one per metric. Every number it states carries the window it came from AND how much of that window was sampled: OpsMaxx only collects while it is running, so "fro