zapi-mcp

get_problems

Read-only

Fetch active Zabbix problems newest first, with severity and tag filters, and report the true total while excluding disabled triggers unless requested.

Instructions

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. Problems whose trigger, host or item is disabled (for example a trigger silenced for a known outage) are left out, as the Zabbix frontend's Problems page also does, and the header says how many.

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) include_disabled: Also list problems whose trigger, host or item is disabled (default False, matching the Zabbix frontend)

Input Schema

Name	Required	Description	Default
`limit`	No
`tag_name`	No
`tag_value`	No
`min_severity`	No
`include_disabled`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.14.0Oct 18, 2026

addedInput schema / properties / include_disabled

Added value: +{
+  "default": false,
+  "title": "Include Disabled",
+  "type": "boolean"
+}

First observedv0.1.0Jul 31, 2026

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the read-only annotation by disclosing sorting, age annotation, capped-total reporting, default disabled-problem exclusion, and the second count query issued when the limit is reached. These are exactly the behavioral traits an agent needs to interpret results correctly. It adds substantial value over the structured annotations.

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 front-loaded with the core purpose and then structured into behavioral context and an Args block. The opening sentence and the next paragraph slightly repeat the newest-first ordering, but otherwise every sentence carries useful information. It is appropriately sized for a five-parameter tool.

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?

With an output schema present, the description need not explain return structures, and it correctly focuses on invocation and behavior. It covers all five optional parameters, default filtering behavior, and limit handling. Nothing material is missing for an agent to call this read-only listing tool correctly.

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 must carry all parameter meaning. It does so thoroughly: it explains min_severity values, tag filtering and the tag_value/tag_name dependency, limit flooring and count-query behavior, and include_disabled semantics. Every parameter is documented with enough detail to invoke the tool correctly.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: get active Zabbix problems. It also adds scope details such as newest-first ordering and disabled-problem exclusion. It does not explicitly distinguish itself from siblings like acknowledge_problem or daily_brief, so it falls short of a 5.

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?

Usage is implied: this is the tool for listing active problems, mirroring the Zabbix frontend Problems page. However, no explicit when-to-use or when-not guidance is given relative to alternatives such as acknowledge_problem or daily_brief. The reference to the frontend page provides modest context but not routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server