Zabbix MCP Server

What it is

A standalone HTTP service that puts the Zabbix API in front of MCP clients, which connect to it over the network rather than launching it. It ships 237 tools by the README's count — 223 covering all 58 Zabbix API groups, plus 14 extension tools written for this server — and an admin web portal on port 9090 for tokens, users, servers, templates, settings and the audit log. One deployment can front several Zabbix instances: every tool takes an optional server parameter and defaults to the first one configured. AGPL-3.0, from initMAX and community contributors.

What you get

• Monitoring — problem_get for what is wrong right now, event_get and event_acknowledge to acknowledge, close or comment, history_get and trend_get for raw and aggregated metric data, sla_get and sla_getsli, plus the dashboard_* and map_* families
• Data collection — host_* and hostgroup_*, item_* / trigger_* / graph_*, template_* and templategroup_*, maintenance_* to suppress alerts on a schedule, discoveryrule_* with the prototype families, and configuration_export / _import in YAML, XML or JSON
• Alerts — action_* and mediatype_* for notification channels, alert_get for the history of what was actually sent, script_execute to run global scripts on hosts over SSH, IPMI or custom commands
• Users and access — user_*, usergroup_*, role_*, and token_* for service-account API tokens
• Administration — proxy_* and proxygroup_* for distributed monitoring, auditlog_get for the trail of configuration changes and logins, settings_get / _update
• Pre-correlated views that fold 3–5 raw API calls into one round-trip — problem_active_get, host_status_get, hostgroup_overview_get, infrastructure_summary_get, item_history_summary_get
• Analysis on top of the raw data — anomaly_detect (z-score), capacity_forecast (linear regression), item_threshold_search (filter items by lastvalue thresholds), graph_render (PNG export)
• PDF reports through report_generate, rendered server-side from Jinja2 templates so the output is the same every run; built-in types are availability, capacity_host, capacity_network, backup and showcase
• A two-step approval path for writes — action_prepare, then action_confirm
• zabbix_raw_api_call for any method the server does not wrap, and health_check for its own status and connectivity to every configured Zabbix server

Requirements

A Linux server with Python 3.10 or newer, network access to your Zabbix server, and a Zabbix API token from User settings → API tokens. sudo ./deploy/install.sh creates the zabbix-mcp system user, a virtualenv at /opt/zabbix-mcp/venv, a systemd unit and logrotate; configuration is a single TOML file at /etc/zabbix-mcp/config.toml, where each Zabbix instance gets a section carrying its frontend url and api_token. read_only defaults to true per server, so writes stay off until you turn them on. Transport is http (recommended), sse or stdio, and the default endpoint is http://127.0.0.1:8080/mcp; HTTP and SSE clients authenticate with auth_token, or through the embedded OAuth 2.1 authorization server, which needs [server].public_url set. Zabbix 7.0 LTS, 7.2 and 7.4 are fully supported; on 6.0 LTS, 6.2 and 6.4 the core methods work but newer ones such as proxy groups and MFA may return errors; 5.0 LTS, 5.2 and 5.4 get core monitoring and data collection only; 8.0 is experimental behind skip_version_check = true. PDF reports need weasyprint, jinja2 and the cairo, pango and gdk-pixbuf system libraries; sudo ./deploy/install.sh update --with-reporting adds them to an existing install.

Setup effort

Build from source — git clone https://github.com/initMAX/zabbix-mcp-server.git

Tools you get

26 tools named in the project's documentation.