# Zabbix AI CLI MCP (oci · ghcr.io/stufently/zabbix-ai-cli-mcp)

Task-shaped Zabbix access for AI agents: problems, host triage, metrics, maintenance windows.

- Trust score: 61/100 (medium)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

## Components

- oci · `ghcr.io/stufently/zabbix-ai-cli-mcp`: 61/100 (this document), [markdown](https://verifymcp.io/servers/stufently-zabbix-ai-cli-mcp/ghcr-io-stufently-zabbix-ai-cli-mcp.md), [page](https://verifymcp.io/servers/stufently-zabbix-ai-cli-mcp/ghcr-io-stufently-zabbix-ai-cli-mcp)

## Channel facts

- Registry: `oci`
- Package: `ghcr.io/stufently/zabbix-ai-cli-mcp`
- Version: `0.5.0`
- Transport: `stdio`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Supply Chain Security**: 0/100
  - No malware scan is available for this kind of package: the supply-chain vendors we use do not cover it. This is a permanent gap in our coverage, not a finding about the package.
  - Known CVEs could not be checked: this artifact ships no SBOM or dependency manifest, so there is no dependency list to read.
  - Install-script risk not yet assessed.
  - Dependency health could not be checked: this artifact ships no SBOM or dependency manifest, so there is no dependency list to read.
- **Provenance & Transparency**: 100/100
  - Source repository is publicly reachable at the declared URL.
  - Cryptographically verified build provenance (signed, bound to stufently/zabbix-ai-cli-mcp).
  - Clear OSI-approved license (Apache-2.0).
  - Actively maintained (last published 20 days ago).
  - Publishes a security disclosure policy (SECURITY.md).
- **Schema Quality & AI Usability**: 69/100
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 2785 tokens (~185/item across 15 items; 15 tools + 0 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 73/100
  - Stability observed for 22 of 30 days with no destabilising changes; credit accrues until the full window elapses.
- **Tool Coverage**: 100/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 100% of tool parameters carry a description.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - We read all 15 captured tool definition(s), and no name or description among them implies an irreversible operation.
  - An AI judge read all 16 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

**Unverified: 1 category.** A category scored 0 because we could not verify it: a data source with nothing on this package, evidence we could not reach, or a check we could not run. We only credit what we can confirm.

## Install

### How do I install the Zabbix AI CLI MCP server?

Zabbix AI CLI MCP runs locally as a container image, launched with docker run --rm -i ghcr.io/stufently/zabbix-ai-cli-mcp:0.5.0. Ready-made configuration for Claude, Cursor, VS Code, Codex and 3 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add stufently-zabbix-ai-cli-mcp -- docker run --rm -i ghcr.io/stufently/zabbix-ai-cli-mcp:0.5.0
```

### Cursor

```json
{
  "mcpServers": {
    "stufently-zabbix-ai-cli-mcp": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/stufently/zabbix-ai-cli-mcp:0.5.0"
      ]
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "stufently-zabbix-ai-cli-mcp": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/stufently/zabbix-ai-cli-mcp:0.5.0"
      ]
    }
  }
}
```

### Codex

```bash
codex mcp add stufently-zabbix-ai-cli-mcp -- docker run --rm -i ghcr.io/stufently/zabbix-ai-cli-mcp:0.5.0
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "stufently-zabbix-ai-cli-mcp": {
      "type": "local",
      "command": [
        "docker",
        "run",
        "--rm",
        "-i",
        "ghcr.io/stufently/zabbix-ai-cli-mcp:0.5.0"
      ],
      "enabled": true
    }
  }
}
```

### Hermes

```yaml
mcp_servers:
  stufently-zabbix-ai-cli-mcp:
    command: "docker"
    args: ["run", "--rm", "-i", "ghcr.io/stufently/zabbix-ai-cli-mcp:0.5.0"]
```

### Netclaw

```json
{
  "McpServers": {
    "stufently-zabbix-ai-cli-mcp": {
      "Transport": "stdio",
      "Command": "docker",
      "Arguments": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/stufently/zabbix-ai-cli-mcp:0.5.0"
      ]
    }
  }
}
```

### Other

```json
{
  "mcpServers": {
    "stufently-zabbix-ai-cli-mcp": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "ghcr.io/stufently/zabbix-ai-cli-mcp:0.5.0"
      ]
    }
  }
}
```

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-05 (score 61, +1)

No change was recorded against any check on this day. Stability & Change Management went from 70 to 73. That category is still filling its 30-day observation window: 21 days of observed history at the previous scan, 22 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-03 (score 60, +1)

No change was recorded against any check on this day. Stability & Change Management went from 63 to 67. That category is still filling its 30-day observation window: 19 days of observed history at the previous scan, 20 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-11-01 (score 59, +1)

No change was recorded against any check on this day. Stability & Change Management went from 57 to 60. That category is still filling its 30-day observation window: 17 days of observed history at the previous scan, 18 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-30 (score 58, +1)

No change was recorded against any check on this day. Stability & Change Management went from 50 to 53. That category is still filling its 30-day observation window: 15 days of observed history at the previous scan, 16 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-28 (score 57, +1)

No change was recorded against any check on this day. Stability & Change Management went from 43 to 47. That category is still filling its 30-day observation window: 13 days of observed history at the previous scan, 14 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-25 (score 56, +1)

No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-23 (score 55, +1)

No change was recorded against any check on this day. Stability & Change Management went from 27 to 30. That category is still filling its 30-day observation window: 8 days of observed history at the previous scan, 9 at this one. The score rises as the window fills, whether or not the server changes.

### 2026-10-21 (score 54, +1)

No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.

## MCP tools (15)

### `zabbix_alert_why` (~128 tokens)

Explain whether an event produced a notification, and what stood in the way.

Walks the whole chain: suppression, delivery attempts and their errors, trigger actions, media types, and each recipient's media severity filter and active period. Any one of those links can drop a notification without recording an error anywhere.

Use when the user asks why an alert did or did not arrive, or why a notification was missing. For the problem itself call zabbix_problem; to turn a pasted notification into identifiers call zabbix_resolve first.

Input parameters:

- `event` (string, required): event identifier

### `zabbix_api_call` (~222 tokens)

Call a Zabbix API method directly.

Read methods run immediately. Write methods produce a plan and go through approval like every other change. A method that is not in the risk registry is refused rather than guessed at. The constrained exceptions are mediatype.update (mediatypeid + status only) and discoveryrule.update (itemid + lifetime_type/lifetime/enabled_lifetime_type/enabled_lifetime only); prefer the domain operations. The params argument accepts an object, array or JSON string. Over MCP this tool is read-only.

Use when no high-level tool covers the question and a read method such as host.get is required. For problems, hosts, metrics or alert delivery call the matching zabbix tool instead. A write through this tool is refused; to make one, call zabbix_write, or zabbix_plan_create to show the operator the change first.

Input parameters:

- `method` (string, required): API method, for example host.get
- `params`: method parameters as a JSON object or JSON string (arrays also accepted)

### `zabbix_host_investigate` (~123 tokens)

Collect a diagnostic snapshot of one host in a single call.

Gathers host state, active problems, recent events, silent and unsupported items and maintenance windows. It reports facts and draws no conclusions; interpreting them is the caller's job.

Use when the user asks what is wrong with a named host or wants one diagnostic pass instead of several queries. For a short status line call zabbix_host_status; for hosts Zabbix cannot poll at all call zabbix_unreachable.

Input parameters:

- `host` (string, required): host name, fragment or identifier

### `zabbix_host_status` (~116 tokens)

Summarise one host: availability, active problems, data freshness, maintenance.

An aggregate over several API calls, returned as a handful of fields rather than several thousand characters of configuration.

Use when the user wants a short health check of one named host: whether it is up, whether it has problems, whether data is fresh. For the full diagnostic bundle call zabbix_host_investigate; to search by a name fragment call zabbix_hosts.

Input parameters:

- `host` (string, required): host name, fragment or identifier

### `zabbix_hosts` (~179 tokens)

Find hosts by name fragment, pattern or group.

Matching is a case-insensitive substring over both the technical and the visible name, and exact matches are listed first. Guessing exact names is the most common way a query comes back empty.

Use when the user is looking for a host and does not have its exact name, or wants the hosts in a group. For a short health check of one host call zabbix_host_status; for a full diagnostic snapshot call zabbix_host_investigate.

Input parameters:

- `group` (string): limit to a host group
- `limit` (integer): maximum rows to return, 1 to 500 (default 50); the result reports whether it was truncated
- `monitored` (boolean): exclude hosts whose monitoring is disabled
- `search` (string): name fragment; * is allowed

### `zabbix_maintenance_list` (~168 tokens)

List maintenance windows, including expired ones.

Expired windows are shown by default: removing one that has already lapsed is a routine follow-up, and it cannot be done if the window is invisible.

Use when the user asks which maintenance windows exist, which hosts are silenced, or whether a window has expired. To open, extend, end or remove a window, call zabbix_write, or zabbix_plan_create to show the operator the change first.

Input parameters:

- `active` (boolean): hide windows whose period has passed
- `host` (string): only windows covering this host
- `limit` (integer): maximum rows to return, 1 to 500 (default 50); the result reports whether it was truncated
- `search` (string): name fragment

### `zabbix_metrics_history` (~182 tokens)

Read an item's values over a time window, with min, max and average.

Windows are written the way operators write them: 30m, 2h, 24h, 7d.

Use when the user asks how a metric behaved over a period, or wants its minimum, average and maximum. For only the newest value call zabbix_metrics_latest; for whether the host itself is unreachable call zabbix_unreachable.

Input parameters:

- `host` (string, required): host name or fragment
- `items` (integer): maximum distinct items to read, 1 to 10
- `last` (string): how far back to read
- `limit` (integer): maximum rows to return, 1 to 500 (default 200); the result reports whether it was truncated
- `search` (string): item name or key fragment

### `zabbix_metrics_latest` (~167 tokens)

Show the newest value of a host's items.

Values come from history, because item.lastvalue has returned a constant zero for several releases. The history type is derived from each item automatically; querying it wrongly returns nothing rather than an error.

Use when the user wants the current value of an item, such as CPU, disk or a custom metric, on one host. For values across a time window call zabbix_metrics_history; for a host whose items stopped sending data call zabbix_host_investigate.

Input parameters:

- `host` (string, required): host name or fragment
- `limit` (integer): maximum rows to return, 1 to 500 (default 25); the result reports whether it was truncated
- `search` (string): item name or key fragment

### `zabbix_plan_create` (~376 tokens)

Describe a change to Zabbix without making it. Use when the user wants to see what a change would do before anything is written. Call zabbix_write instead when the user wants the change applied now; call zabbix_plan_status to check a plan that already exists.

Returns a plan identifier and the exact command the operator must run to apply it. Nothing changes until it is applied. Use this to show the operator what a change would do; call zabbix_write to make one, or relay the approve command so the operator applies this exact plan.

Available operations:
api.call — Call a Zabbix API method directly.
discoveryrules.set_lost_resources — Set lost LLD resource policy by itemid or template + rule name; only lifetime_type/lifetime/enabled_lifetime_type/enabled_lifetime. Shows host and lost-item counts; deletion is destructive.
events.acknowledge — Acknowledge an event, comment on it, close it or change its severity.
maintenance.create — Open a maintenance window over hosts or host groups.
maintenance.delete — Remove a maintenance window permanently.
maintenance.expire — End a maintenance window now, keeping its record.
maintenance.extend — Push a maintenance window's end further out.
mediatypes.disable — Disable a media type by mediatypeid or exact name; change only status and show affected users/actions.
mediatypes.enable — Enable a media type by mediatypeid or exact name; change only status, including Script/Webhook.
triggers.disable — Disable a trigger so it stops raising problems.
triggers.enable — Re-enable a disabled trigger.

Input parameters:

- `operation` (string, required): the change to describe
- `params` (object): parameters for the operation; call zabbix_plan_create with an unknown parameter to be told the accepted ones

### `zabbix_plan_status` (~97 tokens)

Check whether a stored plan is still waiting, was applied, or has expired. Use when the user asks what happened to a change they were asked to approve, or after zabbix_plan_create while you wait. Call zabbix_plan_create to describe a new change, and call zabbix_write when the user wants that change made now.

Input parameters:

- `plan_id` (string, required): identifier returned by zabbix_plan_create

### `zabbix_problem` (~79 tokens)

Show one active problem by event identifier.

Use when the user gives one event identifier and wants that problem's host, severity and state. For the list of what is broken now call zabbix_problems; to learn why its notification did or did not arrive call zabbix_alert_why.

Input parameters:

- `event` (string, required): event identifier

### `zabbix_problems` (~222 tokens)

List active Zabbix problems, newest first.

Suppressed problems are included by default and say which maintenance window hides them. Hiding them silently is how an outage goes unnoticed for weeks.

Use when the user asks what is broken right now, which problems are firing, or whether anything is in alarm. For one event identifier call zabbix_problem; to learn why a notification never arrived call zabbix_alert_why.

Input parameters:

- `exclude_suppressed` (boolean): hide problems inside a maintenance window (they are shown by default)
- `group` (string): limit to a host group
- `host` (string): limit to one host; matching is fuzzy
- `limit` (integer): maximum rows to return, 1 to 500 (default 50); the result reports whether it was truncated
- `severity` (string): minimum severity, as a name or 0-5
- `since` (string): only problems that started within this window
- `unacknowledged` (boolean): only problems nobody has acknowledged

### `zabbix_resolve` (~132 tokens)

Turn the text of a notification into event, host and trigger identifiers.

Accepts a notification pasted out of a chat client. Without it, an instruction such as "acknowledge that one" cannot be acted on, because the identifiers only exist inside the message text.

Use when the user pastes a notification from chat and the event, host or trigger identifier is buried in that text. Once you have the event identifier, call zabbix_problem for the problem or zabbix_alert_why for the delivery chain.

Input parameters:

- `text` (string, required): the pasted notification, or a bare event identifier

### `zabbix_unreachable` (~143 tokens)

List monitored hosts Zabbix currently cannot poll.

Availability lives on the interface: host.available was removed in 5.4, and code still reading it sees nothing at all.

Use when the user asks which hosts Zabbix cannot poll, or which agent, SNMP, IPMI or JMX interfaces are down. A host whose interface is up but whose items went silent is not listed here: call zabbix_host_investigate for that, and zabbix_metrics_latest for the newest values.

Input parameters:

- `limit` (integer): maximum rows to return, 1 to 500 (default 50); the result reports whether it was truncated

### `zabbix_write` (~366 tokens)

Change Zabbix in one call and record it in the audit log. Use when the user wants a permitted change applied now rather than only described. To show the operator the change before anything is written, call zabbix_plan_create instead; to check a plan that already exists, call zabbix_plan_status.

Prefer the narrowest operation that does the job and say plainly what you did. Operations marked destructive remove something Zabbix cannot restore on its own.

Available operations:
api.call — Call a Zabbix API method directly.
discoveryrules.set_lost_resources — Set lost LLD resource policy by itemid or template + rule name; only lifetime_type/lifetime/enabled_lifetime_type/enabled_lifetime. Shows host and lost-item counts; deletion is destructive.
events.acknowledge — Acknowledge an event, comment on it, close it or change its severity.
maintenance.create — Open a maintenance window over hosts or host groups.
maintenance.delete — Remove a maintenance window permanently. (destructive)
maintenance.expire — End a maintenance window now, keeping its record.
maintenance.extend — Push a maintenance window's end further out.
mediatypes.disable — Disable a media type by mediatypeid or exact name; change only status and show affected users/actions. (destructive)
mediatypes.enable — Enable a media type by mediatypeid or exact name; change only status, including Script/Webhook.
triggers.disable — Disable a trigger so it stops raising problems. (destructive)
triggers.enable — Re-enable a disabled trigger.

Input parameters:

- `operation` (string, required): the change to make
- `params` (object): parameters for the operation; call zabbix_write with an unknown parameter to be told the accepted ones

## Diagnostics

Captured diagnostic sections: Provenance. The full working is on the page: https://verifymcp.io/servers/stufently-zabbix-ai-cli-mcp/ghcr-io-stufently-zabbix-ai-cli-mcp#diagnostics

## Score history

- 2026-11-05: 61
- 2026-11-04: 60
- 2026-11-03: 60
- 2026-11-02: 59
- 2026-11-01: 59
- 2026-10-31: 58
- 2026-10-30: 58
- 2026-10-29: 57
- 2026-10-28: 57
- 2026-10-27: 56
- 2026-10-26: 56
- 2026-10-25: 56
- 2026-10-24: 55
- 2026-10-23: 55
- 2026-10-22: 54
- 2026-10-21: 54
- 2026-10-20: 53
- 2026-10-19: 53
- 2026-10-18: 52
- 2026-10-17: 52
- 2026-10-16: 51
- 2026-10-15: 51
- 2026-10-14: 51
- 2026-10-13: 10
- 2026-10-12: 10
- 2026-10-11: 10

## Common questions

### What is the Zabbix AI CLI MCP server?

Zabbix AI CLI MCP is listed in the public MCP registry as io.github.stufently/zabbix-ai-cli-mcp. Task-shaped Zabbix access for AI agents: problems, host triage, metrics, maintenance windows. This page covers its container image (ghcr.io/stufently/zabbix-ai-cli-mcp).

### Is the Zabbix AI CLI MCP server safe to use?

Zabbix AI CLI MCP scores 61 out of 100 on VerifyMCP. Its build provenance is signed and verified. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Zabbix AI CLI MCP server expose?

Zabbix AI CLI MCP exposes 15 tools: zabbix_alert_why, zabbix_api_call, zabbix_host_investigate, zabbix_host_status, zabbix_hosts, and 10 more. Their descriptions and schemas cost roughly 2,700 tokens of context every time the server is loaded.

### Is the Zabbix AI CLI MCP server still maintained?

Zabbix AI CLI MCP is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

### What licence is the Zabbix AI CLI MCP server under?

Zabbix AI CLI MCP declares the Apache-2.0 licence, which is OSI-approved. That covers the source only, and says nothing about the cost of any service it calls.

## Links

- GitHub Container Registry: https://ghcr.io/stufently/zabbix-ai-cli-mcp
- Repository: https://github.com/stufently/zabbix-ai-cli-mcp
- Changelog RSS feed: https://verifymcp.io/servers/stufently-zabbix-ai-cli-mcp/ghcr-io-stufently-zabbix-ai-cli-mcp.xml
- Changelog JSON feed: https://verifymcp.io/servers/stufently-zabbix-ai-cli-mcp/ghcr-io-stufently-zabbix-ai-cli-mcp.json
- HTML version of this page: https://verifymcp.io/servers/stufently-zabbix-ai-cli-mcp/ghcr-io-stufently-zabbix-ai-cli-mcp