# Reported issues for Zabbix API MCP

Pod holds 11 of 11 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [Zabbix API MCP](/mcp/zabbix-api-mcp).

## Most discussed

### set_maintenance: comma/whitespace-only hosts bypasses this tool's own validation

\`set_maintenance\`'s \`location\`/\`hosts\` normalization strips and rejects a wholly empty or whitespace-only string (fixed in #57), but a string that's non-empty after stripping yet resolves to zero real host names after splitting -- e.g. \`hosts="   ,   "\` -- still passes the "exactly one of location/hosts" check here.

Not a silent-success bug: the resulting empty \`host_list\` is passed to \`zapi_lib.ZapiClient.set_maintenance_for_hosts([])\`, which raises \`ZapiError("... requires at lea

[Read the thread](https://github.com/shigechika/zapi-mcp/issues/58) · 2026-08-10 · closed · 2 comments

### Pre-public audit: review for sensitive data (secrets / PII / org-specific settings)

## Goal

Before making this repository public, audit the **current tree and the entire git history** for any secrets, third-party personal data, real infrastructure identifiers, or organization-specific settings. Once clear, proceed with going public.

> Note: All concrete sensitive values are **redacted** below and described only by category, so this audit issue does not itself leak the data it tracks.

## Method

Multi-agent audit across 5 dimensions (secrets / pii / infra / org-config / docs-

[Read the thread](https://github.com/shigechika/zapi-mcp/issues/3) · 2026-06-01 · closed · 1 comment

### daily_brief: stale fossil alerts crowd Active Problems — want recency-focused display

> Recreated from the pre-public repository (history was reset before going public). Original was in Japanese; translated here. Resolved by #3 / #4.

## Problem

`daily_brief`'s Active Problems lists *all* currently-active problems per severity. In Zabbix, liveness alerts whose recovery is not auto-confirmed (e.g. "Unavailable by ICMP ping", "RDP service is down") can stay active for months or years, so problems from long ago pile up under High / Average and **bury the day's real operational anom

[Read the thread](https://github.com/shigechika/zapi-mcp/issues/1) · 2026-06-01 · closed · 1 comment

### docs: set_maintenance has no docs/reference.* entry

## Problem

`docs/reference.md` / `docs/reference.ja.md` document every read-only tool plus `acknowledge_problem`, but `set_maintenance` — the only other write tool — has no entry in either file. It ships without a documented output format, argument semantics, or the write-tool caveats that `acknowledge_problem`'s entry calls out (visibility, irreversibility).

## Context

Noticed while adding `get_maintenance_windows` (#63) as the read counterpart to `set_maintenance`. The new tool's docs expli

[Read the thread](https://github.com/shigechika/zapi-mcp/issues/65) · 2026-08-11 · closed · 0 comments

### set_maintenance に期間上限が無く、遠い未来の till で長期間アラート抑制されうる

## 背景

`shigechika/zapi-mcp` の `set_maintenance` ツールは `till` に任意の未来日時を渡せる。呼び出し元（例: `slack-mcp-bridge`）が承認ゲート等の人間チェックを挟んでいても、それは目視確認どまりで機械的な歯止めではない。`till` に例えば2037年のような遠い未来を指定した呼び出しが承認されてしまうと、対象ホスト（`location` タグ一致の場合は多数になりうる）のアラートが何年も抑制され続ける。加えて、現状 `set_maintenance` を取り消す（メンテナンスウィンドウをキャンセルする）ツールが無いため、一度作成すると `till` を迎えるまで手動でZabbix UI等から消すしかない。

NichidaiSRE PR#328（`slack-mcp-bridge` のWRITE_TOOL_WHITELISTに`set_maintenance`追加）のai-reviewで指摘された（advisory、blockingではない）。

## 提案

以下のいずれか、または組み合わせ:

- `set

[Read the thread](https://github.com/shigechika/zapi-mcp/issues/62) · 2026-08-10 · open · 0 comments

### set_maintenance: reset_client() and generic-KeyError catch mislabel pure-validation errors

Two related, pre-existing patterns in this file that \`set_maintenance\` (#57) exercises through a new code path:

1. **\`except ZapiError as e: reset_client()\`** fires even when the \`ZapiError\` came from pure local validation with zero network I/O -- e.g. \`zapi_lib._parse_maintenance_time\` raises \`ZapiError\` on a malformed \`since\`/\`till\` string before any \`self._call()\`, and \`_resolve_hostids_by_name\`'s empty-list guard does the same. Every *other* tool's \`ZapiError\` has always

[Read the thread](https://github.com/shigechika/zapi-mcp/issues/60) · 2026-08-10 · open · 0 comments

### set_maintenance: idempotency key (name+since) doesn't include the actual target

\`set_maintenance\`'s idempotency key is \`name\` + \`since\` + a tag/host mode suffix only (\`zapi_lib.ZapiClient._create_maintenance_window\`, shigechika/zapi-lib#26) -- it never includes the \`location\` value or the \`hosts\` list itself.

Two calls sharing the same \`name\`+\`since\` but a **different** target silently collide: the second call hits Zabbix's \`maintenance.get\`, finds the first call's window, and returns its id without creating anything for the new target and without validat

[Read the thread](https://github.com/shigechika/zapi-mcp/issues/59) · 2026-08-10 · open · 0 comments

### feat: exclude_hosts option in categories.ini to suppress known-normal hosts from daily_brief

## Problem

`daily_brief` flags every host whose item value crosses the category threshold. Some hosts are *known-normal* at extreme values — the typical case is a DHCP pool dedicated to static (fixed) address assignment: every address in the range is bound to a `host` entry, so the pool sits at 100% usage by design, forever. Each morning brief then reports it as a critical exhaustion, and downstream consumers (e.g. an automated patrol routine) keep escalating a false positive.

Today the only w

[Read the thread](https://github.com/shigechika/zapi-mcp/issues/49) · 2026-08-06 · open · 0 comments

## Most recent

### Add a live smoke test that exercises every registered tool

## Motivation

Unit tests check logic against fixtures. They cannot tell you that a tool users actually call has stopped returning real data — a tool that exists but does not work is worse than no tool.

This happened for real in `jquants-mcp`: the earnings-calendar tools returned well-formed **empty** results for every query while the whole suite stayed green (shigechika/jquants-mcp#523). A live smoke test was built there to close the gap, and on its first production run it found three defects,

[Read the thread](https://github.com/shigechika/zapi-mcp/issues/34) · 2026-07-25 · closed · 0 comments

### docs: user documentation site on GitHub Pages (family rollout)

## Summary

Roll out the family documentation-site pattern to this repository: a task-oriented user guide on GitHub Pages, complementing the reference README.

Template (live example): https://github.com/shigechika/mcp-stdio — issue shigechika/mcp-stdio#284, scaffold PR shigechika/mcp-stdio#285, published at https://shigechika.github.io/mcp-stdio/ (Japanese at `/ja/`).

## Steps

1. Copy the three-piece scaffold from mcp-stdio and adapt:
   - `mkdocs.yml` — change `site_name` / `site_url` / `rep

[Read the thread](https://github.com/shigechika/zapi-mcp/issues/12) · 2026-07-02 · closed · 0 comments

### Exit cleanly on ^C instead of dumping an anyio teardown traceback

## Observed

Launching `zapi-mcp` interactively by mistake and pressing ^C dumps a 78-line anyio teardown traceback ending in `KeyboardInterrupt` (measured on 0.5.0, macOS, Python 3.14).

## Expected

Silent clean exit, same as the sibling MCP servers (junos-mcp / eos-mcp / aruba-central-mcp / keycloak-mcp all exit 0 with zero stderr on SIGINT).

## Fix (fleet convention, see eos-mcp `__main__.py`)

```python
try:
    mcp.run()
except KeyboardInterrupt:
    os._exit(0)
```

Plus a subprocess-bas

[Read the thread](https://github.com/shigechika/zapi-mcp/issues/11) · 2026-07-02 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/shigechika/zapi-mcp/issues).