Zabbix MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Logging level | INFO |
| SENTRY_DSN | No | Sentry DSN to enable error tracking | |
| ZABBIX_URL | No | URL of the Zabbix API endpoint, e.g., https://zabbix.example.com/api_jsonrpc.php | |
| ZABBIX_USER | No | Zabbix username for authentication (alternative to token) | |
| ZABBIX_TOKEN | No | Zabbix API token (preferred for Zabbix 5.4+) | |
| DISABLED_TAGS | No | Comma-separated list of tags to disable tools for | |
| MCP_HTTP_HOST | No | Host to bind HTTP server | 0.0.0.0 |
| MCP_HTTP_PORT | No | Port to bind HTTP server | 8000 |
| MCP_TRANSPORT | No | Transport type: stdio, sse, or http | stdio |
| READ_ONLY_MODE | No | Set to true to disable all write operations | false |
| ZABBIX_TIMEOUT | No | Connection timeout in seconds | 30 |
| ZABBIX_PASSWORD | No | Zabbix password for authentication (alternative to token) | |
| ZABBIX_VERIFY_SSL | No | Enable SSL certificate verification | true |
| RATE_LIMIT_ENABLED | No | Enable rate limiting | false |
| TOOL_SEARCH_ENABLED | No | Replace full tool listing with search tools | false |
| TOOL_SEARCH_STRATEGY | No | Search strategy: bm25 or regex | bm25 |
| MCP_HTTP_BEARER_TOKEN | No | Optional bearer token for HTTP authentication | |
| RATE_LIMIT_MAX_REQUESTS | No | Maximum requests allowed per window | 60 |
| TOOL_SEARCH_MAX_RESULTS | No | Maximum number of matching tools returned | 5 |
| RATE_LIMIT_WINDOW_MINUTES | No | Window size in minutes | 1 |
| ZABBIX_SKIP_VERSION_CHECK | No | Skip version check | false |
Capabilities
Features and capabilities supported by this server
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| extensions | {
"io.modelcontextprotocol/ui": {}
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| api_versionA | 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. Returns: dict: Contains 'version' key with the API version string (e.g., "6.0.10"). On error, contains 'error' key with the error message. |
| host_getA | Get hosts from Zabbix with optional filtering. Retrieves a list of monitored hosts from Zabbix. You can filter by host IDs, groups, templates, proxies, or use search criteria. This is useful for discovering which hosts are available in your monitoring system. |
| host_createA | Create a new host in Zabbix. Adds a new monitored host to Zabbix. This is essential for starting to monitor a new server or device. You must specify at least a host name and groups. You can optionally configure interfaces (for agent/SNMP communication) and link templates. |
| host_updateA | Update an existing host in Zabbix. Modifies properties of an existing host. You can change the technical name, visible name, status (enable/disable monitoring), or description. Only specify the fields you want to change. |
| host_deleteA | Delete hosts from Zabbix. Permanently removes one or more hosts from Zabbix. This will delete all associated data including history and alerts. Use with caution as this is a destructive operation. |
| hostgroup_getA | Get host groups from Zabbix. Retrieves host groups with optional filtering. Host groups are used to organize and manage hosts collectively, applying templates, permissions, and maintenance windows to multiple hosts at once. |
| hostgroup_createA | Create a new host group in Zabbix. Host groups serve as containers for organizing hosts. They're essential for applying permissions, templates, and maintenance windows to multiple hosts at once. |
| hostgroup_updateA | Update an existing host group in Zabbix. Modifies properties of an existing host group. You can change the group's name. Only specify the fields you want to change. |
| hostgroup_deleteA | Delete host groups from Zabbix. Permanently removes one or more host groups. Hosts in deleted groups will no longer be members of that group (though the hosts themselves remain unless explicitly deleted). |
| template_getA | Get templates from Zabbix. Templates are reusable collections of items, triggers, and graphs that can be applied to hosts. They standardize monitoring across multiple servers with the same role. |
| template_createA | Create a new template in Zabbix. Templates define the monitoring configuration (items, triggers, graphs) that can be reused across multiple hosts. Creating custom templates enables standardized monitoring for specific applications or server types. |
| template_updateA | Update an existing template in Zabbix. Modifies properties of an existing template. You can change the name or description. Only specify the fields you want to change. |
| template_deleteA | Delete templates from Zabbix. Permanently removes one or more templates. Hosts that have the deleted templates applied will lose those template's items, triggers, and graphs. The hosts themselves remain unchanged. |
| item_getB | Get items (metrics) from Zabbix. Items are the data sources in Zabbix - they define what metrics are collected and how (protocol, interval, etc.). Each item produces a stream of values over time. |
| item_createB | Create a new item in Zabbix. Items define what data is collected from a host. Each item specifies the metric name, how to collect it (agent, SNMP, etc.), what interval to use, and what data type to store. |
| item_updateA | Update an existing item in Zabbix. Modifies properties of an existing monitoring item. You can change the name, collection interval, units, or status. Only specify the fields you want to change. |
| item_deleteA | Delete items from Zabbix. Permanently removes one or more items from monitoring. The item's historical data is typically removed as part of cleanup, though this depends on Zabbix configuration. |
| itemprototype_getA | Get item prototypes from Zabbix. Item prototypes are template items created by discovery rules that generate actual items dynamically based on discovered entities. |
| trigger_getA | Get triggers from Zabbix. Triggers are rules that define when a problem occurs based on item values. They evaluate expressions against collected metrics and transition between problem and normal states. |
| trigger_createA | Create a new trigger in Zabbix. Triggers define the conditions under which problems are detected. They use expressions to evaluate item values and determine when to transition from normal to problem state. |
| trigger_updateB | Update an existing trigger in Zabbix. Modifies properties of an existing trigger. You can change the description, expression, priority, status, or comments. Only specify fields you want to change. |
| trigger_deleteA | Delete triggers from Zabbix. Permanently removes one or more triggers. Hosts will no longer generate alerts for these conditions. Historical trigger data and associated problems are typically retained. |
| problem_getA | Get problems from Zabbix. Problems are active trigger states that indicate issues with monitored infrastructure. Each problem is associated with a trigger and can be acknowledged by operators. |
| event_getA | Get events from Zabbix. Events represent state changes in the system - when triggers transition from normal to problem and back, or recovery events. Each event has a timestamp, trigger, and can be acknowledged to show operators have seen the alert. |
| event_acknowledgeA | Acknowledge events in Zabbix. Mark events (problems/alerts) as acknowledged to show that operations staff are aware of and working on the issue. Acknowledged events can also be closed if resolved. |
| history_getB | Get history data from Zabbix. Retrieves the raw metric values collected by items. History contains all individual collected data points with timestamps, allowing detailed analysis of system behavior over time. |
| trend_getA | Get trend data from Zabbix. Trends are aggregated (summarized) historical data providing min/max/average values at hour-long intervals. Trends use less storage than raw history while preserving statistical information for long-term analysis. |
| user_getA | Get users from Zabbix. Users represent people with access to the Zabbix system. Each user has authentication credentials and permission level determining what they can view and modify. |
| user_createA | Create a new user in Zabbix. Creates a new user account with specified credentials and group membership. New users inherit permissions from their assigned user groups. |
| user_updateA | Update an existing user in Zabbix. Modifies properties of an existing user account. You can change name, surname, password, or user type. Only specify the fields you want to change. |
| user_deleteA | Delete users from Zabbix. Permanently removes user accounts from the system. The user's access will be immediately revoked. Historical data and previous actions by the user are retained for audit purposes. |
| proxy_getC | Get proxies from Zabbix. Proxies act as data collection points for Zabbix, allowing monitoring of remote networks without direct connectivity. Proxies collect data locally and report to the Zabbix server. |
| proxy_createA | Create a new proxy in Zabbix. Proxies allow distributed monitoring by collecting data from remote networks and reporting to the central Zabbix server. Useful for firewall-separated networks or high-latency connections. |
| proxy_updateA | Update an existing proxy in Zabbix. Modifies properties of an existing proxy. You can change the name, operating mode, or description. Only specify the fields you want to change. |
| proxy_deleteA | Delete proxies from Zabbix. Permanently removes proxy definitions. Hosts assigned to deleted proxies will need to be reassigned to other proxies or the server. Data from deleted proxies is typically retained. |
| maintenance_getA | 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. |
| maintenance_createA | 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. |
| maintenance_updateA | Update an existing maintenance period in Zabbix. Modifies properties of an existing maintenance window. You can change the name, start time, end time, or description. Only specify the fields you want to change. |
| maintenance_deleteA | Delete maintenance periods from Zabbix. Cancels maintenance windows immediately, resuming alert generation. If the maintenance period has already passed, historical event suppression is retained. |
| action_getA | Get actions from Zabbix. Actions define automated responses to problems/triggers. They specify what happens when problems occur - sending notifications, executing remote commands, etc. |
| mediatype_getA | Get media types from Zabbix. Media types define communication channels for sending notifications (email, SMS, webhooks, etc.). Actions use media types to deliver alerts to users and integrations. |
| graph_getB | Get graphs from Zabbix. Graphs visualize item data over time, displaying metric values in line/bar/pie charts. Graphs can be included in dashboards, reports, and custom views for data analysis. |
| discoveryrule_getB | Get discovery rules from Zabbix. Discovery rules automatically detect items, triggers, and interfaces from network resources. They enable dynamic host and item management without manual configuration. |
| drule_getA | Get network discovery rules from Zabbix. Network discovery (drule) rules perform network scanning to discover hosts and services. They can scan for active devices, open ports, and available services in CIDR ranges. |
| configuration_exportA | 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:
|
| configuration_importA | Import configurations into Zabbix. Imports hosts, templates, and other configurations from JSON or XML format. Useful for migration, cloning, or restoring configurations. |
| sla_getB | Get SLAs from Zabbix. Service Level Agreements (SLAs) define uptime and availability targets for services. They track compliance with service objectives and generate reports on availability. |
| service_getA | Get services from Zabbix. Services represent business capabilities or applications (e.g., 'Web Application', 'Database'). Services can depend on other services, creating hierarchies for tracking dependencies. |
| script_getB | Get scripts from Zabbix. Scripts are custom automation routines that can be executed on monitored hosts or the server. They can be triggered manually or by actions to automate remediation or configuration tasks. |
| script_executeA | Execute a script on a host in Zabbix. Runs a custom script on a specified host. Used for executing remediation tasks, configuration changes, or diagnostic commands remotely. |
| usermacro_getA | Get user macros from Zabbix. User macros are variables that can be referenced in items, triggers, and scripts. They allow parameterization of monitoring configurations with custom values. |
| usermacro_createA | Create a new host macro in Zabbix. Host macros define custom variables for specific hosts. They can be referenced in items and triggers using {$MACRO_NAME} syntax, allowing dynamic configuration without editing items. |
| usermacro_deleteA | Delete host macros from Zabbix. Permanently removes host-level macro definitions. Items and triggers using this macro will no longer be able to reference it, potentially causing parsing errors. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mhajder/zabbix-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server