Explain whether an event produced a notification, and what stood in the way.

Walks the whole chain: suppression, delivery attempts and their errors, trigger actions, media types, and each recipient's media severity filter and active period. Any one of those links can drop a notification without recording an error anywhere.

Use when the user asks why an alert did or did not arrive, or why a notification was missing. For the problem itself call zabbix_problem; to turn a pasted notification into identifiers call zabbix_resolve first.

Call a Zabbix API method directly.

Read methods run immediately. Write methods produce a plan and go through approval like every other change. A method that is not in the risk registry is refused rather than guessed at. Over MCP this tool is read-only.

Use when no high-level tool covers the question and a read method such as host.get is required. For problems, hosts, metrics or alert delivery call the matching zabbix tool instead. A write through this tool is refused; to make one, call zabbix_write, or zabbix_plan_create to show the operator the change first.

Collect a diagnostic snapshot of one host in a single call.

Gathers host state, active problems, recent events, silent and unsupported items and maintenance windows. It reports facts and draws no conclusions; interpreting them is the caller's job.

Use when the user asks what is wrong with a named host or wants one diagnostic pass instead of several queries. For a short status line call zabbix_host_status; for hosts Zabbix cannot poll at all call zabbix_unreachable.

Summarise one host: availability, active problems, data freshness, maintenance.

An aggregate over several API calls, returned as a handful of fields rather than several thousand characters of configuration.

Use when the user wants a short health check of one named host: whether it is up, whether it has problems, whether data is fresh. For the full diagnostic bundle call zabbix_host_investigate; to search by a name fragment call zabbix_hosts.

Find hosts by name fragment, pattern or group.

Matching is a case-insensitive substring over both the technical and the visible name, and exact matches are listed first. Guessing exact names is the most common way a query comes back empty.

Use when the user is looking for a host and does not have its exact name, or wants the hosts in a group. For a short health check of one host call zabbix_host_status; for a full diagnostic snapshot call zabbix_host_investigate.

List maintenance windows, including expired ones.

Expired windows are shown by default: removing one that has already lapsed is a routine follow-up, and it cannot be done if the window is invisible.

Use when the user asks which maintenance windows exist, which hosts are silenced, or whether a window has expired. To open, extend, end or remove a window, call zabbix_write, or zabbix_plan_create to show the operator the change first.

Read an item's values over a time window, with min, max and average.

Windows are written the way operators write them: 30m, 2h, 24h, 7d.

Use when the user asks how a metric behaved over a period, or wants its minimum, average and maximum. For only the newest value call zabbix_metrics_latest; for whether the host itself is unreachable call zabbix_unreachable.

Show the newest value of a host's items.

Values come from history, because item.lastvalue has returned a constant zero for several releases. The history type is derived from each item automatically; querying it wrongly returns nothing rather than an error.

Use when the user wants the current value of an item, such as CPU, disk or a custom metric, on one host. For values across a time window call zabbix_metrics_history; for a host whose items stopped sending data call zabbix_host_investigate.

Describe a change to Zabbix without making it. Use when the user wants to see what a change would do before anything is written. Call zabbix_write instead when the user wants the change applied now; call zabbix_plan_status to check a plan that already exists.

Returns a plan identifier and the exact command the operator must run to apply it. Nothing changes until it is applied. Use this to show the operator what a change would do; call zabbix_write to make one, or relay the approve command so the operator applies this exact plan.

Available operations: api.call — Call a Zabbix API method directly. events.acknowledge — Acknowledge an event, comment on it, close it or change its severity. maintenance.create — Open a maintenance window over hosts or host groups. maintenance.delete — Remove a maintenance window permanently. maintenance.expire — End a maintenance window now, keeping its record. maintenance.extend — Push a maintenance window's end further out. triggers.disable — Disable a trigger so it stops raising problems. triggers.enable — Re-enable a disabled trigger.

Check whether a stored plan is still waiting, was applied, or has expired. Use when the user asks what happened to a change they were asked to approve, or after zabbix_plan_create while you wait. Call zabbix_plan_create to describe a new change, and call zabbix_write when the user wants that change made now.

Show one active problem by event identifier.

Use when the user gives one event identifier and wants that problem's host, severity and state. For the list of what is broken now call zabbix_problems; to learn why its notification did or did not arrive call zabbix_alert_why.

List active Zabbix problems, newest first.

Suppressed problems are included by default and say which maintenance window hides them. Hiding them silently is how an outage goes unnoticed for weeks.

Use when the user asks what is broken right now, which problems are firing, or whether anything is in alarm. For one event identifier call zabbix_problem; to learn why a notification never arrived call zabbix_alert_why.

Turn the text of a notification into event, host and trigger identifiers.

Accepts a notification pasted out of a chat client. Without it, an instruction such as "acknowledge that one" cannot be acted on, because the identifiers only exist inside the message text.

Use when the user pastes a notification from chat and the event, host or trigger identifier is buried in that text. Once you have the event identifier, call zabbix_problem for the problem or zabbix_alert_why for the delivery chain.

List monitored hosts Zabbix currently cannot poll.

Availability lives on the interface: host.available was removed in 5.4, and code still reading it sees nothing at all.

Use when the user asks which hosts Zabbix cannot poll, or which agent, SNMP, IPMI or JMX interfaces are down. A host whose interface is up but whose items went silent is not listed here: call zabbix_host_investigate for that, and zabbix_metrics_latest for the newest values.

Change Zabbix in one call and record it in the audit log. Use when the user wants a permitted change applied now rather than only described. To show the operator the change before anything is written, call zabbix_plan_create instead; to check a plan that already exists, call zabbix_plan_status.

Prefer the narrowest operation that does the job and say plainly what you did. Operations marked destructive remove something Zabbix cannot restore on its own.

Available operations: api.call — Call a Zabbix API method directly. events.acknowledge — Acknowledge an event, comment on it, close it or change its severity. maintenance.create — Open a maintenance window over hosts or host groups. maintenance.delete — Remove a maintenance window permanently. (destructive) maintenance.expire — End a maintenance window now, keeping its record. maintenance.extend — Push a maintenance window's end further out. triggers.disable — Disable a trigger so it stops raising problems. (destructive) triggers.enable — Re-enable a disabled trigger.