Skip to main content
Glama
Sign In
Zabbix MCP Server

Zabbix MCP Server

by initMAX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

capacity_forecast

Read-only

Forecast when a Zabbix metric will reach a threshold using historical trend regression, returning predicted date, daily growth rate, and confidence for capacity planning.

Instructions

Forecast when a metric will reach a threshold using linear regression on historical trend data. Returns predicted date, daily growth rate, and R-squared confidence. Useful for capacity planning (disk, CPU, memory).

Needs identifiers resolved beforehand: the host ID (host_get) and the key of a numeric item that exists on that host (item_get with hostids).

Input Schema

NameRequiredDescriptionDefault
hostidYesHost ID to analyze (from host_get; a host name is not accepted here)
periodNoHistorical period for regression (default: '30d'). A number followed by h (hours), d (days) or m (months of 30 days), e.g. '1h', '6h', '7d', '30d'.30d
serverNoTarget Zabbix server. Available: default. Defaults to 'default' if omitted.
item_keyYesItem key to forecast (e.g. 'vfs.fs.size[/,pused]', 'system.cpu.util'), matched as a substring of key_; the first enabled item that matches is used, so pass the full key. 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.
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.
thresholdNoValue threshold to predict when reached (default: 90.0)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.42.2
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / hostid / description
      Previous value: -"Host ID to analyze"New value: +"Host ID to analyze (from host_get; a host name is not accepted here)"
    • changedInput schema / properties / item_key / description
      Previous value: -"Item key to forecast (e.g. 'vfs.fs.size[/,pused]', 'system.cpu.util')"New value: +"Item key to forecast (e.g. 'vfs.fs.size[/,pused]', 'system.cpu.util'), matched as a substring of key_; the first enabled item that matches is used, so pass the full key. 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: -"Historical period for regression: '7d', '30d', '90d' (default: '30d')"New value: +"Historical period for regression (default: '30d'). 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": "_capacity_forecastOutput",
-  "type": "object"
-}New value: +null
  2. First observedv1.41.0

TDQS

A3.9/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 safety is covered. The description adds useful behavior beyond that: the three return values and the hard requirement that identifiers be resolved before calling. It says nothing about failure modes (e.g., insufficient history for regression) or how the substring match on item_key behaves if multiple items match, which the schema only partially hints at.

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?

Two short paragraphs: purpose plus return values first, then the prerequisite workflow. Front-loaded and free of filler, though the identifier-resolution sentence restates what the schema already spells out at length.

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 no output schema, the description carries the burden of explaining returns and does so explicitly (predicted date, growth rate, R-squared). Combined with 100% schema coverage of all six parameters and read-only annotations, an agent has what it needs; only edge-case behavior is left unaddressed.

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 period, server, threshold and raw_json is fully documented in the schema. The description's sentence about host_get/item_get largely duplicates the hostid and item_key schema descriptions rather than adding new semantics. Baseline 3 is appropriate.

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 and resource ('Forecast when a metric will reach a threshold using linear regression on historical trend data') and names the outputs (predicted date, daily growth rate, R-squared). This clearly separates it from read-oriented siblings like trend_get or history_get, which return raw data rather than a prediction.

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?

Gives concrete usage context ('capacity planning (disk, CPU, memory)') and an explicit pre-call workflow: resolve the host ID with host_get and the item key with item_get. It does not explicitly say when to prefer trend_get or anomaly_detect instead, so the exclusion half of the guidance is missing.

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