Skip to main content
Glama
Sign In
Zabbix MCP Server

Zabbix MCP Server

by initMAX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

graph_render

Read-only

Render a Zabbix graph as a PNG image and return a base64 data URI for multimodal AI models to display and interpret. Find graph IDs with graph_get first.

Instructions

Render a Zabbix graph as a PNG image. Returns a base64-encoded data URI that multimodal AI models can display and interpret directly. Use graph_get to find graph IDs first.

Input Schema

NameRequiredDescriptionDefault
widthNoImage width in pixels, 100-4096 (default: 800)
heightNoImage height in pixels, 50-2048 (default: 200)
periodNoTime period (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.
graphidYesZabbix graph ID (numeric)
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. Changed4 schema fields changedv1.42.2
    • addedInput schema / additionalProperties
      Added value: +false
    • 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 period: '1h', '6h', '1d', '7d', '30d' (default: '1h')"New value: +"Time period (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": "_graph_renderOutput",
-  "type": "object"
-}New value: +null
  2. First observedv1.41.0

TDQS

A4.2/5.0
Behavior4/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 genuinely new behavior information by specifying the return payload is a base64 data URI directly interpretable by multimodal models. It does not discuss the raw_json prompt-injection tradeoff or error behavior, but that is documented in the schema property itself.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action and output type, followed by the return-format detail and the prerequisite. No filler and nothing repetitive of structured fields.

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 correctly compensates by explaining the return value, and the six-parameter schema is fully self-documenting. The only gap is the absence of any mention of the security/prompt-injection wrapper that shapes the default response, which matters for how an agent consumes the result.

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 (width, height, period, server, graphid, raw_json) has a rich inline description, so the baseline of 3 applies. The description adds no parameter-level detail of its own beyond the implicit link between graph_get results and the graphid argument.

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 ('Render a Zabbix graph'), the concrete output format ('PNG image', 'base64-encoded data URI'), and explicitly distinguishes itself from the sibling graph_get in the same breath. An agent can separate visualization from metadata retrieval 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear prerequisite workflow ('Use graph_get to find graph IDs first'), which is the main gating condition for calling this tool. It stops short of explicit when-not-to-use guidance (e.g., preferring text history/trend queries for programmatic analysis), so it is strong but not exhaustive.

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