Loading ToolBench
MCP server for Zabbix monitoring: hosts, problems, triggers, events, items, and acknowledgements
Zabbix MCP demonstrates solid tool design with consistent naming (verb_noun pattern), comprehensive parameter schemas, and clear descriptions. All 11 tools follow the verb-first convention (list_, get_, acknowledge_). Descriptions average ~120 chars, meeting the 10-1024 char baseline. All parameters include type definitions and descriptions. However, output schemas are not explicitly documented in the source, and error handling lacks recovery guidance. Tool composition is clean, each tool has a single responsibility. The server properly gates write operations (zabbix_acknowledge_event marked WRITE). Pagination is well-implemented across list tools with page/pageSize parameters and documented limits (max 500). No secrets exposed as parameters, auth handled via environment variables.
Acknowledge a problem event, optionally add a message, change severity, close it manually, suppress it, or unacknowledge it.
Get full host detail by host ID, including groups, interfaces, tags, inventory, and linked items/triggers counts.
Read raw history for a Zabbix item over a time range. Supports pagination. `historyType` is OPTIONAL — when omitted the server auto-resolves it from the item's value_type via item.get. Pass historyType explicitly only if you need to override (rare).
Get full detail for a single Zabbix trigger including hosts, items, tags, dependencies, and discovery data.
Connectivity check for Zabbix API. Returns API version and current server time.
Output schemas not documented in source code. While parameter schemas are comprehensive, return types for each tool are not explicitly defined. LLMs cannot plan downstream tool calls without knowing what fields to expect.
Error handling lacks recovery guidance. No evidence of actionable error messages that tell LLMs what to do next (e.g., 'Host not found. Try zabbix_list_hosts() to discover available hosts.'). Raw API errors would not guide agent recovery.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 68 | 2026-07-28+ | v2 |
List trigger events from Zabbix. Supports pagination. Use for timeline/history work when problem.get is too narrow. Sorted DESC by eventid; use `lastSeen.eventid` as a continuation reference.
List Zabbix host groups with optional name search. Supports pagination.
List monitored Zabbix hosts with optional filtering by group, name, status. Supports pagination.
List Zabbix items by host/group/search. Supports pagination. Useful for metrics discovery before reading history. Returned items include `value_type` which feeds zabbix_get_item_history.
List current or historical Zabbix problem events with filters for host, group, severity, acknowledgement, suppression, and time window. Supports pagination. Sorted DESC by eventid (newest first); use `lastSeen.eventid` from the response as a stable continuation reference.
List Zabbix triggers with filters for host, group, state, severity. Supports pagination.
zabbix_acknowledge_event combines multiple concerns (acknowledge, unacknowledge, message, severity, close, suppress). While parameters are well-described, the tool could be split into separate operations for clarity: acknowledge_event, update_event_severity, suppress_event.
Pagination continuation not fully documented. zabbix_list_problems and zabbix_list_events mention using 'lastSeen.eventid' as a continuation reference, but this pattern is not explained in other list tools (zabbix_list_hosts, zabbix_list_triggers, zabbix_list_items). Inconsistent pagination guidance.
No dry-run or confirmation step for the destructive write operation (zabbix_acknowledge_event with close=true). Agents can accidentally close production incidents without a safety gate.