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.
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 below.
| Option | Fits when | Writes | Key limit | Verification |
|---|---|---|---|---|
| CheckMCP | Read-only status access with nothing to configure wrong — and the only dedicated server here you can run as a central HTTP service | No — read-only by design; eight tools are the entire surface | No writes at all; repository created and last pushed on the same day in March 2026 | Docs review |
| Checkmk MCP Server | Event Console, Metrics API or Business Intelligence through a plain local process | Yes — monitoring actions such as downtimes and acknowledgements are documented | Self-described production ready; the last commit is from September 2025 | Docs review |
| StackOne Checkmk MCP | Nothing to operate yourself — a hosted endpoint with OAuth and token handling done by the vendor | Yes — 68 pre-built actions, configuration writes included | Your Checkmk credentials and monitoring data pass through StackOne's infrastructure | Docs review |
| ToolMesh + Checkmk DADL our project | Checkmk alongside other systems behind one governed endpoint — or the widest documented reach into Checkmk | Yes — across monitoring and Setup, verified live including a full write cycle | A standing service to operate; HW/SW inventory, agent registration and DCD stay out of reach | Hands-on tested |
| vibeMK | Writes against one Checkmk without running a service — a Python process your LLM client launches | Yes — the broadest write coverage among the options that need no separate service | Self-declared alpha; last commit August 2025 | Docs review |
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.
A deliberately small, read-only MCP server: eight tools for hosts, services, downtimes, folders and tags. Among the dedicated Checkmk servers here it is the only one you can run yourself as a central HTTP service — with optional OAuth 2.0 JWT verification — rather than as a per-user subprocess. Repository created and last pushed on the same day in March 2026.
37 tools in eight categories, and the broadest coverage of Checkmk's specialised subsystems in this list: Event Console, Metrics API and Business Intelligence are all addressed. Self-described as production ready; the last commit is from September 2025.
The only hosted, commercially operated option: 68 pre-built actions behind a StackOne endpoint, with OAuth token exchange, storage and refresh handled by the vendor. Feature-wise it is the closest thing here to a gateway — it is the only other option with dynamic tool discovery, a code mode, and a classifier for prompt injection in tool responses. No installation, but your Checkmk credentials and monitoring data pass through StackOne's infrastructure.
Not a Checkmk-specific server but a self-hosted gateway that reads a declarative YAML description of the Checkmk REST API — 146 tools plus three composites, 63% of the API surface, including the Event Console and Business Intelligence since 14 August 2026. Governance (per-tool authorization, server-side credentials, output policies, audit) comes from the gateway rather than from the connector. Still uncovered: HW/SW inventory, agent registration, DCD, LDAP connections, and historical Event Console events, which Checkmk only exposes on an unstable API version.
Our project — see the disclosure below
The most visible community project — announced in the Checkmk forum, where Checkmk staff responded positively. Among the options that run as a plain local process, its README documents write access across the most Checkmk configuration objects: hosts, folders, rules, users, tags and bulk host creation. StackOne and ToolMesh, which run as services, document write access across more object types. vibeMK publishes no tool count, so this is a reading of its documented feature areas, not a measured surface. The README labels it alpha, and the last commit is from August 2025.
Rows are the ten dimensions; columns are the options. The table scrolls horizontally. Superscript numbers link to the source 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 and we will fix the data file.
| Dimension | CheckMCP | Checkmk MCP Server | StackOne Checkmk MCP | ToolMesh + Checkmk DADL our project | vibeMK |
|---|---|---|---|---|---|
| Maintainer type | Community — single maintainer 1 | Community — single maintainer 2 | Commercial vendor 3 | Vendor — Dunkel Cloud GmbH (publisher of this page) 6 | Community — single maintainer 7 |
| License | MIT 1 | MIT 2 | Proprietary (SaaS) 3 | Apache-2.0 (gateway and DADL registry) 6 | GPL-3.0 5 |
| Runtime & install | Python 3.12+; Docker Compose, Docker or manual 1 | Python 3.8+; git clone and pip install 2 | None — hosted endpoint 3 | Single Go binary; the DADL is one YAML file in backends.yaml 4 | Python 3.8+; git clone 5 |
| Last code activity | 14 Mar 2026 — created and last pushed the same day 1 | 2 Sep 2025 2 | Not applicable — no public repository 3 | 11 Aug 2026 6 | 29 Aug 2025 5 |
| Public adoption signal | 0 stars, 0 forks 1 | 1 star, 2 forks 2 | Not published 3 | 5 stars, 0 forks 6 | 16 stars, 9 forks 5 |
| Maturity (self-declared) | No claim made 1 | "Production ready" 2 | Marketed as a production connector 3 | Gateway is pre-1.0; the Checkmk DADL is live-verified 6 | "Alpha stage and under development" 5 |
| Tools / actions | 8 tools 1 | 37 tools in 8 categories 2 | 68 actions in total; the vendor's CRUD filters account for 49 of them (12 create, 15 read, 11 update, 11 delete), the remaining 19 are not broken out 3 | 146 tools + 3 composites — 63% of ~230 REST endpoints 4 | Not documented; the README lists five functional areas 5 |
| Read / write / delete | Read only — "currently only supports read operations" 1 | Read and write (downtimes, acknowledgements) 2 | Read, write and delete 3 | Read, write and delete; each tool carries an access level 4 | Read and write — hosts, folders, rules, users, tags, bulk host creation 5 |
| Monitoring vs Setup | Monitoring reads plus folders and tags 1 | Both — host/service management and maintenance scheduling 2 | Both — CRUD across hosts, folders, services and configuration 3 | Both — status reads via the REST API's Livestatus query expressions, plus broad Setup-tree coverage 4 | Both — live monitoring and configuration management 5 |
| Event Console, BI, metrics, inventory | None of these 1 | Event Console, Metrics API and Business Intelligence 2 | Not documented 3 | Event Console, Business Intelligence and metrics all covered since 14 Aug 2026; HW/SW inventory, agent registration, agent bakery and DCD are not 4 | Metrics; BI and Agent Bakery listed as Enterprise-edition features 5 |
| Method towards Checkmk | Checkmk credentials from a YAML config file (CONFIG_PATH) 1 | Automation user via YAML config file or environment variables 2 | OAuth via a StackOne Connect Session 3 | Automation-user bearer token ("<user> <secret>"), injected server-side at call time 4 | Automation user, Administrator role recommended 5 |
| Where the secret lives | On the host running CheckMCP 1 | On the client machine (config file or .env) 2 | In StackOne's cloud — the vendor handles storage and refresh 3 | Server-side in the gateway's credential store; it is injected at call time and not passed to the client or the model 8 | In the LLM client's config or a .env file on the client machine 9 |
| Who may call the server | OAuth 2.0 JWT verification against an external IdP, or none 1 | Not applicable — local subprocess of one client 2 | StackOne API key; users isolated via origin_owner_id 3 | Authenticated gateway users with per-user identity 8 | Not applicable — local subprocess of one client 5 |
| Least privilege | Read-only by construction 1 | Through the Checkmk role of the automation user 2 | Actions can be limited in the StackOne dashboard 3 | Checkmk role plus per-tool, per-user authorization in the gateway 10 | Through the Checkmk role; the README suggests a read-only role for analysis-only use 5 |
| Deployment mode | Self-hosted HTTP service (Docker Compose, Docker or Python) 1 | Local subprocess on the client machine 2 | SaaS — vendor-operated endpoint 3 | Self-hosted gateway (binary or container) 6 | Local subprocess on the client machine 5 |
| Data path | Client → CheckMCP → Checkmk; no third party 1 | Client → local server → Checkmk; no third party 2 | Client → StackOne cloud → Checkmk; monitoring data and credentials traverse the vendor's infrastructure 3 | Client → your gateway → Checkmk; no third party 6 | Client → local server → Checkmk; no third party 5 |
| Works with firewalled on-prem Checkmk | Yes — runs inside your network 1 | Yes — runs on the operator's machine 2 | Not documented — a hosted endpoint needs to reach your Checkmk 3 | Yes — the gateway runs inside your network 6 | Yes — runs on the operator's machine 5 |
| Checkmk versions | Tested with Raw Edition 2.3.0p23 1 | 2.4.0 or newer required 2 | Not documented 3 | Targets 2.4/2.5, live-verified on 2.5.0p11; most tools also work on 2.2/2.3, exceptions documented per tool 4 | 2.4.x and 2.3.x full; 2.2/2.1/2.0 untested; 1.6 unsupported 5 |
| Edition dependencies | Raw Edition tested 1 | Not stated per edition 2 | Not documented 3 | Verified on a community (Raw) edition site, including the Event Console and BI, which Checkmk registers for every edition; CEE-only endpoints such as agent bakery and signature keys are not covered 4 | Raw = basic functions; BI, Agent Bakery and Metrics listed under Enterprise/Cloud 5 |
| Tool allow/deny | Not documented 1 | Not documented 2 | Yes — actions toggled per connector, and session tokens can be scoped to specific actions 3 | Yes — per-tool, per-user policies; four access levels per tool 10 | Not documented 5 |
| Read-only mode | Inherent — no write tools exist 1 | Not documented — use a read-only Checkmk role 2 | Approximated by deselecting write actions 3 | Via authorization policy and/or a read-only Checkmk role 10 | Not documented — use a read-only Checkmk role 5 |
| Audit trail in the connector | Not documented — Checkmk's own audit log still applies 1 | Not documented — Checkmk's own audit log still applies 2 | Vendor-side logging; detail not published 3 | SQL-queryable log per call, attributed to user and caller 6 | Not documented — Checkmk's own audit log still applies 5 |
| DLP / redaction of responses | Not documented 1 | Not documented 2 | No response redaction documented; exposure is limited by scoping actions and session tokens instead 3 | Output Gate — JS policies before and after execution, with redaction 11 | Not documented 5 |
| Distribution & pinning | Docker image or git clone; no signed release documented 1 | git clone; no published package or signed release 2 | Vendor-operated; no artifact to pin 3 | Tagged releases and container images; the Checkmk description is a versioned YAML file in a public registry 4 | git clone; a third party has republished it to PyPI under a different name, which is not the maintainer's channel 12 |
| Dependency surface | Python plus requirements.txt 1 | Python plus requirements.txt 2 | Opaque — vendor-operated 3 | One static Go binary; adding Checkmk introduces no further runtime dependency, only a YAML file 6 | Python plus requirements.txt 5 |
| Defence against prompt injection | Not documented 1 | Not documented 2 | Ships a classifier (StackOne Defender, Apache-2.0, vendor-reported F1 90.8%); whether it is active by default on this connector is not documented 13 | No classifier ships; response text can be screened in an Output Gate post-policy, but none does so by default 11 | Not documented 5 |
| Transport | HTTP, port 8000 by default 1 | stdio 2 | Remote HTTP endpoint 3 | Streamable HTTP; stdio when the gateway itself runs locally as a single-user subprocess 14 | stdio, launched from the LLM client config 5 |
| Remote / multi-user capable | Yes — HTTP with optional OAuth JWT verification 1 | No — one subprocess per client 2 | Yes — multi-user with per-user isolation 3 | Yes — multi-user with per-user authorization 10 | No — one subprocess per client 5 |
| Catalog cost in context | 8 tools — negligible 1 | 37 tools loaded up front 2 | 68 actions, but tool discovery and a "Code Mode" that keeps raw responses in a sandbox hold the loaded context down — the vendor reports massive token savings 15 | 146 tools, but Code Mode replaces the catalog with two meta-tools, keeping the loaded context near-flat — massive token savings, with the exact rate depending on the workload 16 | Not documented 5 |
| Discovery | Static tool list 1 | Static tool list 2 | Dynamic tool discovery — the vendor states only relevant actions are loaded per query, using a hybrid lexical search 15 | Progressive, ranked tool discovery 16 | Static tool list 5 |
| Pending changes & activation | Not applicable — read only 1 | Not documented 2 | Not documented 3 | Explicit — tools for listing and activating pending changes plus a composite that applies them; the Monitoring/Setup split is documented for the model 4 | Not documented in the README 5 |
| Concurrency (ETag / If-Match) | Not applicable — read only 1 | Not documented 2 | Not documented 3 | Sends If-Match by default, which Checkmk requires for mutating requests (HTTP 428 otherwise) 4 | Not documented 5 |
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:
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.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.If your use case is any of the above, a REST gateway is the wrong shape regardless of who makes it.
A gateway earns its keep when Checkmk is not the only system in the picture:
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.
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. It records 146 tools plus three composites, 63% of roughly 230 endpoints, with the uncovered areas named explicitly.
No. As of August 2026 Checkmk GmbH has not released an MCP server. Checkmk 2.5 added an 'Explain with AI' feature in April 2026, but it runs inside the Checkmk GUI, is limited to the Cloud edition, and cannot be called by an external AI agent. When vibeMK was announced in the Checkmk forum in August 2025, a Checkmk staff member replied that AI initiatives were under way internally, without announcing an MCP server.
Both, depending on the option. CheckMCP is read-only by design. The other four support writes at different depths: the Checkmk MCP Server documents downtimes and acknowledgements, while vibeMK, StackOne and ToolMesh also document configuration writes such as creating hosts and folders or editing rules. Note that Checkmk splits the two worlds: monitoring actions such as downtimes take effect immediately, while Setup changes are staged as pending changes and do nothing until they are activated.
Two of them. The Checkmk MCP Server (jlk/checkmk-llm-server) documents Event Console, Metrics API and Business Intelligence coverage. The ToolMesh Checkmk DADL added both on 14 August 2026 — seven Event Console and fourteen BI tools, verified against a live Checkmk 2.5.0p11 site. vibeMK lists BI and the Agent Bakery as Enterprise-edition features, though Checkmk in fact registers BI and the Event Console for every edition, Raw included. CheckMCP covers neither. One limit applies to all of them: historical Event Console events are only exposed on an API version Checkmk marks unstable, so no REST-based option reaches them.
That is one of the clearest differences between the options. vibeMK and the Checkmk MCP Server read the automation user's secret from the LLM client's configuration or a .env file on the operator's machine. CheckMCP reads it from a YAML file on the host it runs on. StackOne stores and refreshes the credential in its own cloud, and your monitoring data traverses StackOne's infrastructure. ToolMesh keeps it server-side in the gateway and injects it at call time, so it never appears in a client configuration.
The four self-hosted options do, because they run inside your network. For the hosted StackOne connector this is not documented, and a vendor-operated endpoint needs some way to reach your Checkmk site.
It varies and matters. CheckMCP is tested against Raw Edition 2.3.0p23. The Checkmk MCP Server requires 2.4.0 or newer. vibeMK reports full support for 2.4.x and 2.3.x, with older releases untested and 1.6 unsupported. The ToolMesh DADL targets 2.4 and 2.5 and was live-verified on 2.5.0p11. StackOne does not document version support.
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.
Disclosure. This page is published by Dunkel Cloud GmbH, 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. 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.