zapi-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.9.2
Disambiguation4/5
Most 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness3/5
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.
Average 4.5/5 across 8 of 8 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 61 commits in the last 12 weeks
- Last stable release on August 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![zapi-mcp MCP server](https://glama.ai/mcp/servers/shigechika/zapi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/shigechika/zapi-mcp)

Score Badge

Copy to your README.md:

[![zapi-mcp MCP server](https://glama.ai/mcp/servers/shigechika/zapi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/shigechika/zapi-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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