A while back chexma built vibeMK ( GitHub - chexma/vibeMK: vibeMK - CheckMK monitoring via LLM - MCP Server · GitHub ), an MCP server that lets an LLM work with Checkmk: ask what’s broken, schedule downtimes, create hosts and rules, activate changes. It’s a genuinely good idea, it was first, and the hard part — mapping a large, opinionated REST API onto something a model can actually plan against — was already done. I’ve been using it against my own production instance for months.
It’s been quiet since August 2025, so I’ve picked it up as a fork: https://github.com/SirTificate/vibemk-mcp. Same licence (GPL-3.0), full history and authorship kept, tool names unchanged, so an existing client config keeps working. 0.5.0 is out. The offer to hand any of it back stands.
The part that might be useful to you even if you never touch MCP
Your Checkmk site publishes its own OpenAPI document:
{server_url}/check_mk/api/1.0/openapi-doc.yaml
131 paths on my 2.4.0p36 Raw site. What makes it better than docs.checkmk.com for verification is that it carries your exact version and edition — it cannot describe an endpoint your site doesn’t have, and it won’t hide one it does. If you build anything against the REST API, it’s worth pulling.
I ended up leaning on it because of a structural blind spot, and I want to be precise about this since it’s not a criticism of the original: a test suite that mocks the HTTP client cannot tell whether an endpoint exists. A call to a path Checkmk doesn’t serve looks exactly like one that works. That’s the default state of most API clients I’ve written too — the tests pass, and they’re passing on a fiction.
What broke the illusion was mundane. I pointed a local model at the server and asked “what’s critical right now?” It answered with service names and states, no check output — so it went and read the handler source and started calling the REST API directly. It was routing around the tool because the tool wasn’t answering the question.
So I checked all 112 endpoint calls against that document. Seven had nothing behind them. A few examples, less to catalogue them than to show what the check catches:
• Rule positioning sent top/bottom/before/after. The API takes top_of_folder, bottom_of_folder, after_specific_rule, before_specific_rule, wants the target under rule_id, and needs a folder for the first two. Interestingly, an open PR upstream had spotted this months earlier.
• Acknowledgement removal went through DELETE objects/comment/{id}, which serves GET only. The host variant also decided which comments were acknowledgements by looking for “ack” in the text — so a note reading “ack with vendor pending” was in scope. 2.4 has a proper endpoint for this now (domain-types/acknowledge/actions/delete/invoke), which removes the guessing entirely.
• Effective host attributes used /folder/path where Checkmk wants ~folder~path, so the inheritance lookup 404’d for every host outside the root folder and the tool quietly returned the host’s own attributes instead.
None of these announced themselves. They reported success, or a failure that read like a transient error.
Where it stands now
104 endpoint calls, every one matching a path and verb 2.4.0p36 Raw actually serves. Three tools were removed rather than left to fail quietly — Checkmk’s REST API has no reschedule-check operation, and the metric domain offers only actions/get. 114 tools remain: hosts, folders, services and discovery, downtimes, acknowledgements and comments, rules and rulesets, users and contact groups, groups, tags, timeperiods, passwords, notification rules, metrics, BI, activate-changes.
Also worth correcting, in the original’s favour: its README listed Business Intelligence and the Event Console as Enterprise-only. They’re not — Checkmk registers those endpoints for every edition including Raw. The one genuine restriction is the Agent Bakery, which isn’t implemented here.
Under the hood: 214 tests, type checking and linting actually running in CI, and a read-only smoke test against a live instance behind an env flag, because that’s the only thing that catches the class of bug above.
Getting started
Python 3.9+, no dependencies, stdio. Clone it, point your MCP client at main.py, give it a Checkmk automation user. INSTALL.md has the details, examples/llm_configs/ has ready-made configs.
Start with a read-only automation user. Widen it later, once you’ve watched what the model actually does.
Before you point it at production
This lets a language model create and delete hosts, rules and users in your monitoring, and “activate changes” is a real button. Every tool call is logged at INFO — that log is your only record of what happened, so keep it.
I run this against my own production Checkmk, and I still wouldn’t hand it write access on someone else’s without a scoped role and a look at the audit log afterwards.
Feedback welcome
Especially from anyone on a commercial edition: my verification is against Raw, so those endpoints are the part I can’t check myself. Issues and PRs are open.