The zapi-mcp server integrates with Zabbix API to enable network operations monitoring and management. It provides tools to: verify server and Zabbix connectivity (health_check); generate a daily brief summarizing active problems by severity and configurable site-specific categories like DHCP/SNAT (daily_brief); query active problems with filtering and true totals (get_problems); list hosts by role/tag/group (get_hosts); retrieve current item values for a host (get_host_items); and acknowledge problems without closing them (acknowledge_problem). It supports version-adaptive authentication, CLI flags for health check/config validation/direct brief output, and features like stale-problem folding and truncation indicators.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@zapi-mcp show me the daily brief"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
English | 日本語
MCP (Model Context Protocol) server for the Zabbix API.
Built for network operations: a single daily_brief call summarizes active
problems plus site-specific categories (DHCP pool usage, SNAT session usage,
core-network problems, …), and individual tools query problems, hosts, and item
values. Organization-specific tags live in a config file, not the code, so the
server stays generic.
Version-adaptive auth: works against Zabbix 6.0 LTS (user + auth field) and
forward-compatible with 6.4 / 7.0 (username + Authorization: Bearer).
Documentation: https://shigechika.github.io/zapi-mcp/
Tool | Description |
| Server version, Zabbix connectivity/auth, detected API version, and configured |
| Morning patrol: active problems (Warning+), hosts currently in maintenance, plus one section per configured category |
| Active problems by severity and tag, newest-first with age; header shows the true total ( |
| List hosts filtered by role/tag/group, with IP and tags |
| Current item values for a host (server-side host filter) |
| Acknowledge problems and add a message (does not close them) |
| Open an idempotent Zabbix maintenance window, selecting hosts by |
| List maintenance windows (Active/Upcoming/Expired) — cross-check before treating another tool's alert as a new incident |
Related MCP server: DevHelm MCP Server
# uv
uv pip install zapi-mcp
# pip
pip install zapi-mcpOr from source:
git clone https://github.com/shigechika/zapi-mcp.git
cd zapi-mcp
# uv
uv sync
# pip
pip install -e .Set the following environment variables:
Variable | Description | Default |
| Zabbix base URL (e.g. | required |
| Zabbix API user | required |
| Zabbix API password | required |
| Path to a categories INI file for | — |
|
|
|
| Max active problems |
|
The API user needs read permission for the host groups you query, plus
acknowledge permission if you use acknowledge_problem, maintenance-write
permission if you use set_maintenance, and maintenance-read permission
(usually included by default) for get_maintenance_windows and the
daily_brief "In Maintenance" section.
daily_briefProblems are grouped by severity and listed newest-first, each annotated with
its age (e.g. 3h ago). Problems older than the recent window
(ZABBIX_BRIEF_RECENT_HOURS, default 24h) are folded to a single
… and N older (stale; oldest …) line — so a backlog of alerts that Zabbix
keeps active because their recovery is never auto-confirmed (ICMP ping down, RDP
down, …) doesn't bury what just happened. Section headers carry the true total
and show showing N of TOTAL when the fetch is capped, never a silent truncation.
daily_briefRight after Active Problems, daily_brief lists hosts covered by a
maintenance window that's active now, plus any window starting later today —
so a planned outage isn't mistaken for a new incident by whatever else is
watching those hosts. The ## In Maintenance section is omitted entirely
when there's nothing to show (no news is no maintenance). Windows starting
tomorrow or later, and expired windows, aren't included here; call
get_maintenance_windows (optionally with include_expired=True) for the
full picture.
daily_brief (optional)daily_brief always lists active problems. To add site-specific sections —
DHCP pool exhaustion, SNAT session usage, core-network problems — point
ZABBIX_CATEGORIES_INI at an INI file. Each [section] is one category:
[dhcp]
name = DHCP Pool Usage
# Zabbix host tag identifying the group
tag = dhcp-pool-usage
# report current values for this exact item key
item_key = usage
# flag values >= this
threshold = 80
[snat]
name = SNAT Session Pool
tag = snat-pool-usage
# substring match (catches pool.node0.usage etc.)
item_key_search = .usage
threshold = 80
[core]
name = Core Network
tag = role
# the tag must equal this value
tag_value = main
# no item key -> report active problems insteadtag (required): host tag identifying the category. With tag_value, the tag
must equal it (Equal); without, any host carrying the tag matches (Exists).
item_key / item_key_search: when either is set, the section reports current
item values sorted high-to-low. item_key matches the key exactly; use
item_key_search for keys that embed an id (e.g. .usage catches
pool.node0.usage). When neither is set, it reports active problems for the tag.
threshold: optional; values at or above it are flagged.
See categories.ini.example. When the variable is
unset or the file is missing, daily_brief reports active problems only.
Two tools change state. Everything else only reads.
Tool | Zabbix API call |
|
|
|
|
acknowledge_problem needs acknowledge permission on the API user;
set_maintenance needs maintenance-write permission. Leave either off and
the server stays read-only for that one tool: the call fails against the
Zabbix API and every other tool keeps working, so an API user can be handed
to Claude for investigation without granting it any ability to change Zabbix
configuration. Grant the permission only when acknowledging alerts or opening
maintenance windows from Claude is part of the job.
This repository doubles as a single-plugin marketplace, so Claude Code can install the server for you:
/plugin marketplace add shigechika/zapi-mcp
/plugin install zapi-mcp@zapi-mcpThe plugin launches uvx zapi-mcp and reads the same environment variables
described in Configuration; export them before starting
Claude Code. ZABBIX_CATEGORIES_INI may stay unset.
uvx must be on the PATH of the process that runs Claude Code — a login
shell usually has it, but a GUI-launched app may not; install
uv system-wide if the plugin fails to start.
Add to .mcp.json:
{
"mcpServers": {
"zapi-mcp": {
"type": "stdio",
"command": "zapi-mcp",
"env": {
"ZABBIX_URL": "https://zabbix.example.com",
"ZABBIX_USER": "api-user",
"ZABBIX_PASSWORD": "",
"ZABBIX_CATEGORIES_INI": "/path/to/categories.ini"
}
}
}
}Add to claude_desktop_config.json:
{
"mcpServers": {
"zapi-mcp": {
"command": "zapi-mcp",
"env": {
"ZABBIX_URL": "https://zabbix.example.com",
"ZABBIX_USER": "api-user",
"ZABBIX_PASSWORD": ""
}
}
}
}export ZABBIX_URL=https://zabbix.example.com
export ZABBIX_USER=api-user
export ZABBIX_PASSWORD=your-password
zapi-mcpzapi-mcp --version # Print version and exit
zapi-mcp --check # Verify environment variables and authentication, then exit
zapi-mcp --brief # Print the daily_brief to stdout and exit (handy for cron)
zapi-mcp # Start MCP server (STDIO, default)--check exit codes: 0 success, 1 config error, 2 auth/connection error.
--brief exit codes: 0 success, 1 a section failed (auth, the active-problems
fetch, or category loading — see the embedded Error: line in the output).
git clone https://github.com/shigechika/zapi-mcp.git
cd zapi-mcp
# uv
uv sync --dev
uv run pytest -v
uv run ruff check .
# pip
python3 -m venv .venv
.venv/bin/pip install -e . && .venv/bin/pip install pytest pytest-cov respx ruff
.venv/bin/pytest -v
.venv/bin/ruff check .pytest checks logic against fixtures; it cannot tell you that a tool has
stopped returning real data. scripts/smoke_test.py runs every registered
tool against the configured Zabbix and fails on empty, malformed or error
answers:
# needs the same ZABBIX_* environment variables as the server
uv run python scripts/smoke_test.py
uv run python scripts/smoke_test.py --only get_problems --tracebackRead-only. acknowledge_problem and set_maintenance are skipped by
name — an acknowledgement is visible to every operator and cannot be
quietly undone, and set_maintenance opens a real maintenance window that
suppresses alerts — and a test enforces that. The report prints tool names
and statuses only, never
payloads; server-authored error text is redacted too, since Zabbix quotes the
host it was asked about. --traceback still shows the full text on the
operator's own terminal.
Arguments that would identify real hosts, groups or tag values are
discovered at run time, never written into scripts/smoke_probes.py.
Two tests enforce that: one refuses those parameters as literals, the other
bans anything address-shaped (mail address, URL, hostname, IPv4, IPv6)
anywhere in the file.
An empty answer is a real observation here — a monitoring system with nothing wrong is the goal — so probes assert the envelope the tool must produce rather than a row count.
CI enforces the cheap half: a tool registered without a probe spec fails the
build (tests/test_smoke_probes.py), so adding a tool forces the question
"how would we know it works?".
scripts/smoke_harness.py is the engine and holds no Zabbix knowledge: it is
kept identical across the servers that share it, so fix engine bugs once and
sync the file rather than patching this copy.
Releases are automated with release-please.
Merging Conventional Commits (feat:, fix:, …)
to main keeps a release PR open with the next version and changelog. Merging
that PR tags vX.Y.Z and publishes a GitHub Release, whose release: published
event triggers the release workflow to build and publish to PyPI and the MCP
Registry. release-please owns the version in zapi_mcp/__init__.py and
server.json (do not bump them by hand).
The release-please workflow should be given a repository secretRELEASE_PLEASE_TOKEN (a PAT with contents: write + pull-requests: write).
The default GITHUB_TOKEN cannot create the Release that triggers the
downstream release workflow (GitHub blocks workflow runs triggered by
GITHUB_TOKEN), so without the PAT nothing gets published. The workflow falls
back to GITHUB_TOKEN when the secret is unset so PR CI keeps working on forks.
Streamable HTTP transport + OAuth2 for remote / mobile use
Visual rendering of key metrics
MIT
Acknowledge Zabbix problems and add a message (does not close them).
Args: event_ids: Comma-separated event IDs (from get_problems output) message: Acknowledgement message
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| event_ids | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the key behavioral trait (does not close the problem), but it lacks details on permissions, idempotency, or state changes beyond acknowledging. For an unannotated tool, this is only partially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences plus a compact Args block. It is front-loaded with the main purpose, and every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with an output schema and no annotations, the description explains the inputs and the primary behavioral limitation. It could mention prerequisites or effects, but the core context is present, making it sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only names and types, with 0% coverage, so the description must add meaning. It does: event_ids are described as 'Comma-separated event IDs (from get_problems output)' and message as 'Acknowledgement message'. This compensates well for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Acknowledge Zabbix problems') and adds a crucial caveat ('does not close them'), which distinguishes it from potential close operations. It also lists the key arguments, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides contextual guidance by noting that event_ids come 'from get_problems output', indicating a direct workflow with a sibling tool. It does not explicitly state when not to use it, but the caveat 'does not close them' implies it is not a replacement for a closing operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Morning patrol summary.
Reports active problems (Warning and above), hosts currently in maintenance, then one section per category configured via ZABBIX_CATEGORIES_INI (e.g. DHCP pool usage, SNAT session usage, core-network problems). Item-based categories show current values sorted high-to-low; problem-based categories list active problems.
Problems are listed newest-first with their age; those older than the recent window (ZABBIX_BRIEF_RECENT_HOURS, default 24h) are folded to a count so a long-standing backlog of un-recovered fossils doesn't bury today's events. Section headers show the true total ('showing N of TOTAL' when capped).
The "## In Maintenance" section lists windows that are active now, plus windows starting later today -- cross-check these hosts before treating another tool's alert about them as a new incident. No section means no host is currently (or about to be, today) under a registered maintenance window; see get_maintenance_windows for the full picture including tomorrow-or-later and expired windows.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It specifies sorting (newest-first), age display, the folding of older problems into a count, section headers showing true totals, and that maintenance includes windows starting later today. This is rich, non-obvious behavioral detail beyond what any schema could imply.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with 'Morning patrol summary' and then structured into logical paragraphs: content, ordering/capping behavior, and maintenance interpretation. Each sentence adds essential operational meaning; no filler or repetition. The length is justified by the need to explain non-obvious capping and maintenance semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no parameters and an output schema exists, the description focuses on what the agent cannot infer: section semantics, sorting, capping behavior, and the interpretation of a missing maintenance section. It also cross-links to get_maintenance_windows for extended data, making it a self-contained guide for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (input schema is empty), so the description has no parameters to explain. It adds useful context by mentioning ZABBIX_CATEGORIES_INI and ZABBIX_BRIEF_RECENT_HOURS as configuration influences, which helps the agent understand the tool's variability. Per the rubric, 0 params earns a baseline of 4, and the description adds a bit on top.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Morning patrol summary' and clearly specifies it reports active problems (Warning and above), hosts in maintenance, and category-configured sections. This distinctively positions it as an aggregate/overview tool, differentiating it from siblings like get_problems and get_maintenance_windows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage context, advising to cross-check maintenance entries before treating alerts as new incidents, and explicitly directs to get_maintenance_windows for a fuller maintenance picture. It lacks an explicit 'when to use this vs. alternatives' statement for the general summary purpose, but the morning patrol framing and cross-references effectively imply usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current item values for a host.
Args: host: Hostname (exact match) search: Filter items by name (partial match)
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | ||
| search | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states it retrieves values but does not disclose potential errors for unknown hosts, pagination, authentication requirements, or whether results are sorted. The 'exact match' and 'partial match' notes are more about parameter semantics than behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one opening sentence and two bullet-style argument explanations. Every sentence earns its place, and it's front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and an output schema exists, so return format need not be described. However, there's no usage context or edge-case handling mentioned, and the absence of annotations leaves the safety profile unclear. It's adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by adding matching behavior: 'host' is exact match and 'search' is partial match by name. This adds meaning beyond the schema's bare type definitions, though it doesn't explain formats like FQDN vs IP or regex support.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Get current item values for a host.' This distinguishes it from siblings like get_hosts (listing hosts) and get_problems (problems), so it's unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention any exclusions or recommend when get_host_items is preferable to siblings. Users must infer from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Zabbix hosts filtered by tag or group.
Args: role: Filter by role tag value (e.g. 'main', 'edge') tag_name: Filter by arbitrary tag name tag_value: Filter by tag value (requires tag_name) group: Filter by host group name
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | ||
| group | No | ||
| tag_name | No | ||
| tag_value | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the read-only nature via 'List' and the tag_value/tag_name dependency. However, it doesn't explain how filters interact (AND/OR), what happens with no filters, or return format/pagination, which could be relevant behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line purpose followed by a compact argument list. Every sentence contributes value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and parameters, and an output schema exists to explain return values. However, it leaves out important context about how filters combine and the default behavior when no filters are provided, which could affect expected results. The simplicity of the tool mitigates this gap somewhat, but it's still incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates fully by explaining each parameter: role with examples, tag_name as arbitrary tag, tag_value requiring tag_name, and group by host group. It adds necessary meaning and constraints that the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'List Zabbix hosts filtered by tag or group', which clearly states the verb and resource. It distinguishes from siblings like get_host_items and get_problems, which cover different resources. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing hosts with optional filters, but provides no explicit guidance on when to use this tool versus alternatives. It doesn't mention exclusions or contrast with get_host_items or get_problems, leaving the decision to the agent based on the resource type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Zabbix maintenance windows -- the read counterpart to set_maintenance.
Use this to cross-check anomalies reported by OTHER tools (e.g. device unreachability, AP-offline reports) before treating them as new incidents: a host in an Active window is one Zabbix is currently suppressing new problem notifications for, because someone (or set_maintenance) registered a planned outage covering it.
Windows are grouped Active / Upcoming (and Expired when requested). "Active" means the current time falls inside the window's own time period, not just its outer active_since/active_till frame -- exact for a one-time window (the kind set_maintenance/set_maintenance_for_hosts create). A window with a recurring time period (set up outside this server) is instead evaluated against its outer frame only and labeled "(recurring)", since precise recurrence evaluation isn't implemented.
Times are the MCP server process's local timezone (same caveat as set_maintenance's since/till).
Args: include_expired: Also list windows whose active_till has passed (default False -- set_maintenance never deletes windows, so expired ones accumulate over time and are noise by default).
| Name | Required | Description | Default |
|---|---|---|---|
| include_expired | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels: it discloses the precise definition of 'Active' (current time inside the window's own time period vs. outer frame), the special handling and labeling of recurring windows, the timezone caveat, and the fact that expired windows accumulate because set_maintenance never deletes them. This is rich, non-obvious behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average but every sentence earns its place: the purpose, usage scenario, behavioral nuances, and parameter explanation are all necessary. It is front-loaded with the main purpose, uses paragraph breaks effectively, and ends with a clear 'Args' section. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a read-only list tool with one optional boolean parameter and an output schema, the description covers all essential context: the parameter's meaning and default, the distinction between Active/Upcoming/Expired, the recurring-window caveat, timezone, and the accumulation of expired windows. Nothing important is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameter, and it does thoroughly: include_expired is defined as 'Also list windows whose active_till has passed,' the default is stated, and the rationale (expired ones accumulate over time and are noise by default) adds meaningful context beyond the schema's bare boolean type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'List Zabbix maintenance windows' and explicitly positions it as 'the read counterpart to set_maintenance,' which distinguishes it from sibling tools. The purpose is immediately clear and not a mere tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit use case: cross-check anomalies from other tools before treating them as new incidents, with a concrete example (device unreachability, AP-offline reports). It also explains when Active windows matter and contrasts with set_maintenance, giving clear contextual guidance without needing to list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get active Zabbix problems, newest first.
Problems are listed newest-first and annotated with their age. The header
shows the true total ('showing N of TOTAL' when the result is capped by
limit), so a capped listing is never mistaken for the full picture.
Args: min_severity: Minimum severity (0=Not classified, 1=Info, 2=Warning, 3=Average, 4=High, 5=Disaster) tag_name: Filter by tag name (optional) tag_value: Filter by tag value (optional, requires tag_name) limit: Maximum number of problems to return (floored at 1; when the result hits this cap a second count query is issued to report the true total)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| tag_name | No | ||
| tag_value | No | ||
| min_severity | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and delivers it: it discloses ordering (newest-first), age annotation, the cap behavior with true total reporting, the floor on limit, and the dependency between tag_value and tag_name. This goes well beyond the schema and gives the agent critical behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a front-loaded purpose and a clear Args section. It is slightly verbose, repeating 'newest first' in the opening and second paragraph, but every sentence otherwise contributes useful information about result behavior and parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so the description need not detail return fields. It covers all parameters, explains the cap and total behavior, and provides enough context for a 4-parameter read-only tool. The only minor gap is the lack of explicit alternative-tool guidance, but that is addressed in the usage dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully by explaining every parameter: min_severity with severity levels, tag_name, tag_value (with dependency), and limit (with floor and cap behavior). This adds substantial meaning beyond the raw schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get active Zabbix problems, newest first' with a specific verb and resource. It naturally differentiates from sibling tools like get_hosts and acknowledge_problem by focusing on problem retrieval rather than host inventory or mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when active Zabbix problems are needed, but it does not explicitly contrast with sibling tools or provide exclusion criteria. There is clear context about the tool's behavior, but no mention of when to prefer this over alternatives such as get_hosts or health_check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report server version, Zabbix connectivity, and configured categories.
Call this at session start (or after a tool-call timeout) to confirm the MCP is up, see which version is running, verify the Zabbix backend is reachable and authenticated, and list the daily_brief categories that are loaded. Lightweight: it authenticates once (reusing the cached session) and reads the detected API version — it does NOT scan problems or items.
Always returns the same keys: status (healthy / degraded / error),
service, version, zabbix_url, zabbix_api_version (None until a
backend connection succeeds), auth (ok / error / missing-env), and
categories (the configured daily_brief section names). On a degraded or
error result, detail carries the reason and categories_error the
category-parse failure (when that is the cause).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It details that the tool authenticates once, reuses the cached session, reads the detected API version, and returns a fixed set of keys with specific conditions (e.g., zabbix_api_version is None until a backend connection succeeds, degraded/error results include a detail reason). This provides a complete model of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-line summary, followed by a usage paragraph and then a return-keys breakdown. While longer than typical, every sentence adds value—especially given there is no output schema to explain the return format. The structure is logical, skimmable, and free of fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless health-check tool with no output schema, the description is remarkably complete. It explains the exact return keys, possible values, error cases, and behavior (e.g., not scanning problems/items). The agent can confidently invoke it and parse the result without any ambiguity, even without additional structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. The rubric sets a baseline of 4 for parameterless tools, and the description adds no parameter-specific semantics because there are none. It does clarify that the tool reads environment state (auth can be missing-env), which is useful contextual information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource statement: 'Report server version, Zabbix connectivity, and configured categories.' This clearly distinguishes health_check from siblings like get_problems, and explicitly notes it does NOT scan problems or items, eliminating any ambiguity about its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to call it: 'Call this at session start (or after a tool-call timeout) to confirm the MCP is up...' It also contrasts with heavier operations by noting it is lightweight and does not scan problems or items, giving the agent clear usage context and effectively differentiating it from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Zabbix maintenance window, selecting hosts by location tag OR by explicit host name (exactly one of the two -- not both, not neither).
Unlike acknowledge_problem (which only marks existing problems as seen), this suppresses NEW problem notifications for the matched hosts during the window.
IMPORTANT -- idempotency key is name + since (not the target): the two
selection modes (location vs. hosts) can't collide with each other, but
within the SAME mode, calling again with the same name/since always
returns the FIRST window created under that name/since, even if this
call's location/hosts is different. A second call with a different
target but a name/since that collides with an earlier one (same mode)
silently protects nothing for the new target (no error, no window
created for it) -- pick a name that uniquely identifies the actual
target whenever more than one maintenance might be open around the same
time (shigechika/zapi-mcp#59).
IMPORTANT -- since/till are naive local-server-time strings: parsed and converted via the MCP server process's own timezone, not a fixed zone. If the server doesn't run in the timezone you mean, convert first.
Args: since: Window start, "%Y/%m/%d %H:%M:%S" (e.g. "2026/08/10 11:00:00"), interpreted in the MCP server process's local timezone till: Window end, "%Y/%m/%d %H:%M:%S", same timezone caveat as since name: Maintenance window name prefix (the start time is appended). Also the idempotency key together with since -- see above description: Free-text reason, shown in the Zabbix UI location: Value of the hosts' "location" tag to match (e.g. "CIT"). Mutually exclusive with hosts. hosts: Comma-separated exact host (technical) names, for when the affected hosts don't share a location tag or precise host-level control is wanted. No per-port selection. Mutually exclusive with location.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| till | Yes | ||
| hosts | No | ||
| since | Yes | ||
| location | No | ||
| description | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses idempotency behavior (keyed on name+since, not target), silent failure on collision, timezone handling for since/till, and the mutual exclusivity of selection modes. This exceeds expectations for behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place, covering critical caveats like idempotency, timezone, and selection constraints. It is well-structured with clear warnings and examples, appropriate for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers selection modes, idempotency, timezone, and all parameter semantics. With an output schema present, return values need not be described. There are no significant gaps for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain every parameter, and it does. It provides format and timezone for since/till, idempotency and prefix behavior for name, meaning of description, and mutual exclusivity with examples for location and hosts. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Zabbix maintenance window and specifies the two mutually exclusive host selection modes (location tag or explicit host names). It also differentiates from sibling acknowledge_problem by stating its unique function of suppressing NEW problem notifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with acknowledge_problem, telling when to use this tool over an alternative. It also provides clear selection constraints (exactly one of location/hosts) and advice on naming to avoid idempotency collisions, which guides appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.9.0get_maintenance_windowsv0.8.0set_maintenancev0.1.0acknowledge_problemdaily_briefget_host_itemsget_hostsget_problemshealth_checkMost tools map to distinct resources and actions: health_check is clearly separate, get_problems vs daily_brief could overlap but daily_brief is a curated summary while get_problems is a raw list, and the maintenance/host tools have clear boundaries. Minor overlap between daily_brief and get_problems is clarified by descriptions.
The majority follow a verb_noun pattern (get_problems, get_hosts, acknowledge_problem, set_maintenance), but health_check and daily_brief are noun phrases, and number agreement is inconsistent (problem vs problems). No mixing of snake_case/camelCase, so the overall consistency is good but not perfect.
8 tools is well-scoped for a Zabbix operations server, covering health checks, problem listing/acknowledgment, host inventory, item values, and maintenance windows without excessive overlap or bloat.
Core read and write operations are present (list problems, ack, create maintenance, list maintenance), but there is no delete_maintenance to reverse set_maintenance, nor an unacknowledge_problem, leaving lifecycle gaps in the maintenance and acknowledgment workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Remote MCP server for managing Muninx tickets, messages, ticket search, and support analytics.
Read-only MCP server for AIStatusDashboard status, incidents, metrics, and fallback recommendations.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for Linear project management and issue tracking
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/shigechika/zapi-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
