zapi-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ZABBIX_URL | Yes | Zabbix base URL (e.g. https://zabbix.example.com); /api_jsonrpc.php is appended if absent | |
| ZABBIX_USER | Yes | Zabbix API user | |
| ZABBIX_PASSWORD | Yes | Zabbix API password | |
| ZABBIX_CATEGORIES_INI | No | Path to a categories INI file for daily_brief (optional) | |
| ZABBIX_BRIEF_RECENT_HOURS | No | daily_brief recent window in hours; problems older than this are folded to a count | 24 |
| ZABBIX_BRIEF_PROBLEM_LIMIT | No | Max active problems daily_brief fetches per call before counting the rest | 1000 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| health_checkA | 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: |
| daily_briefA | 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). Problems whose trigger, host or item is disabled are left out (the Zabbix frontend's Problems page hides them too); the header says how many (get_problems with include_disabled=True lists them). 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_problemsA | 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
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) include_disabled: Also list problems whose trigger, host or item is disabled (default False, matching the Zabbix frontend) |
| get_hostsA | 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_host_itemsB | Get current item values for a host. Args: host: Hostname (exact match) search: Filter items by name (partial match) |
| acknowledge_problemA | 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 |
| set_maintenanceA | 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 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. |
| get_maintenance_windowsA | 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). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 8 tools
Each tool has a clearly distinct role: daily_brief is an aggregated summary, get_problems is a raw problem query, get_hosts and get_host_items target different host data, health_check checks server status, acknowledge_problem and set_maintenance perform distinct actions, and get_maintenance_windows is the read-side counterpart. The descriptions explicitly clarify boundaries (e.g., acknowledge vs. suppress new notifications, daily_brief vs. get_problems). No two tools appear to do the same thing.
Most tools follow a verb_noun pattern (get_hosts, get_problems, acknowledge_problem, get_host_items, get_maintenance_windows, set_maintenance). Two tools (daily_brief, health_check) use noun phrases instead, which is a minor deviation but still readable and consistently snake_case throughout.
Eight tools is well-scoped for a Zabbix monitoring server, covering read operations, a curated summary, health checking, and two targeted write actions without excess. Each tool earns its place and the count avoids feeling either thin or bloated.
The surface covers core monitoring workflows: problem listing and acknowledgement, host and item queries, maintenance window creation and viewing, a daily brief, and a health check. Minor gaps exist—no update/delete for maintenance windows (they only expire), no item history or trend retrieval, and no direct problem-resolution action—but these are either non-standard in Zabbix or workable around.