Skip to main content
Glama
Sign In
Zabbix MCP Server

Zabbix MCP Server

by initMAX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

problem_active_get

Read-only

Retrieves active Zabbix problems where both trigger and host are enabled, filtering out stale alerts and low-severity noise. Use it to answer what is currently wrong or firing on a Zabbix server.

Instructions

Real, actionable problems right now -- the PRIMARY tool for an LLM asked "what is wrong on the Zabbix server?".

Returns only problems where BOTH the trigger AND the host are enabled, with severity Warning (2) or above. Skips the noise that problem_get would return: stale alerts on disabled triggers, problems on hosts that were taken out of monitoring but not deleted, and Information / Not classified events that operators do not act on.

Each problem comes back with the host name, severity_label ("warning", "high", "disaster", ...), and time rendered as a human-readable UTC string. Use this whenever the operator asks "active problems", "current issues", "what is firing", "real problems", or "skip disabled".

For an unfiltered raw view (e.g. to also see stale problems), use problem_get instead.

Returns {"problems": [...], "count": N, "filtered_out": M} where filtered_out = problems dropped due to disabled trigger/host.

Input Schema

NameRequiredDescriptionDefault
limitNoMax problems to return after filtering disabled triggers/hosts (default 50).
serverNoTarget Zabbix server. Available: default. Defaults to 'default' if omitted.
hostidsNoRestrict to problems on these hosts.
groupidsNoRestrict to problems on hosts in these host groups.
raw_jsonNoStrips the security disclaimer preamble from the response so it is pure JSON. Default: false. Requires the bearer token to have 'allow_raw_json' explicitly enabled by an operator in the admin portal - tokens without that policy receive a PolicyError instead. WARNING: setting true bypasses the prompt-injection mitigation marker that wraps untrusted Zabbix data (host names, item descriptions, problem text). LLM clients (Claude, GPT, Cursor, ...) should leave this false; only programmatic non-LLM consumers (Python scripts, n8n workflows that json.loads the result) should set true.
sortfieldNoProblem sort key; problem.get can only sort by 'eventid' (default). Event IDs grow with time, so this is also the chronological order.eventid
sortorderNo'ASC' or 'DESC' (default 'DESC').DESC
severitiesNoSeverity floor as a list of numeric codes. Default [2,3,4,5] (Warning and above). Pass [0,1,2,3,4,5] to include Information / Not classified.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.42.2
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / sortfield / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "eventid"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / sortfield / description
      Previous value: -"Problem sort key; problem.get can only sort by 'eventid' (default)."New value: +"Problem sort key; problem.get can only sort by 'eventid' (default). Event IDs grow with time, so this is also the chronological order."
    • changedInput schema / properties / sortorder / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "ASC",
+      "DESC"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "_problem_active_getOutput",
-  "type": "object"
-}New value: +null
  2. First observedv1.41.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint/openWorldHint, so the description carries the meaningful burden and does: it discloses the exact filter predicate (trigger AND host enabled, severity Warning or above), what is deliberately excluded (stale alerts, disabled hosts, Information/Not classified), and the shape and semantics of filtered_out. This is behavior the annotations cannot express.

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?

Front-loaded with the primary claim and the exclusion rules, then usage triggers, then the alternative. It is somewhat long and the severity/return paragraph partially overlaps with schema text, but no sentence is filler and the progression is logical.

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?

No output schema exists, so the description must describe returns, and it does precisely: {"problems": [...], "count": N, "filtered_out": M} with filtered_out defined. Combined with the filter rules and the sibling routing, an agent has everything needed to call and interpret this correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and every parameter is already documented in the schema, including the severities default [2,3,4,5] and the limit-after-filtering semantics. The description only restates the severity floor and adds output-field detail (host name, severity_label, human-readable UTC time) rather than new parameter meaning, so baseline 3 applies.

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?

States a specific verb+resource (retrieve currently active, actionable problems) plus the exact scope narrowing (both trigger and host enabled, severity >= Warning). It explicitly names the sibling problem_get and what that sibling would return instead, so an agent can distinguish the two without opening either schema.

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?

Gives explicit when-to-use signals ("what is wrong on the Zabbix server?", "active problems", "current issues", "what is firing", "skip disabled") and an explicit when-not/alternative ("For an unfiltered raw view ... use problem_get instead"). Nothing is left to inference.

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

Deploy Server

Other Tools