Zabbix MCP server and command-line client in one Go binary

Install

On Linux or macOS, paste this into a terminal. It fetches the latest release, checks it against checksums.txt, puts the binary in ~/.local/bin and starts the MCP server over stdio. Replace the two placeholders first:

VERSION=$(curl -fsSLI -o /dev/null -w '%{url_effective}' \
  https://github.com/stufently/zabbix-ai-cli-mcp/releases/latest | sed 's|.*/v||')
OS=$(uname -s | tr '[:upper:]' '[:lower:]')                      # linux | darwin
ARCH=$(uname -m | sed 's/x86_64/amd64/; s/aarch64/arm64/')        # amd64 | arm64
ARCHIVE=zabbix-ai-cli-mcp_${VERSION}_${OS}_${ARCH}.tar.gz
BASE=https://github.com/stufently/zabbix-ai-cli-mcp/releases/download/v${VERSION}

TMP=$(mktemp -d) && cd "$TMP"
curl -fsSLO "$BASE/$ARCHIVE" && curl -fsSLO "$BASE/checksums.txt"
grep " $ARCHIVE\$" checksums.txt | shasum -a 256 -c -   # sha256sum -c - works too
tar -xzf "$ARCHIVE"
mkdir -p ~/.local/bin && install -m 0755 zabbix-ai-cli-mcp ~/.local/bin/
~/.local/bin/zabbix-ai-cli-mcp --version
ZABBIX_AI_CLI_MCP_URL=https://zabbix.example.com ZABBIX_AI_CLI_MCP_TOKEN=your-api-token ~/.local/bin/zabbix-ai-cli-mcp mcp

The last line is the command every client block below runs: zabbix-ai-cli-mcp with arguments ["mcp"], the Zabbix URL and API token taken from the environment. Stop it with Ctrl-C once it starts; the client launches it from then on. ~/.local/bin has to be on PATH, because the client configurations call the binary by name; otherwise give them the absolute path.

Prebuilt binary (no Go needed)

Each tagged release publishes archives for Linux, macOS and Windows on amd64 and arm64, plus checksums.txt. The block at the top of this section installs one on Linux or macOS. The archive also carries docs/ and the agent skills.

On Windows (PowerShell), the archive is a zip:

$Version = (Invoke-RestMethod https://api.github.com/repos/stufently/zabbix-ai-cli-mcp/releases/latest).tag_name.TrimStart('v')
$Arch = if ($env:PROCESSOR_ARCHITECTURE -eq 'ARM64') { 'arm64' } else { 'amd64' }
$Zip = "zabbix-ai-cli-mcp_${Version}_windows_${Arch}.zip"
$Base = "https://github.com/stufently/zabbix-ai-cli-mcp/releases/download/v$Version"
Invoke-WebRequest "$Base/$Zip" -OutFile $Zip
Invoke-WebRequest "$Base/checksums.txt" -OutFile checksums.txt
$Want = ((Select-String -Path checksums.txt -Pattern " $Zip$").Line -split '\s+')[0]
if ((Get-FileHash $Zip -Algorithm SHA256).Hash -ne $Want) { throw "checksum mismatch" }
Expand-Archive $Zip -DestinationPath "$env:LOCALAPPDATA\zabbix-ai-cli-mcp" -Force
& "$env:LOCALAPPDATA\zabbix-ai-cli-mcp\zabbix-ai-cli-mcp.exe" --version

Add %LOCALAPPDATA%\zabbix-ai-cli-mcp to PATH, or use the full path to zabbix-ai-cli-mcp.exe in the client configuration.

From source

For a host-native build, use Go 1.25 or newer:

go install github.com/stufently/zabbix-ai-cli-mcp/cmd/zabbix-ai-cli-mcp@latest

# Or build the current checkout.
mkdir -p bin
go build -trimpath -o bin/zabbix-ai-cli-mcp ./cmd/zabbix-ai-cli-mcp

The Make targets are container-first and do not require Go on the host:

make build      # Linux binary in ./bin, built inside Docker
make docker     # Linux container image for the MCP server

Check where a release came from

checksums.txt proves a download is intact, not who built it: whoever could replace an archive could replace the checksum file next to it. From the first release cut after this section was added, the release workflow also signs build provenance for every archive, every .mcpb bundle and the container image (Sigstore, through GitHub artifact attestations). With the GitHub CLI:

verify() {
  gh attestation verify "$1" --repo stufently/zabbix-ai-cli-mcp \
    --source-ref "refs/tags/v$VERSION" \
    --signer-workflow stufently/zabbix-ai-cli-mcp/.github/workflows/release.yml \
    --deny-self-hosted-runners
}
verify "$ARCHIVE"
verify "zabbix-ai-cli-mcp-${VERSION}-linux-amd64.mcpb"
verify "oci://ghcr.io/stufently/zabbix-ai-cli-mcp:$VERSION"

A pass means the file was built by this repository's release workflow, on a GitHub-hosted runner, from the tag v$VERSION: an attested file from another release, renamed, fails --source-ref. Releases up to and including 0.4.3 carry checksums only.

Safety

Read operations always run immediately. Whether anything else does is one setting, allow_write, and it is on by default.

# ~/.config/zabbix-ai-cli-mcp/config.toml
allow_write = true            # the default; omit the key and you get this

[profiles.prod]
url = "https://zabbix.example.com"
allow_write = false           # this one profile is an exception

If you are not sure, set allow_write = false. It costs one command per change and it is the right default for an installation you cannot afford to have an agent surprise you in. A profile override beats the file-wide setting, and ZABBIX_AI_CLI_MCP_ALLOW_WRITE beats both — that is how a container is told, without owning the config file.

With writes off, no tool and no flag applies anything: a change is described, and a person runs zabbix-ai-cli-mcp approve <plan-id> in their own terminal. A confirmation an agent could send would be a confirmation prompt injection could send, so none is offered — the approval lives outside the model's context.

With writes on, the agent applies the change itself and every change lands in an audit log with the profile, the parameters, the objects touched and whether a person or a model asked for it. zabbix-ai-cli-mcp mcp --read-only refuses both paths regardless of the setting, and an HTTP endpoint that can write refuses to start without a bearer token.

Everything else holds either way: a profile's scopes still bound what it may touch, the risk registry still refuses methods that hand out credentials or run code, and a plan is still re-checked against live Zabbix before it executes.

$ zabbix-ai-cli-mcp maintenance create "ms*" --for 2h

PLAN pl_cc89d2e87d15

Create maintenance "ms* (2h0m)" for 2h0m, 2026-08-21T05:39:00Z to 2026-08-21T07:39:00Z

Affects:
  host ms1.8qw.ru
  host ms10.8qw.ru
  ...

Risk: write
Expires: 2026-08-21T05:54:22Z

Nothing has changed yet.
To apply it: zabbix-ai-cli-mcp approve pl_cc89d2e87d15

Media channel state and lost LLD resource policies also use this approval/audit path. Media state requests are idempotent for external cron use; LLD plans show host scope and lost-item counts and flag history deletion as destructive. See parameters and examples.

Before a plan runs, its parameters are re-hashed, its deadline checked and its preconditions re-read from Zabbix. A window that has been replaced since the plan was made is refused, not deleted. Every applied change is appended to an audit log.

This matters more than a refusal would. When the tool this replaces blocked a write, the work was done anyway with a token copied out of a container — losing the audit trail without preventing anything. A permitted path that is recorded beats a refusal that gets routed around.

Example prompts

• Why did the disk alert on web01 never arrive?
• What is broken in Zabbix right now?
• Which monitored hosts has Zabbix been unable to poll?
• How did CPU on db01 look over the last day?