Skip to main content
Glama
Sign In
Zabbix MCP Server

Zabbix MCP Server

by initMAX
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

script_getscriptsbyevents

Read-only

Retrieve scripts available for given Zabbix events and map event IDs to executable scripts, enabling dynamic script menus in event detail views.

Instructions

Get scripts available for the given events. Returns a mapping of event IDs to the scripts that can be executed in each event's context. Useful for building dynamic script menus in event detail views.

Input Schema

NameRequiredDescriptionDefault
serverNoTarget Zabbix server. Available: default. Defaults to 'default' if omitted.
eventidsYesEvent IDs to get available scripts for.
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.
scriptidNoReturn only this script, with its macros resolved for each event. Zabbix 7.0+.
manualinputNoValue of the {MANUALINPUT} macro to resolve in the script. Zabbix 7.0+.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.42.2
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / manualinput
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Value of the {MANUALINPUT} macro to resolve in the script. Zabbix 7.0+.",
+  "title": "Manualinput"
+}
    • addedInput schema / properties / scriptid
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Return only this script, with its macros resolved for each event. Zabbix 7.0+.",
+  "title": "Scriptid"
+}
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "script_getscriptsbyeventsOutput",
-  "type": "object"
-}New value: +null
  2. 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=false, so the safety profile is covered. The description adds value by disclosing the return shape (a mapping of event IDs to executable scripts), which is meaningful given there is no output schema, but it says nothing about permission requirements, macro resolution behavior, or Zabbix version constraints that live only in the schema.

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 sentences, front-loaded with the action and followed by the return shape and use case; nothing is redundant. The closing 'useful for' sentence is mild framing rather than essential information, keeping it just short of a 5.

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 simple read-only lookup with five fully documented parameters and no output schema, the description covers purpose, input scope, and return structure. The main omission is any indication that scriptid narrows the result to a single script with resolved macros, which changes what the caller receives.

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%, with detailed per-parameter docs including the raw_json security warning and the Zabbix 7.0+ notes for scriptid/manualinput. The description repeats none of this and adds no semantics beyond the schema, so the baseline of 3 applies.

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?

States a specific verb and resource ('Get scripts available for the given events') and names the scoping key (events). It does not explicitly distinguish itself from the sibling script_getscriptsbyhosts, so an agent must infer the events-vs-hosts split from the name alone.

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?

The sentence 'Useful for building dynamic script menus in event detail views' implies the intended use case, but there is no explicit when-to-use / when-not-to-use guidance and no mention of the host-scoped alternative. An agent gets a hint of context but no routing rule.

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