# MCP Server für Checkmk: die Optionen im Vergleich
> Alle auffindbaren MCP-Optionen für Checkmk nebeneinander — vibeMK, Checkmk MCP Server, CheckMCP, StackOne und ToolMesh + DADL. Abdeckung, Auth, Credential-Standort, Governance und Schreibsicherheit, jeweils mit Belegen.
Canonical: https://www.toolmesh.io/de/mcp/checkmk/
Es gibt **keinen offiziellen MCP-Server der Checkmk GmbH**. Checkmk 2.5 hat im April 2026 die Funktion „Explain with AI" gebracht, die aber in der Checkmk-GUI läuft, auf die Cloud Edition beschränkt ist und von einem externen Agenten nicht aufgerufen werden kann. Alles, was ein KI-Agent heute steuern kann, kommt aus Community-Projekten, von einem kommerziellen Hosted-Dienst oder von einem Gateway.
Diese Seite listet **alle fünf MCP-Optionen, die wir finden konnten**, und stellt sie über zehn Dimensionen nebeneinander. Wir stellen eine davon selbst her — deshalb sind die Regeln unten wichtig: keine Scores, keine Sterne, kein Ranking. Jede Zelle nennt eine Tatsache und verlinkt den Beleg.
## Entscheidung auf einen Blick
Die eigentliche Wahl ist nicht die Toolzahl, sondern der Zuschnitt des Zugangs: ein kleiner Checkmk-spezifischer Agenten-Connector, ein gehosteter Endpunkt ohne eigenen Betrieb — oder eine Governance-Schicht über Checkmk und weitere Systeme. Mit Stand 15. August 2026 sieht das Feld so aus — **fünf MCP-Optionen**, dazu drei benachbarte Projekte: zwei ohne MCP-Schnittstelle und ein angekündigter Server, der nicht mehr überprüfbar ist. Jede Aussage in der Tabelle fasst belegte Zellen der [Vergleichsmatrix](#vergleichsmatrix) unten zusammen.
Nach dokumentierter Fläche deckt ToolMesh + Checkmk-DADL mehr der Checkmk-REST-API ab als jede andere Option hier — 146 Tools über 63% der Endpunkte, die einzige veröffentlichte Messung unter den fünf, einschließlich Event Console, Business Intelligence und breiter Setup-Abdeckung. Der Checkmk MCP Server ist der einzige einfache lokale Prozess, der Event-Console-Abdeckung dokumentiert.
## Die Optionen
## Vergleichsmatrix
Zeilen sind die zehn Dimensionen, Spalten die Optionen. Die Tabelle scrollt horizontal. Hochgestellte Zahlen verlinken den [Beleg](#belege) zur jeweiligen Zelle.
„Nicht dokumentiert" heißt: Die von uns geprüften Quellen sagen dazu nichts — nicht, dass die Funktion fehlt. Wer eines dieser Projekte pflegt und einen Fehler findet, [eröffnet ein Issue](https://github.com/DunkelCloud/ToolMesh/issues) — wir korrigieren die Datendatei.
:::caution[Zwei Dinge, bevor Sie die Tabelle lesen]
**Nur unser eigener Eintrag lief real gegen ein Checkmk.** Die vier anderen Zeilen sind eine Auswertung der jeweils eigenen Dokumentation mit Stand 13. August 2026 — siehe [Methodik](#methodik-und-offenlegung). Unsere Zeile wurde am 14. August neu verifiziert, nachdem das Checkmk-DADL Event Console und BI ergänzt hat.
**Toolzahlen sind kein Maß für Funktionsumfang.** Die Projekte schneiden die API unterschiedlich granular in Tools, „146 gegen 37" sagt für sich genommen also wenig. Vergleichbar ist die Endpunkt-Abdeckung — wie viel der Checkmk-REST-API ein Projekt tatsächlich erreicht, gemessen am selben Nenner für alle. Unsere veröffentlichen wir (63% von rund 230 Endpunkten); die übrigen veröffentlichen ihre nicht, ihre Endpunkt-Abdeckung bleibt hier also unbeziffert. Wo diese Seite sagt, eine Option erreiche mehr der API als eine andere, ist das aus den jeweils dokumentierten Bereichen gelesen — und genau die Art Aussage, die ein Maintainer korrigieren sollte, wenn sie falsch ist.
:::
## Wann ein dedizierter Checkmk-Server die bessere Wahl ist
Ein Gateway, das die Checkmk-REST-API spricht, erreicht nie mehr als das, was diese API hergibt. Einiges in Checkmk liegt außerhalb davon — dort gewinnt ein eigens gebauter Server oder ein Checkmk-Plugin immer:
- **Livestatus.** Der Monitoring-Kern antwortet auf einem Socket, nicht über REST. Für große oder häufige Statusabfragen ist Livestatus drastisch günstiger und bietet Spalten und Filter, die die REST-Schicht nicht nach außen gibt. Ein dedizierter Server kann diesen Socket direkt öffnen, eine REST-basierte Option nicht.
- **Die Event Console.** `mkeventd` hat ein eigenes Protokoll, und die REST-Fläche für Events ist nur teilweise vorhanden: Aktuelle Events lassen sich auflisten, quittieren und archivieren, **historische** Events gibt Checkmk jedoch ausschließlich auf einer als unstable markierten API-Version heraus, die keine der hier gelisteten REST-basierten Optionen erreicht. Die aktuelle Seite decken zwei Optionen ab.
- **Business Intelligence.** BI-Aggregationen werden serverseitig kompiliert. Sie sinnvoll zu lesen heißt, den Aggregationsbaum zu verstehen, nicht bloß JSON abzuholen.
- **Das Dateisystem der Site und das `cmk`-CLI.** Entwicklung von Check-Plugins, Local Checks, Interna des Agent Baking, `omd`-Operationen und Konfigurationsdateien erreicht man über SSH oder auf der Site, niemals über REST.
- **Benachrichtigungen und Events als Strom.** Checkmk stößt Benachrichtigungen über Notification-Handler an. Es gibt kein REST-Abo zum Pollen — alles Ereignisgetriebene muss als Handler in Checkmk laufen.
- **Performance-Daten über lange Zeiträume.** Monate an Metriken durch die REST-API zu ziehen ist weit teurer, als die RRDs dort zu lesen, wo sie liegen.
Wer einen dieser Fälle hat, ist mit einem REST-Gateway grundsätzlich falsch bedient — unabhängig davon, wer es baut.
## Wann ein Gateway die bessere Wahl ist
Ein Gateway rechnet sich, wenn Checkmk nicht das einzige System im Bild ist:
- **Fragen über Systemgrenzen hinweg.** „Welche Hosts sind in Checkmk kritisch, und wem gehören sie laut NetBox?" ist ein Agenten-Zug gegen einen Endpunkt statt zweier Connectoren, die einander nicht sehen. Die öffentliche [DADL-Registry](https://www.dadl.ai) führt Stand August 2026 30 APIs mit über 4.000 Tools — das zweite System ist also oft schon beschrieben.
- **Ein Ort für Credentials.** Das Automation-Secret liegt serverseitig und wird zur Aufrufzeit injiziert, statt in der Client-Konfiguration jedes Operators zu stehen.
- **Ein Autorisierungsmodell und ein Audit-Trail** über alle angebundenen Systeme statt Konventionen je Connector.
- **Kontext-Ökonomie im Großen.** 146 Checkmk-Tools sind viel Schema für ein Modell; ein Katalog, der flach bleibt, zählt umso mehr, je mehr Systeme dazukommen. Das ist allerdings nicht unser Alleinstellungsmerkmal — StackOne löst dasselbe Problem für seinen gehosteten Katalog.
Der ehrliche Trade-off: Ein Gateway ist **eine zusätzliche Komponente**, die betrieben, überwacht und verfügbar gehalten werden muss — und es zahlt sich erst aus, wenn mehr als ein System dahinter hängt. Wer nur Checkmk anbinden wird und lesende Statusabfragen braucht, fährt mit einem kleinen dedizierten Server schlanker. CheckMCP gibt es, und es sind acht Tools.
## Coverage-Report
Der maschinenlesbare Coverage-Report für unsere Option — jedes Tool, seine Zugriffsstufe und welche Teile der Checkmk-REST-API abgedeckt sind und welche nicht — steht unter **[dadl.ai/d/checkmk](https://www.dadl.ai/d/checkmk)**. Er weist 146 Tools plus drei Composites aus, 63% von etwa 230 Endpunkten, mit ausdrücklich benannten Lücken.
## Häufige Fragen
{faqs.map(({ q, a }) => (
<>
{q}
{a}
))}
---
*Ab hier Referenzteil — die benachbarten Projekte, Methodik und Offenlegung, Changelog und Belege. Für die Entscheidung oben braucht es nichts davon; hier steht die Evidenz.*
## Benachbarte Projekte ohne nutzbaren MCP-Server
## Methodik und Offenlegung
**Offenlegung.** Diese Seite wird von der [Dunkel Cloud GmbH](https://www.dunkel.cloud) herausgegeben, die ToolMesh herstellt — eine der fünf gelisteten Optionen. Wir haben ein offensichtliches Interesse daran, wie das aussieht. Die Gegenmaßnahmen sind strukturell: Die Optionen stehen alphabetisch, jede Zelle trägt einen Beleg-Link, keine Zelle enthält Score oder Ranking, und die beiden „Wann…"-Abschnitte oben benennen die Fälle, in denen unsere Option das falsche Werkzeug ist.
**Wie die Fakten erhoben wurden.** Aus dem jeweils eigenen Repository, README und der eigenen Dokumentation, gelesen am 13. August 2026. Repository-Metadaten — Lizenz, letzter Commit, Sterne und Forks — stammen vom selben Tag aus der GitHub-API. Wo ein Projekt etwas nicht angibt, steht „nicht dokumentiert" statt einer Vermutung.
Bei gehosteten Produkten heißt das: die Plattform-Dokumentation, nicht nur die Seite des jeweiligen Connectors. Eine Connector-Seite beschreibt den Connector; Fähigkeiten, die für das ganze Produkt gelten — Tool-Discovery, der Umgang mit Antworten, die Prüfung auf eingeschleusten Inhalt — stehen woanders. Wer nur die Connector-Seite liest, stellt solche Produkte zu schwach dar, und zwar genau in den Bereichen, in denen ein Gateway seine Stärke reklamieren würde.
**Prüftiefe.** Die vier Optionen, die wir nicht selbst pflegen, sind Doku-Auswertung, nicht Testergebnis — gelesen, nicht gestartet. Anbieterangaben, die wir nicht selbst nachzählen können, werden als solche zitiert. Unser eigener Eintrag ist die Ausnahme: Das Checkmk-DADL wurde am 13. August 2026 mit vollem Schreibzyklus gegen eine Checkmk-2.5.0p11-Site live verifiziert und am 14. August nach der Ergänzung von Event Console und BI erneut. Die Maintainer der gelisteten Projekte wurden mit der Veröffentlichung dieser Seite benachrichtigt; Korrekturen landen in der Datendatei.
**Korrekturen und Ergänzungen.** Die Matrix lebt als eine YAML-Datei im Repository dieser Website; das Website-Repository selbst ist privat, Korrekturen laufen deshalb als [Issue im öffentlichen ToolMesh-Repository](https://github.com/DunkelCloud/ToolMesh/issues). Eine Tatsache korrigieren oder eine übersehene Option ergänzen: ein Issue genügt. An die Maintainer: Wenn wir euer Projekt falsch dargestellt haben, ist das ein Bug, und wir beheben ihn.
## Changelog
## Belege