MCP server

Overview

Zabbix MCP server is a process that allows AI agents to work with Zabbix using the Model Context Protocol (MCP). MCP server communicates with MCP clients and Zabbix API.

Using the MCP server, an AI agent can:

• Retrieve host groups, template groups, hosts, templates, items, LLD rules, interfaces, macros, triggers, problems, maintenance periods, and item history data (except binary items);
• Perform problem updates: add comments, acknowledge or unacknowledge, change severity, suppress or unsuppress, or close problems;
• Create, update, and delete maintenance periods.

Zabbix API tokens are used for authorization; the tokens are sent with every request. Access is limited by the permissions of the token owner: only data from host groups available to that user is visible, and actions the user is not permitted to perform are rejected.

The MCP server is stateless: no session is kept between requests.

:::note-classic While Zabbix MCP server may work with older/newer versions of Zabbix, its compatibility is officially supported only for the same version of Zabbix as the MCP server itself. :::

See also:

• Configuration parameters: MCP server
• Tools and resources

Installation

The official zabbix-mcp-server package is available in the Zabbix repository.

To install Zabbix MCP server from sources, build it with make.

To configure Zabbix MCP server, update the MCP server configuration file parameters. At least the FrontendURL and AllowedIP parameters must be set.

The default configuration file (zabbix_mcp_server.conf) is located at /etc/zabbix/; it denies the tools that most often expose sensitive data. To enable a tool, remove the corresponding DenyTool line.

See also: Security best practices

Running

To start the MCP server, run:

zabbix_mcp_server -c /etc/zabbix/zabbix_mcp_server.conf

To check the configuration file and exit without starting the server, use the -T option:

zabbix_mcp_server -c /etc/zabbix/zabbix_mcp_server.conf -T

The following command-line options are supported:

When the MCP server is installed from sources, a systemd unit must be created manually, for example:

[Unit]
Description=Zabbix MCP server
After=network-online.target

[Service]
User=zabbix
ExecStart=/usr/local/sbin/zabbix_mcp_server -c /etc/zabbix/zabbix_mcp_server.conf
Restart=on-failure

[Install]
WantedBy=multi-user.target

Connecting an MCP client

Any MCP client that supports the Streamable HTTP transport can be connected to the MCP server. The following settings are required:

Each user must configure their own API token.

To verify the setup, send a single request to the MCP server:

curl -sS https://mcp.example.com:8443/mcp \
  -H "Authorization: Bearer $ZABBIX_API_TOKEN" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

The HTTP status code 200 and a list of the available tools in the response confirm that the MCP server is reachable and accepts the token; the list shows which tools are exposed. Other status codes indicate the following problems:

• 400 - the Accept header does not include both media types required by the transport;
• 401 - the Authorization header with the token is missing;
• 403 - the client address is not listed in the AllowedIP parameter.

Approval and tool access

If the MCP client supports form elicitation, every change must be approved by the user before it is sent to Zabbix. The MCP client shows the user what will be changed, and the change is applied only if the user confirms it; if the user rejects or dismisses the request, nothing is changed in Zabbix. An approval is valid for five minutes and only for the exact change that was shown; within this time, the approval can be reused.

If the MCP client does not support form elicitation (including clients that support only URL elicitation), changes are applied immediately, without approval. In this case, restrict write tools and Zabbix API permissions.

Approval is particularly important because tool output may contain untrusted text from monitored systems that could influence an agent.

Use AllowTool, DenyTool, AllowToolRegexp, and DenyToolRegexp to control which tools the MCP server exposes. Denied tools cannot be called or listed, and their associated resources cannot be accessed.

::: note-warning AllowTool, DenyTool, AllowToolRegexp, and DenyToolRegexp rules limit MCP access but do not change the permissions of the Zabbix token. If the frontend address is exposed to an AI agent, the agent may attempt to send direct API calls. Keep the Zabbix frontend location and MCP server configuration inaccessible to the agent so that requests must go through the MCP server and its security controls. :::

Security best practices

API tokens

Authentication and authorization are handled entirely by Zabbix. The MCP client sends a Zabbix API token with each request; the MCP server forwards it without storing or logging it, while Zabbix validates the token, enforces permissions, and records actions in the audit log.

Use a separate, least-privileged, expiring token for each agent and user. Store tokens in a secure location and rotate API tokens regularly.

TLS encryption

To prevent tokens from being sent in clear text, set TLSAccept=cert and specify the certificate and the key (TLSCertFile and TLSKeyFile) or run the MCP server behind a trusted TLS-terminating reverse proxy and set TLSAccept=unencrypted. Unencrypted HTTP is acceptable only in a trusted network.

Access restrictions

Restrict the AllowedIP parameter to the addresses of trusted MCP clients, and use Zabbix permissions to limit what API tokens can do.

The MCP server does not provide request rate limiting. Each MCP request normally results in one Zabbix API call, although an agent running in a loop can still generate significant load.

Sensitive data protection

Item keys may contain credentials (for example, in SSH, JMX, ODBC and HTTP agent items), macro values may contain passwords and community strings, interfaces reveal internal addresses, and log or text item values may contain any data. For this reason, the item_get, lld_get, interface_get, macro_get and history_get tools are denied by default in the shipped configuration file.

To avoid sensitive macro value exposure to the LLM provider of the connected agent, use secret macros; their values are never returned by the API.