# MCP servers for Checkmk: the options compared
> Every findable MCP option for Checkmk side by side — vibeMK, Checkmk MCP Server, CheckMCP, StackOne and ToolMesh + DADL. Coverage, auth, credential location, governance and write safety, each with sources.
Canonical: https://www.toolmesh.io/en/mcp/checkmk/
There is **no official MCP server from Checkmk GmbH**. Checkmk 2.5 shipped an "Explain with AI" feature in April 2026, but it lives inside the Checkmk GUI, is limited to the Cloud edition, and cannot be called by an external agent. Everything an AI agent can drive today comes from community projects, one commercial hosted service, or a gateway.
This page lists **all five MCP options we could find** for Checkmk and puts them side by side across ten dimensions. We make one of them, which is why the sourcing rules below matter: no scores, no stars, no rankings — every cell states a fact and links to the evidence.
## Decision at a glance
The real choice is not the tool count but the shape of access: a small Checkmk-specific agent connector, a hosted endpoint with nothing to operate, or one governance layer across Checkmk and further systems. As of 15 August 2026 the field looks like this — **five MCP options**, plus three adjacent projects: two that are not MCP servers, and one announced server that can no longer be verified. Every claim in the table is a summary of sourced cells in the [comparison matrix](#comparison-matrix) below.
By documented surface, ToolMesh + the Checkmk DADL covers more of the Checkmk REST API than any other option here — 146 tools across 63% of the endpoints, the only published measurement among the five, including the Event Console, Business Intelligence and broad Setup coverage. The Checkmk MCP Server is the only plain local process that documents Event Console coverage.
## The options
## Comparison matrix
Rows are the ten dimensions; columns are the options. The table scrolls horizontally. Superscript numbers link to the [source](#sources) for that cell.
"Not documented" means the sources we checked do not state it — not that the feature is absent. If you maintain one of these projects and we got something wrong, [open an issue](https://github.com/DunkelCloud/ToolMesh/issues) and we will fix the data file.
:::caution[Two things to know before reading the table]
**Only our own entry has been run against a live Checkmk.** The other four rows are a reading of each project's own documentation as of 13 August 2026 — see [methodology](#methodology-and-disclosure). Our row was re-verified on 14 August, after the Checkmk DADL gained Event Console and BI coverage.
**Tool counts are not a measure of capability.** The projects slice the API into tools at very different granularity, so "146 vs 37" says little on its own. The number that *is* comparable is endpoint coverage — how much of the Checkmk REST API a project can actually reach, measured against the same denominator for everyone. We publish ours (63% of roughly 230 endpoints); none of the others publish theirs, so their endpoint coverage remains unquantified here. Where this page says one option reaches more of the API than another, that is read from the areas each project documents — and is exactly the kind of claim a maintainer should correct if we have it wrong.
:::
## When a dedicated Checkmk server is the better choice
A gateway that speaks the Checkmk REST API can only ever reach what the REST API exposes. Several things in Checkmk sit outside it, and for those a purpose-built server — or a Checkmk plugin — will always win:
- **Livestatus.** The monitoring core answers on a socket, not over REST. For large or frequent status queries, Livestatus is dramatically cheaper and exposes columns and filters the REST layer does not surface. A dedicated server can open that socket directly; a REST-based option cannot.
- **The Event Console.** `mkeventd` has its own protocol, and the REST surface for events is only partial: current events can be listed, acknowledged and archived, but **historical** events are exposed solely on an API version Checkmk marks unstable, which no REST-based option here reaches. Two options cover the current-event side.
- **Business Intelligence.** BI aggregations are compiled server-side. Reading them meaningfully means understanding the aggregation tree, not just fetching JSON.
- **The site filesystem and the `cmk` CLI.** Check plugin development, local checks, agent baking internals, `omd` operations and configuration files are reachable over SSH or on the site, never over REST.
- **Notifications and events as a stream.** Checkmk pushes notifications through notification handlers. There is no REST subscription to poll, so anything event-driven needs to run as a handler inside Checkmk.
- **Performance data over long ranges.** Pulling months of metrics through the REST API is far more expensive than reading the RRDs where they live.
If your use case is any of the above, a REST gateway is the wrong shape regardless of who makes it.
## When a gateway is the better choice
A gateway earns its keep when Checkmk is not the only system in the picture:
- **Questions that span systems.** "Which hosts are critical in Checkmk, and who owns them in NetBox?" is one agent turn against one endpoint, instead of two connectors that cannot see each other. The public [DADL registry](https://www.dadl.ai) lists 30 APIs and over 4,000 tools as of August 2026, so the second system is often already described.
- **One place for credentials.** The automation secret lives server-side and is injected at call time, rather than sitting in every operator's client configuration.
- **One authorization model and one audit trail** across every connected system, instead of per-connector conventions.
- **Context economy at scale.** 146 Checkmk tools is a lot of schema for a model to carry; a catalog that stays flat matters more the more systems you connect. This one is not ours alone — StackOne solves the same problem for its hosted catalog.
The honest trade-off: a gateway is **an additional component** you have to run, monitor and keep available — and it only pays for itself once more than one system is behind it. If Checkmk is the only thing you will ever connect, and read-only status queries are all you need, a small dedicated server is the leaner answer. CheckMCP exists and is eight tools.
## Coverage report
The machine-readable coverage report for our option — every tool, its access level, and which parts of the Checkmk REST API are and are not covered — is at **[dadl.ai/d/checkmk](https://www.dadl.ai/d/checkmk)**. It records 146 tools plus three composites, 63% of roughly 230 endpoints, with the uncovered areas named explicitly.
## Frequently asked questions
{faqs.map(({ q, a }) => (
<>
{q}
{a}
))}
---
*Reference from here on — the adjacent projects, the methodology and disclosure, the changelog and the sources. Nothing below is needed for the decision above; it is where the evidence lives.*
## Adjacent projects without a usable MCP server
## Methodology and disclosure
**Disclosure.** This page is published by [Dunkel Cloud GmbH](https://www.dunkel.cloud), which makes ToolMesh — one of the five options listed. We have an obvious interest in how it looks. The countermeasures are structural: options are ordered alphabetically, every cell carries a source link, no cell contains a score or a ranking, and the two "when to choose" sections above name the cases where our option is the wrong tool.
**How the facts were gathered.** Each option's own repository, README and documentation, read on 13 August 2026. Repository metadata — licence, last commit, stars and forks — comes from the GitHub API on the same date. Where a project does not state something, the cell says "not documented" rather than guessing.
For hosted products that means the platform documentation, not only the per-connector page. A connector page describes the connector; capabilities that span the whole product — tool discovery, how responses are handled, screening for injected content — are documented elsewhere. Reading only the connector page understates such products, and it understates them in exactly the areas where a gateway would claim strength.
**Depth of verification.** The four options we do not maintain are documentation review, not test results — read, not run. Vendor figures we cannot count ourselves are quoted as such. Our own entry is the exception: the Checkmk DADL was live-verified against a Checkmk 2.5.0p11 site on 13 August 2026, including a full write cycle, and re-verified on 14 August after Event Console and BI coverage were added. The maintainers of the listed projects were notified when this page went live; corrections land in the data file.
**Corrections and additions.** The matrix lives as one YAML file in this site's repository; the site repository itself is private, so corrections travel as [issues on the public ToolMesh repository](https://github.com/DunkelCloud/ToolMesh/issues). Correcting a fact, or adding an option we missed, takes one issue. Maintainers: if we have misrepresented your project, that is a bug and we will fix it.
## Changelog
## Sources