Skip to main content
Glama
initMAX

Zabbix MCP Server

action_get

Read-only

Retrieve Zabbix actions that define automated responses to events, filter by event source, and include operation definitions to inspect conditions and operations.

Instructions

Retrieve actions that define automated responses to Zabbix events. Actions tie conditions (e.g. trigger severity, host group membership) to operations (e.g. send message, execute script, close problem). Filter by event source to narrow results: 0=trigger, 1=discovery, 2=autoregistration, 3=internal, 4=service. Use selectOperations, selectRecoveryOperations, selectUpdateOperations in the output to include the full operation definitions.

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: actionid, esc_period, eventsource, name, notify_if_canceled (6.0+), pause_suppressed, pause_symptoms (6.4+), status. Text properties cannot be filtered; use 'search' for them.
outputNoProperties of the action 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: actionid, name, status, eventsource. Properties: actionid, esc_period, eventsource, name, notify_if_canceled (6.0+), pause_suppressed, pause_symptoms (6.4+), status.
searchNoReturn results whose string properties contain the given pattern (case-insensitive; '*' is a wildcard when searchWildcardsEnabled is true). Example: {"name": "web"}. Keys: esc_period, name.
serverNoTarget Zabbix server. Available: default. Defaults to 'default' if omitted.
hostidsNoReturn only actions that reference these host IDs in their conditions.
groupidsNoReturn only actions that reference these host group IDs in their conditions.
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.
actionidsNoReturn only actions with the given IDs.
sortfieldNoSort by one or more of: actionid, name, status (comma-separated for several; pair with 'sortorder'). No other property is sortable.
sortorderNoSort order: 'ASC' (ascending) or 'DESC' (descending).
triggeridsNoReturn only actions that reference these trigger IDs in their conditions.
countOutputNoReturn the count of matching results instead of the actual data.
eventsourceNoReturn only actions with the given event source. Values: 0 = trigger events, 1 = discovery events, 2 = autoregistration events, 3 = internal events, 4 = service events.
searchByAnyNoIf true, return results matching ANY search field (OR). Default is ALL fields (AND).
extra_paramsNoOther native action.get parameters, merged into the request as-is. Parameters: mediatypeids, scriptids, userids, usrgrpids. Sub-object selects (value 'extend', 'count' or a list of property names): selectFilter, selectOperations, selectRecoveryOperations, selectUpdateOperations (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.
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

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds that operations/recovery/update definitions are excluded from the default output unless selects are requested, which is genuinely useful context, but it says nothing about scope of results, pagination, or permission requirements.

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 tight sentences, front-loaded with what the resource is before the operational hints. No filler, though the closing sentence's 'in the output' phrasing is slightly imprecise and could be reworded for clarity.

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 17-parameter read tool with an output schema present, the description need not explain return shapes; it supplies the conceptual framing plus the two most consequential knobs (eventsource scoping and operation selects). Adequate, with minor room to note that it returns action configuration rather than runtime events.

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 the schema already documents limit, filter, search, sortfield, etc., and the baseline is 3. The description restates the eventsource enum (already in the schema) and mentions the select* parameters, though it locates them 'in the output' whereas the schema places them under extra_params — mildly ambiguous rather than helpful.

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?

Specific verb+resource ('Retrieve actions') and it goes further by defining what an action is (conditions bound to operations), which implicitly distinguishes it from event_get/problem_get. However, it never names or contrasts a sibling tool, so it stops short of the top band.

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

Usage Guidelines3/5

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

Gives practical hints ('filter by event source to narrow results', 'use selectOperations ... to include full operation definitions'), but these are parameter-usage tips rather than when-to-use-this-tool-vs-alternatives guidance. No exclusions, prerequisites, or routing to correlation_get/configuration_export are stated.

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