Skip to main content
Glama
initMAX

Zabbix MCP Server

item_get

Read-only

Retrieve Zabbix items to inspect metrics like CPU, memory, or disk usage per host. Filter by hosts, templates, triggers, or item IDs and choose returned fields.

Instructions

Retrieve items. Items are the individual data collection points in Zabbix - each item gathers a specific metric from a host (CPU usage, memory, disk space, etc.). Items belong to hosts and are bound to a host interface. Trigger expressions reference items by their keys to define alerting conditions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return.
filterNoReturn only results whose properties exactly match the given values (a single value or a list of values per key). Example: {"status": 0} or {"status": [0, 1]}. Keys: allow_traps, authtype, delay, enabled_lifetime (7.0+), enabled_lifetime_type (7.0+), evaltype, flags, follow_redirects, formula, granularity (8.0+), history, hostid, http_proxy, interfaceid, inventory_link, ipmi_sensor, itemid, jmx_endpoint, key_, lifetime, lifetime_type (7.0+), logtimefmt, lookback_limit (8.0+), master_itemid, name, name_resolved (7.0+), output_format, password, post_type, privatekey, publickey, request_method, retrieve_mode, snmp_oid, ssl_cert_file, ssl_key_file, ssl_key_password, state, status, status_codes, templateid, time_shift (8.0+), timeout, trapper_hosts, trends, type, units, url, username, uuid (6.0+), value_type, valuemapid, verify_host, verify_peer. Text properties cannot be filtered; use 'search' for them.
outputNoProperties of the item object to return. Pass 'extend' for all, 'count' for the number of matches only, or a comma-separated list of property names. Default when omitted: itemid, hostid, name, key_, status, value_type. Properties: allow_traps, authtype, delay, description, enabled_lifetime (7.0+), enabled_lifetime_type (7.0+), error, evaltype, flags, follow_redirects, formula, granularity (8.0+), headers, history, hostid, http_proxy, interfaceid, inventory_link, ipmi_sensor, itemid, jmx_endpoint, key_, lastclock, lastns, lastvalue, lifetime, lifetime_type (7.0+), logtimefmt, lookback_limit (8.0+), master_itemid, name, name_resolved (7.0+), output_format, parameters (6.0+), params, password, post_type, posts, prevvalue, privatekey, publickey, query (8.0+), query_fields, request_method, retrieve_mode, snmp_oid, ssl_cert_file, ssl_key_file, ssl_key_password, state, status, status_codes, templateid, time_shift (8.0+), timeout, trapper_hosts, trends, type, units, url, username, uuid (6.0+), value_type, valuemapid, verify_host, verify_peer.
searchNoReturn results whose string properties contain the given pattern (case-insensitive; '*' is a wildcard when searchWildcardsEnabled is true). Example: {"name": "web"}. Keys: delay, description, error, formula, granularity (8.0+), history, http_proxy, ipmi_sensor, jmx_endpoint, key_, lifetime, logtimefmt, lookback_limit (8.0+), name, name_resolved (7.0+), params, password, posts, privatekey, publickey, snmp_oid, ssl_cert_file, ssl_key_file, ssl_key_password, status_codes, time_shift (8.0+), timeout, trapper_hosts, trends, units, url, username, uuid (6.0+).
serverNoTarget Zabbix server. Available: default. Defaults to 'default' if omitted.
hostidsNoReturn only items that belong to the given hosts.
itemidsNoReturn only items with the given IDs.
groupidsNoReturn only items that belong to hosts in the given host groups.
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.
webitemsNoInclude web items (items created by web scenarios) in the result.
sortfieldNoSort by one or more of: itemid, name, key_, delay, history, trends, type, status (comma-separated for several; pair with 'sortorder'). No other property is sortable.
sortorderNoSort order: 'ASC' (ascending) or 'DESC' (descending).
triggeridsNoReturn only items used in the given triggers.
countOutputNoReturn the count of matching results instead of the actual data.
searchByAnyNoIf true, return results matching ANY search field (OR). Default is ALL fields (AND).
templateidsNoReturn only items that belong to the given templates.
extra_paramsNoOther native item.get parameters, merged into the request as-is. Parameters: evaltype (6.0+), graphids, group, host, inherited, inheritedTags (8.0+), interfaceids, limitSelects, monitored, proxyids, tags (6.0+), templated. Sub-object selects (value 'extend', 'count' or a list of property names): selectDiscoveryData (7.4+), selectDiscoveryRule, selectGraphs, selectHosts, selectInheritedTags (8.0+), selectInterfaces, selectItemDiscovery, selectPreprocessing, selectTags (6.0+), selectTriggers, selectValueMap (6.0+). Any other key is refused here, because Zabbix would silently ignore it. For a parameter you are sure exists on your release but is not listed, use zabbix_raw_api_call.
with_triggersNoOnly return items that are used in at least one trigger.
searchWildcardsEnabledNoIf true, enable * and ? wildcards in search patterns.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.41.0

TDQS

B3.1/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered and no destruction/auth risk needs spelling out. The description adds conceptual modeling context but no operational behavior: no mention of result size, pagination, default output shape, or that filtering is exact-match versus search. For a read-only tool this is a minor gap, but the description contributes nothing beyond annotations here.

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 sentences, front-loaded with the action and resource, then progressively narrowing to item-host-interface-trigger relationships. No filler or repetition, though the explanatory sentences lean generic rather than operational.

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?

For a zero-required-parameter, read-only list tool with a full output schema and complete per-parameter documentation, the description supplies enough domain framing to call it correctly. The only shortfall is the absent routing to sibling retrieval tools, which matters given how many *_get siblings exist.

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 the schema documents all 19 parameters thoroughly (filter vs search semantics, output defaults, sortfield allow-list, raw_json policy). The description adds no parameter-level meaning, so the baseline 3 is the correct ceiling when the schema does all the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ("Retrieve items") and then defines what an item actually is in Zabbix (a per-host metric collection point, bound to a host interface, referenced by trigger expressions). That is genuinely more informative than a bare name restatement. It never names or contrasts with the close siblings itemprototype_get, history_get, or item_history_summary_get, so the differentiation is left to the agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

There is no when-to-use guidance at all: nothing says when to prefer item_get over itemprototype_get (templates), history_get (values over time), or item_history_summary_get. The domain background (items belong to hosts, feed triggers) implies a retrieval context but does not route the agent between alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.