Skip to main content
Glama
Sign In
Zabbix MCP Server

Zabbix MCP Server

by initMAX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

host_status_get

Read-only

Retrieve a Zabbix host's identity, interfaces, monitored state, active Warning+ problems, and last eight item values in one JSON call to answer status or issue questions without follow-up queries.

Instructions

Single-call host status: identity + interfaces + monitored-state + active problems (severity Warning+, with disabled-trigger/host filtered out) + last 8 item values, in one self-contained JSON payload.

Use this whenever an operator asks 'what is the status of ?' or 'what is wrong on ?'. Replaces the typical 3-4 tool chain (host_get + hostinterface_get + problem_get + item_get) so a one-shot LLM prompt can answer without follow-up tool calls.

Input Schema

NameRequiredDescriptionDefault
hostNoZabbix host name. Tried as exact match first, falls back to substring search. One of host_id or host is required; the name is enough, no host_get call is needed first.
serverNoTarget Zabbix server. Available: default. Defaults to 'default' if omitted.
host_idNoZabbix host ID. One of host_id or host (the name) is required.
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 / host / description
      Previous value: -"Zabbix host name. Tried as exact match first, falls back to substring search."New value: +"Zabbix host name. Tried as exact match first, falls back to substring search. One of host_id or host is required; the name is enough, no host_get call is needed first."
    • changedInput schema / properties / host_id / description
      Previous value: -"Zabbix host ID. Either host_id or host (the name) must be provided."New value: +"Zabbix host ID. One of host_id or host (the name) is required."
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "_host_status_getOutput",
-  "type": "object"
-}New value: +null
  2. First observedv1.41.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), but the description adds genuinely new behavioral detail: problems are filtered to severity Warning+ with disabled-trigger/host records excluded, and only the last 8 item values are returned. What it does not disclose is the response shape or any size/pagination limits, which keeps it below a 5.

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?

Two compact paragraphs: the first front-loads what the payload contains, the second front-loads when to use it and what it replaces. No filler, no repeated information, and the most decision-relevant content comes first.

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?

There is no output schema, so the description carries the burden of describing the return value, and it does enumerate the bundled sections. It omits the exact JSON key structure and any indication of payload size or error behavior, which is a minor gap for a consolidated read tool.

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%, so every parameter including the host substring fallback and the raw_json security caveat is already documented in the schema. The description adds no parameter-level meaning beyond noting there is no need for a prior host_get lookup. Baseline 3 is appropriate when the schema carries the load.

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 names a specific verb and resource ('Single-call host status') and enumerates exactly what the payload bundles: identity, interfaces, monitored-state, active problems, last 8 item values. It explicitly distinguishes itself from the sibling chain host_get + hostinterface_get + problem_get + item_get, so an agent can tell which tool produces a consolidated status.

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 phrasing ('what is the status of <hostname>?', 'what is wrong on <hostname>?') and states the alternative it replaces, making the use/use-not decision explicit. This is about as clear as routing guidance gets.

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