Chatting with Zabbix: The Reality of AI, MCP Servers, and Local LLMs

Imagine being able to simply ask your monitoring system, "What are the latest problems in our infrastructure?" and getting a clear, human-readable answer. A year ago, I showed you how we could achieve this using Large Language Models (LLMs) and the Model Context Protocol (MCP) introduced by Anthropic's Claude. It was a fascinating proof of concept.

Recently, the Zabbix community has taken this idea to the next level. Our friends at InitMax, a prominent Zabbix partner in Europe, released an impressive MCP server project. While their solution is incredibly detailed, diving into it raised a few critical questions for me about how we actually use AI with complex monitoring tools. Today, I want to share my journey of testing these tools, the hurdles I faced with local AI models, and my ultimate verdict on AI-driven Zabbix automation.

The InitMax MCP Server: Powerful, But Complex

The team at InitMax did a fantastic job. They essentially wrapped all the Zabbix APIs—from version 5.0 all the way to the latest 7.4—and made them accessible to an AI. You can check out their work, and it is undeniably comprehensive.

However, when I tried to integrate it into my own workflow, I hit a roadblock. I prefer using Open WebUI as my chat frontend, powered by Ollama running directly on my local machine. Specifically, I use the Qwen 3.5 model with 13 billion parameters. It’s a hefty model that can reason quite well, but connecting it to the standard MCP protocol wasn't straightforward.

The Integration Challenge

When you ask a local LLM for current problems, the API returns raw data, including abstract Host IDs and Item IDs. For the AI to give you a useful answer, it has to realize it needs to take that Host ID, make a separate host.get request, and correlate the data. While massive cloud models like ChatGPT or Gemini might figure this out, local models easily get confused by this complex API chaining.

AI for Zabbix Automation: A Bridge Too Far?

This complexity reminded me of a GitHub project I saw earlier this year by M. Peroni. He attempted to build an AI engine using Gemini and MCP to perform actual Zabbix automation—creating hosts, setting up maintenance periods, and adding items.

Despite crafting incredibly detailed prompts and spending a lot of time on it, the final result was highly unpredictable. The AI would occasionally manage to create a host, but more often than not, it would get lost in the complex logical steps required.

From my perspective, using an LLM to automate Zabbix configuration is a massive gamble. It is simply too inconsistent. If the AI hallucinates or loses its train of thought during a multi-step configuration, you end up with a broken monitoring setup. For automation, traditional scripting and tools like Ansible remain far superior.

Building a Human-Readable Zabbix MCP Server

Realizing that raw API exposure doesn't work well for chat interfaces, I decided to start from scratch. I built my own custom MCP server tailored specifically for problem analysis.

Instead of forcing the LLM to do the heavy lifting of correlating IDs, I designed my MCP server to respond to a "problem get" request with pre-correlated, humanly understandable information. I wanted to see if a local model could handle this streamlined data.

The Live Test

I fired up my local Qwen 3.5 model through Open WebUI, enabled my custom MCP server, and gave it a prompt: "Give me the problems from the last hour."

Because it’s running locally, it took a moment to think. But the result was exactly what I hoped for:

The Verdict: Where AI and Zabbix Truly Shine

So, what is the real use case for MCP servers in Zabbix?

For Automation? No. It makes no sense right now. It is too unpredictable and prone to failure.

For Problem Analysis? Absolutely. Imagine a Network Operations Center (NOC) where Level 1 operators might not immediately understand the nuances of a specific alert. Having an LLM connected via an MCP server that can pull detailed, human-readable context about the host, the specific item, and the history of the problem is a game-changer. It empowers operators to dig deeper into the logs and understand the root cause textually, without needing to be Zabbix experts.

This is a path well worth traveling, and I am excited to keep experimenting.

Let's Keep the Conversation Going!

What do you think about using AI with Zabbix? Do you see it as a helpful assistant for your NOC, or are you still skeptical? Let me know your thoughts in the comments below, and maybe we can run some new experiments together in the future.

If you enjoyed this deep dive, make sure to subscribe to my YouTube channel, Quadrata, for more tutorials and tech explorations. Also, don't forget to join our vibrant community on the ZabbixItalia Telegram Channel!

See you next week! A big greeting from Dimitri.