Execute Zabbix API method. This is the main tool for interacting with Zabbix. It requires multiple iterations to achieve complex goals. Use other tools for guidance. WORKFLOW: 1. If unsure about method/params: call zabbix_api_docs(method) first 2. If unsure about available methods: call zabbix_ap...
AI agents invoke zabbix_api to trigger actions in Zabbix. What it does depends on the arguments the agent supplies, and its effects often reach beyond the immediate call — builds kicked off, notifications sent, workflows started.
The tool's primary function is to execute arbitrary Zabbix API methods with user-supplied parameters. While the server advertises a read-only mode, this tool itself has no inherent restrictions and can execute any Zabbix API call including modifications, deletions, or operational triggers. The ability to execute arbitrary API methods whose effects depend on method name and parameters makes this Execute-class.
From the tool's definition Tool description states "Execute Zabbix API method" and explicitly says "This is the main tool for interacting with Zabbix." The workflow describes executing API calls with parameters/filters, which are characteristics of code/command execution.
Documented attack patterns abuse exactly the kind of access zabbix_api gives an agent:
PolicyLayer is an MCP gateway — it sits between your AI agents and Zabbix, and nothing reaches the server without passing your rules. This is the rule we recommend for zabbix_api:
{
"version": "1",
"default": "deny",
"tools": {
"zabbix_api": {
"limits": [
{
"counter": "zabbix_api_rate",
"window": "minute",
"max": 10,
"scope": "grant"
}
]
}
}
} zabbix_api stays usable, but rate-capped — a runaway agent can't fire it dozens of times a minute. Everything else on the server is denied unless you say otherwise.
Free to start. No card required.
Execute Zabbix API method. This is the main tool for interacting with Zabbix. It requires multiple iterations to achieve complex goals. Use other tools for guidance. WORKFLOW: 1. If unsure about method/params: call zabbix_api_docs(method) first 2. If unsure about available methods: call zabbix_api_list() first 3. Execute the API call with this tool 4. If empty results or errors: iterate with different params/filters 5. Continue iterating until goal is achieved COMMON PATTERNS: - Finding an object requires 2+ calls (find ID, then get details) - CPU usage example: Find host by name, get its items, filter CPU item, get history - Empty results often mean wrong filters - try broader search first Args: method: Zabbix API method (format: 'object.action'). Examples: 'host.get', 'item.create', 'trigger.update' params: Method parameters (optional). For 'get' operations, specify 'output' to limit fields (default: ['name']). Returns: JSON response from Zabbix API. Examples: # Simple query zabbix_api('host.get', {'output': ['hostid', 'name']}) # Multi-step: Find host, then get items # Step 1: Find host ID hosts = zabbix_api('host.get', {'filter': {'host': 'my-srv-01'}, 'output': ['hostid']}) # Step 2: Get CPU items for that host items = zabbix_api('item.get', {'hostids': ['12345'], 'search': {'name': 'CPU'}, 'output': ['itemid', 'name']}) # Step 3: Get history for specific item history = zabbix_api('history.get', {'itemids': ['67890'], 'output': 'extend', 'history': 0, 'limit': 10}) Note: - Use zabbix_api_docs() for method documentation - Use zabbix_api_list() for available methods - Iterate multiple times - complex queries need 2-5 API calls. It is categorised as a Execute tool in the Zabbix MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
Register the Zabbix MCP server in PolicyLayer and add a rule for zabbix_api: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Zabbix. Nothing to install.
zabbix_api is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the zabbix_api rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for zabbix_api. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
zabbix_api is provided by the Zabbix MCP server (mpeirone/zabbix-mcp-server). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Start from Zabbix, add the rest of your stack, and see everything your agents can call. Then put policy on all of it.
Free to start. No card required.
3 Zabbix tools catalogued and risk-classified — across an index of 43,000+ MCP servers.