Zabbix API MCP

Report server version, Zabbix connectivity, and configured categories. Call this at session start (or after a tool-call timeout) to confirm the MCP is up, see which version is running, verify the Zabbix backend is reachable and authenticated, and list the daily_brief categories that are loaded. Lightweight: it authenticates once (reusing the cached session) and reads the detected API version — it does NOT scan problems or items. Always returns the same keys: ``status`` (healthy / degraded / error), ``service``, ``version``, ``zabbix_url``, ``zabbix_api_version`` (None until a backend connection succeeds), ``auth`` (ok / error / missing-env), and ``categories`` (the configured daily_brief section names). On a degraded or error result, ``detail`` carries the reason and ``categories_error`` the category-parse failure (when that is the cause).

Morning patrol summary. Reports active problems (Warning and above), hosts currently in maintenance, then one section per category configured via ZABBIX_CATEGORIES_INI (e.g. DHCP pool usage, SNAT session usage, core-network problems). Item-based categories show current values sorted high-to-low; problem-based categories list active problems. Problems are listed newest-first with their age; those older than the recent window (ZABBIX_BRIEF_RECENT_HOURS, default 24h) are folded to a count so a long-standing backlog of un-recovered fossils doesn't bury today's events. Section headers show the true total ('showing N of TOTAL' when capped). The "## In Maintenance" section lists windows that are active now, plus windows starting later today -- cross-check these hosts before treating another tool's alert about them as a new incident. No section means no host is currently (or about to be, today) under a registered maintenance window; see get_maintenance_windows for the full picture including tomorrow-or-later and expired windows.

Get active Zabbix problems, newest first. Problems are listed newest-first and annotated with their age. The header shows the true total ('showing N of TOTAL' when the result is capped by `limit`), so a capped listing is never mistaken for the full picture. Args: min_severity: Minimum severity (0=Not classified, 1=Info, 2=Warning, 3=Average, 4=High, 5=Disaster) tag_name: Filter by tag name (optional) tag_value: Filter by tag value (optional, requires tag_name) limit: Maximum number of problems to return (floored at 1; when the result hits this cap a second count query is issued to report the true total)

List Zabbix hosts filtered by tag or group. Args: role: Filter by role tag value (e.g. 'main', 'edge') tag_name: Filter by arbitrary tag name tag_value: Filter by tag value (requires tag_name) group: Filter by host group name

Get current item values for a host. Args: host: Hostname (exact match) search: Filter items by name (partial match)

Acknowledge Zabbix problems and add a message (does not close them). Args: event_ids: Comma-separated event IDs (from get_problems output) message: Acknowledgement message

Create a Zabbix maintenance window, selecting hosts by location tag OR by explicit host name (exactly one of the two -- not both, not neither). Unlike acknowledge_problem (which only marks existing problems as seen), this suppresses NEW problem notifications for the matched hosts during the window. IMPORTANT -- idempotency key is `name` + `since` (not the target): the two selection modes (location vs. hosts) can't collide with each other, but within the SAME mode, calling again with the same name/since always returns the FIRST window created under that name/since, even if this call's location/hosts is different. A second call with a different target but a name/since that collides with an earlier one (same mode) silently protects nothing for the new target (no error, no window created for it) -- pick a `name` that uniquely identifies the actual target whenever more than one maintenance might be open around the same time (shigechika/zapi-mcp#59). IMPORTANT -- since/till are naive local-server-time strings: parsed and converted via the MCP server process's own timezone, not a fixed zone. If the server doesn't run in the timezone you mean, convert first. Args: since: Window start, "%Y/%m/%d %H:%M:%S" (e.g. "2026/08/10 11:00:00"), interpreted in the MCP server process's local timezone till: Window end, "%Y/%m/%d %H:%M:%S", same timezone caveat as since name: Maintenance window name prefix (the start time is appended). Also the idempotency key together with since -- see above description: Free-text reason, shown in the Zabbix UI location: Value of the hosts' "location" tag to match (e.g. "CIT"). Mutually exclusive with hosts. hosts: Comma-separated exact host (technical) names, for when the affected hosts don't share a location tag or precise host-level control is wanted. No per-port selection. Mutually exclusive with location.

List Zabbix maintenance windows -- the read counterpart to set_maintenance. Use this to cross-check anomalies reported by OTHER tools (e.g. device unreachability, AP-offline reports) before treating them as new incidents: a host in an Active window is one Zabbix is currently suppressing new problem notifications for, because someone (or set_maintenance) registered a planned outage covering it. Windows are grouped Active / Upcoming (and Expired when requested). "Active" means the current time falls inside the window's own time period, not just its outer active_since/active_till frame -- exact for a one-time window (the kind set_maintenance/set_maintenance_for_hosts create). A window with a recurring time period (set up outside this server) is instead evaluated against its outer frame only and labeled "(recurring)", since precise recurrence evaluation isn't implemented. Times are the MCP server process's local timezone (same caveat as set_maintenance's since/till). Args: include_expired: Also list windows whose active_till has passed (default False -- set_maintenance never deletes windows, so expired ones accumulate over time and are noise by default).