Skip to main content
Glama
Sign In
Zabbix MCP Server

Zabbix MCP Server

by initMAX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

task_get

Read-only

Retrieve and monitor Zabbix internal tasks, including diagnostic data collection and item value checks, to check the status of previously created work items.

Instructions

Retrieve tasks. Tasks are internal Zabbix work items such as diagnostic data collection requests or item value checks. Use this to monitor the status of previously created tasks.

Input Schema

NameRequiredDescriptionDefault
outputNoProperties of the task object to return. Pass 'extend' for all, or a list of property names. Default when omitted: taskid, type, status. Properties: clock, proxy_hostid (removed in 7.0), proxyid (7.0+), request, result, status, taskid, ttl, type.
serverNoTarget Zabbix server. Available: default. Defaults to 'default' if omitted.
taskidsNoReturn only tasks with the given IDs.
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.
extra_paramsNoOther native task.get parameters, merged into the request as-is. task.get has no parameters beyond the typed ones. Any other key is refused here, because Zabbix would silently ignore it. For a parameter you are sure exists on your release but is not listed, use zabbix_raw_api_call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.42.2
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / extra_params / anyOf
      Previous value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "propertyNames": {
+      "enum": [
+        "preservekeys"
+      ]
+    },
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / output / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "extend"
+    ],
+    "type": "string"
+  },
+  {
+    "items": {
+      "enum": [
+        "clock",
+        "proxy_hostid",
+        "proxyid",
+        "request",
+        "result",
+        "status",
+        "taskid",
+        "ttl",
+        "type"
+      ],
+      "type": "string"
+    },
+    "minItems": 1,
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / output / description
      Previous value: -"Properties of the task object to return. Pass 'extend' for all, 'count' for the number of matches only, or a comma-separated list of property names. Default when omitted: taskid, type, status. Properties: clock, proxy_hostid (removed in 7.0), proxyid (7.0+), request, result, status, taskid, ttl, type."New value: +"Properties of the task object to return. Pass 'extend' for all, or a list of property names. Default when omitted: taskid, type, status. Properties: clock, proxy_hostid (removed in 7.0), proxyid (7.0+), request, result, status, taskid, ttl, type."
    • removedInput schema / properties / proxyids
      Removed value: -{
-  "anyOf": [
-    {
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Return only tasks created on the given proxies.",
-  "title": "Proxyids"
-}
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "task_getOutput",
-  "type": "object"
-}New value: +null
  2. First observedv1.41.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered and the description correctly does not restate it. The added value is the explanation of what a Zabbix task actually is, which helps the agent interpret results, but there is no mention of task TTL/expiry, whether results are retained, or what status values mean. Note the important raw_json/bypass-of-prompt-injection-marker warning lives only in the schema, not the description.

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?

Three tight sentences, front-loaded with the action and immediately followed by the domain definition and usage cue. No filler or restated metadata; only minor room to compress the task examples.

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?

With five optional parameters, no output schema, and fully annotated schema descriptions, the description supplies the missing conceptual layer: what tasks are and why one polls them. The main gap is that it does not describe the task lifecycle (ttl, terminal statuses) or that results are keyed by taskid, which an agent needs to interpret a returned task object.

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 description coverage is 100% and every parameter (output, server, taskids, raw_json, extra_params) is documented in detail within the schema, including the default property set and the raw_json policy requirement. The description adds no parameter-level meaning at all, so the baseline 3 for a schema-complete tool is appropriate.

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 uses a specific verb and resource ('Retrieve tasks') and defines the domain object with examples ('internal Zabbix work items such as diagnostic data collection requests or item value checks'), which distinguishes it from data-retrieval siblings like item_get or history_get. It stops short of naming an alternative tool, but the resource is 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?

'Use this to monitor the status of previously created tasks' gives one clear use case and implies the tool is for follow-up polling rather than discovery. There is no guidance on when-not to use it, no exclusion of other *_get tools, and no mention that task IDs (taskids) are the natural handle for narrowing, which leaves the agent to infer usage from the schema.

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