Skip to main content
Glama
Sign In
Zabbix MCP Server

Zabbix MCP Server

by initMAX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

item_history_summary_get

Read-only

Retrieve item metadata, recent history points, and min/max/avg statistics in one call to answer trend and average-value questions for a Zabbix host item.

Instructions

Item metadata + last-N data points + min/max/avg statistics, in one call.

Use this for 'what was the average load on over the last hour?' / 'show me memory usage trend on '. Replaces the item_get + history_get + manual statistics loop the LLM has to write to answer trend questions.

Requires the item: its ID, or the host name together with the exact item key. The key is not derivable from the question ('memory usage' may be vm.memory.utilization, vm.memory.size[pused], ...): when it is not known, call item_get first (hostids or host filter, search on name or key_, output itemid, name, key_, units, value_type) and pass the itemid it returns.

Input Schema

NameRequiredDescriptionDefault
keyNoItem key, exact match on key_ (used together with host), e.g. 'system.cpu.load[all,avg1]'. An item key must be one that exists in Zabbix, never an invented one: when it is not known, resolve it with item_get (hostids or a host filter, search on name or key_; output itemid, name, key_, units, value_type) and use the key_ it returns.
hostNoTechnical host name, exact match (used together with key).
limitNoMax history points to include (default 100).
itemidNoItem ID (from item_get). Either itemid or (host + key) is required; prefer itemid once the item is known.
periodNoTime window (default '1h'). A number followed by h (hours), d (days) or m (months of 30 days), e.g. '1h', '6h', '7d', '30d'.1h
serverNoTarget Zabbix server. Available: default. Defaults to 'default' if omitted.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv1.42.2
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / host / description
      Previous value: -"Host name (used together with key)."New value: +"Technical host name, exact match (used together with key)."
    • changedInput schema / properties / itemid / description
      Previous value: -"Item ID. Either itemid or (host + key) must be supplied."New value: +"Item ID (from item_get). Either itemid or (host + key) is required; prefer itemid once the item is known."
    • changedInput schema / properties / key / description
      Previous value: -"Item key (used together with host)."New value: +"Item key, exact match on key_ (used together with host), e.g. 'system.cpu.load[all,avg1]'. An item key must be one that exists in Zabbix, never an invented one: when it is not known, resolve it with item_get (hostids or a host filter, search on name or key_; output itemid, name, key_, units, value_type) and use the key_ it returns."
    • changedInput schema / properties / period / anyOf
      Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^\\s*[0-9]+[hdmHDM]\\s*$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / period / description
      Previous value: -"Time window: '1h', '6h', '1d', '7d', '30d' (default '1h')."New value: +"Time window (default '1h'). A number followed by h (hours), d (days) or m (months of 30 days), e.g. '1h', '6h', '7d', '30d'."
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "_item_history_summary_getOutput",
-  "type": "object"
-}New value: +null
  2. First observedv1.41.0

TDQS

A4.1/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; the description adds that the call bundles metadata, raw points and aggregates rather than returning a bare series. It says nothing about response size, ordering, or what happens when the item has fewer points than the limit, which are the remaining behaviors an agent would want to know.

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?

It is front-loaded with the outcome, then the usage examples, then the input requirement, which is a sensible order. It is slightly long and repeats the item_get resolution instructions that also appear in the key and itemid schema descriptions, but no sentence is pure filler.

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 7 optional parameters, no output schema and no nested objects, the description does enough: it identifies the returned components (metadata, points, statistics) and how to satisfy identification. The only gap is the shape of the aggregated payload and any truncation behavior, which the absent output schema leaves to the description.

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%, so every parameter including the raw_json security trade-off is already documented in the schema. The description restates the itemid-vs-(host+key) requirement and the key-resolution flow, which is helpful reinforcement but not new meaning beyond the schema, so the 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?

The description opens with a specific composition of outputs ('Item metadata + last-N data points + min/max/avg statistics, in one call'), which is a concrete verb+resource statement an agent can match against siblings like item_get, history_get and trend_get. It also explicitly frames itself as a replacement for the multi-call loop, so the distinction from siblings is clear without opening a 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?

It gives concrete trigger questions ('what was the average load on <host> over the last hour?') and an explicit precondition/escalation path: when the item key is unknown, call item_get first with the stated filters and pass the returned itemid. It also warns that keys are not derivable from natural-language questions, which is exactly the when-not guidance an agent needs.

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