Skip to main content
Glama
Sign In
Zabbix MCP Server

Zabbix MCP Server

by initMAX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

hostgroup_overview_get

Read-only

Get a host group health roll-up in one call: member counts, active-problem severity breakdown, and top problematic hosts for daily health checks or group status questions.

Instructions

Host group health roll-up: member-host counts (total / enabled / with-problems) + active-problem severity breakdown + top-N most-problematic hosts inside the group, in one call.

Use this for 'how is the doing?' / 'give me a daily health report for ' style prompts. Replaces hostgroup_get + host_get(groupids=) + problem_get(hostids=) chain.

Requires the group: pass its exact name as 'group' (no lookup needed) or its ID as 'groupid'. Without either the call is refused; for all groups at once use infrastructure_summary_get.

Input Schema

NameRequiredDescriptionDefault
groupNoHost group name (exact match). One of groupid or group is required; the name is enough, no hostgroup_get call is needed first.
top_nNoNumber of most-problematic hosts to return (default 5).
serverNoTarget Zabbix server. Available: default. Defaults to 'default' if omitted.
groupidNoHost group ID. One of groupid or group (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 / group / description
      Previous value: -"Host group name (exact match)."New value: +"Host group name (exact match). One of groupid or group is required; the name is enough, no hostgroup_get call is needed first."
    • changedInput schema / properties / groupid / description
      Previous value: -"Host group ID. Either groupid or group (the name) must be supplied."New value: +"Host group ID. One of groupid or group (the name) is required."
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "_hostgroup_overview_getOutput",
-  "type": "object"
-}New value: +null
  2. First observedv1.41.0

TDQS

A4.6/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, but the description adds behavior beyond them: the required-name-or-ID gate that causes refusal, and the fact that one call replaces a three-call chain. It does not cover return shape or result size limits, and the raw_json security warning lives mostly in the schema rather than 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 short paragraphs that front-load the purpose, then usage, then the input requirement — every block is load-bearing. It restates the group/groupid requirement that the schema already encodes, which is minor redundancy but not bloat.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description carries return-value burden, and it does: counts, severity breakdown, and top-N host list. Combined with the usage triggers, the refusal condition, and the sibling alternative, an agent has everything needed to select and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so a baseline of 3 applies, but the description adds genuine value: 'exact name as group (no lookup needed)' clarifies the string must match exactly and that a prior hostgroup_get is unnecessary, and it pairs group with groupid as the either/or requirement. It adds nothing for top_n or server beyond what the schema already documents.

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 ('Host group health roll-up') and enumerates exactly what the payload contains: member-host counts (total/enabled/with-problems), severity breakdown, and top-N problematic hosts. It also names the sibling tools it supersedes (hostgroup_get + host_get(groupids=) + problem_get(hostids=)), so the agent can distinguish it from them without opening any 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?

Gives explicit trigger prompts ('how is the <hostgroup> doing?', 'daily health report for <group>') and names the alternative for a different need — infrastructure_summary_get for all groups at once. It also states the precondition: without group or groupid the call is refused, so the agent knows when the tool will fail rather than silently misbehave.

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