MCP server for Zabbix management exposing tools that interact with the Zabbix API for monitoring hosts, templates, triggers, items, problems, events, users, proxies, maintenance periods, and more.
Zabbix MCP server demonstrates good definition quality with consistent naming patterns, detailed parameter descriptions, and proper schema definitions. All 6 tools follow verb_noun naming conventions (api_version, action_get, maintenance_get, maintenance_create, configuration_export, configuration_import). Descriptions are substantive (150-350 chars on average) and explain WHAT the tool does, WHEN to use it, and what it returns. Parameters include type definitions and descriptions. However, there are gaps in output schema documentation, no error handling guidance in tool descriptions, and some parameter constraints could be more explicit (e.g., enum values for format_type in configuration tools).
Get actions from Zabbix. Actions define automated responses to problems/triggers. They specify what happens when problems occur - sending notifications, executing remote commands, etc.
Get Zabbix API version information. This tool retrieves the current version of the Zabbix API you are connecting to. This is useful for understanding API capabilities and ensuring compatibility with specific features that may be version-dependent.
Export Zabbix configurations. Exports monitored hosts, templates, and their complete configurations to JSON, XML, or YAML format. Useful for backup, migration, disaster recovery, or sharing configurations. When you export templates or hosts, the export includes: - All associated items (metrics/data sources) - All triggers and their dependencies - Discovery rules and prototypes - Graphs and visualizations - Macros and variable definitions - Host groups and interfaces (for hosts) - Inventory data (for hosts) - And all other configuration elements
Import configurations into Zabbix. Imports hosts, templates, and other configurations from JSON, XML or YAML. Useful for migration, cloning, or restoring configurations.
Output schemas not documented. Tool descriptions explain inputs but do not describe the structure of returned data. LLMs cannot plan downstream tool calls or field extraction without knowing response shape.
No error handling guidance in tool descriptions. Tools do not explain what errors might occur, whether they are retryable, or how to recover. E.g., configuration_import does not explain what happens if import validation fails or if object conflicts occur.
format_type parameter in configuration tools lacks enum constraint. Parameter description says 'json, xml, or yaml' but these are not formalized as an enum, leaving room for hallucinated values like 'JSON' or 'yml'.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 72 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Create a new maintenance period in Zabbix. Schedules a maintenance window when monitoring alerts are suppressed. Useful for planned upgrades, patching, or system maintenance without triggering false alarms.
Get maintenance periods from Zabbix. Maintenance windows define periods when monitoring is paused for planned upgrades, maintenance, or testing. Alerts are suppressed during maintenance periods.
Pagination guidance incomplete. action_get and maintenance_get accept limit/offset but description does not explain the total count or 'has_more' return field strategy. LLMs cannot reliably iterate through large result sets.
configuration_import 'rules' parameter documentation is dense and assumes API knowledge. Description mentions 'default of createMissing + updateExisting' but does not provide examples or clear guidance on when an LLM should include this vs omit it.
maintenance_create timeperiods parameter is complex. Description explains Zabbix's timeperiod_type enums and fields, but does not clarify the common case (one-off maintenance from X to Y) vs recurring patterns. LLMs will struggle to construct valid timeperiod objects without examples.