Loading ToolBench
Model Context Protocol (MCP) server for Zabbix monitoring platform
This server has 23 tools with explicit schemas and descriptions, but significant gaps in parameter documentation and output schema definition. Most tools have basic descriptions (average ~100 chars) but many parameters lack descriptions entirely. Input schemas are present but incomplete, most lack 'required' field declarations and many parameters are undescribed. No output schemas are documented. Error handling is minimal. The server follows basic tool definition patterns but falls short of production-grade quality due to incomplete parameter documentation and missing output schema definitions.
Add a network interface to an existing host for polling by Zabbix server
Check if host interface (agent) is available
Create a new Zabbix host (monitor). Use this to add new containers/servers to monitoring.
Create a maintenance window for hosts to pause data collection and suppress alerts
Create a new Zabbix user with specified role
Delete a host from Zabbix monitoring. Removes all associated items, triggers, and history.
Missing output schemas for all tools. No documentation of what fields/structure each tool returns. LLMs cannot plan downstream calls without knowing response structure.
No pagination support visible in schemas for list-returning tools (get_hosts, get_problems, get_triggers, get_events, get_templates). Large result sets will bloat context. Missing limit validation and result caps.
Many tools lack 'required' array in inputSchema. get_items requires hostname but schema does not declare it as required. This lets LLMs omit critical parameters.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Disable monitoring for a host (set status=1). Host will stop collecting data.
Enable monitoring for a host (set status=0)
Get recent events from Zabbix
Get detailed information about a specific host
List all host groups
List all monitored hosts in Zabbix
Get monitored items (metrics)
Get active problems/alerts
List all available Zabbix roles
Get overall system status and statistics
List all available templates
List triggers with their current status
Link a template to a host by names (hostname and template name)
Fix sequence table desynchronization (call this once after manual DB operations)
Update host properties (name, status, groups, etc.)
Update a host interface (IP address, port, authentication, etc.)
Update user properties (password, role, etc.)
No error handling or recovery guidance documented. Tools like delete_host should warn about cascading deletes and offer confirmation/dry-run. No actionable error messages defined.
Parameter descriptions are often generic or missing context. Example: 'limit' param in get_problems has no description of the default value, min/max range, or what happens if exceeded.
No input validation constraints visible (min/max for integers, regex patterns, enum values). Tools accept 'limit' as unbounded integer, LLM could pass 999999 and cause timeout.
Credentials (Zabbix API URL, auth token) must not be exposed as tool parameters. Code sample shows they are likely injected via env vars, but schema inspection cannot confirm. This is a implementation detail rather than definition issue.
Tools like create_user accept password as a plain parameter. While this may be intentional (user-facing tool), it risks logging the password in MCP call traces. Should use secure input protocol or confirmation step.
No toolAnnotations (readOnlyHint, destructiveHint, idempotentHint) visible in schema. LLMs cannot infer which tools are safe to call without user approval.