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.
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 unten zusammen.
| Option | Geeignet, wenn | Schreiben | Wichtigste Grenze | Prüfstatus |
|---|---|---|---|---|
| CheckMCP | Rein lesender Statuszugriff, ohne dass man etwas falsch einstellen muss — und der einzige dedizierte Server hier, der als zentraler HTTP-Dienst laufen kann | Nein — bewusst nur lesend; acht Tools sind die gesamte Fläche | Gar kein Schreiben; Repository im März 2026 angelegt und am selben Tag zuletzt aktualisiert | Doku-Review |
| Checkmk MCP Server | Event Console, Metrics API oder Business Intelligence über einen einfachen lokalen Prozess | Ja — dokumentiert sind Monitoring-Aktionen wie Downtimes und Acknowledgements | Selbstbeschreibung production ready; der letzte Commit stammt aus September 2025 | Doku-Review |
| StackOne Checkmk MCP | Selbst nichts betreiben — ein gehosteter Endpunkt, OAuth- und Token-Verwaltung übernimmt der Anbieter | Ja — 68 vorgefertigte Aktionen, Konfigurationszugriffe eingeschlossen | Checkmk-Credentials und Monitoring-Daten laufen durch die Infrastruktur von StackOne | Doku-Review |
| ToolMesh + Checkmk DADL unser Projekt | Checkmk neben weiteren Systemen hinter einem kontrollierten Endpunkt — oder die größte dokumentierte Reichweite in Checkmk hinein | Ja — über Monitoring und Setup, live verifiziert einschließlich eines vollen Schreibzyklus | Ein stehender Dienst, den man betreibt; HW/SW-Inventur, Agent Registration und DCD bleiben außer Reichweite | Live geprüft |
| vibeMK | Schreiben gegen ein Checkmk, ohne einen Dienst zu betreiben — ein Python-Prozess, den der LLM-Client startet | Ja — die breiteste Schreibabdeckung unter den Optionen ohne eigenen Dienst | Selbstauskunft Alpha; letzter Commit August 2025 | Doku-Review |
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.
Ein bewusst kleiner, rein lesender MCP-Server: acht Tools für Hosts, Services, Downtimes, Ordner und Tags. Unter den dedizierten Checkmk-Servern hier ist er der einzige, den man selbst als zentralen HTTP-Dienst betreiben kann — mit optionaler OAuth-2.0-JWT-Prüfung — statt als Subprozess je Nutzer. Repository im März 2026 angelegt und am selben Tag zuletzt aktualisiert.
37 Tools in acht Kategorien und die breiteste Abdeckung der Checkmk-Spezialsysteme in dieser Liste: Event Console, Metrics API und Business Intelligence sind alle angebunden. Selbstbeschreibung „production ready"; der letzte Commit stammt aus September 2025.
Die einzige gehostete, kommerziell betriebene Option: 68 vorgefertigte Aktionen hinter einem StackOne-Endpunkt, OAuth-Tokenaustausch, -Speicherung und -Erneuerung übernimmt der Anbieter. Funktional ist es das, was hier einem Gateway am nächsten kommt — die einzige weitere Option mit dynamischer Tool-Discovery, einem Code Mode und einem Klassifikator für Prompt Injection in Tool-Antworten. Keine Installation, aber Checkmk-Credentials und Monitoring-Daten laufen durch die Infrastruktur von StackOne.
Kein Checkmk-spezifischer Server, sondern ein selbst gehostetes Gateway, das eine deklarative YAML-Beschreibung der Checkmk-REST-API liest — 146 Tools plus drei Composites, 63% der API-Fläche, seit dem 14. August 2026 einschließlich Event Console und Business Intelligence. Governance (Autorisierung je Tool, serverseitige Credentials, Output-Policies, Audit) kommt vom Gateway, nicht vom Connector. Weiter offen: HW/SW-Inventur, Agent Registration, DCD, LDAP-Verbindungen und historische Event-Console-Events, die Checkmk nur auf einer unstable-API-Version anbietet.
Unser Projekt — siehe Offenlegung unten
Das sichtbarste Community-Projekt — im Checkmk-Forum angekündigt, wo Checkmk-Mitarbeiter positiv reagierten. Unter den Optionen, die als einfacher lokaler Prozess laufen, dokumentiert sein README Schreibzugriff über die meisten Checkmk-Konfigurationsobjekte: Hosts, Ordner, Regeln, Benutzer, Tags und Massenanlage von Hosts. StackOne und ToolMesh, die als Dienst laufen, dokumentieren Schreibzugriff über mehr Objekttypen. Eine Toolzahl nennt vibeMK nicht — das ist also aus den dokumentierten Funktionsbereichen gelesen, keine gemessene Fläche. Das README bezeichnet es als Alpha, der letzte Commit stammt aus August 2025.
Zeilen sind die zehn Dimensionen, Spalten die Optionen. Die Tabelle scrollt horizontal. Hochgestellte Zahlen verlinken den Beleg 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 — wir korrigieren die Datendatei.
| Dimension | CheckMCP | Checkmk MCP Server | StackOne Checkmk MCP | ToolMesh + Checkmk DADL unser Projekt | vibeMK |
|---|---|---|---|---|---|
| Maintainer-Typ | Community — ein Maintainer 1 | Community — ein Maintainer 2 | Kommerzieller Anbieter 3 | Hersteller — Dunkel Cloud GmbH (Herausgeber dieser Seite) 6 | Community — ein Maintainer 7 |
| Lizenz | MIT 1 | MIT 2 | Proprietär (SaaS) 3 | Apache-2.0 (Gateway und DADL-Registry) 6 | GPL-3.0 5 |
| Runtime & Installation | Python 3.12+; Docker Compose, Docker oder manuell 1 | Python 3.8+; git clone und pip install 2 | Keine — gehosteter Endpunkt 3 | Ein Go-Binary; das DADL ist eine YAML-Datei in backends.yaml 4 | Python 3.8+; git clone 5 |
| Letzte Code-Aktivität | 14.03.2026 — angelegt und am selben Tag zuletzt gepusht 1 | 02.09.2025 2 | Nicht anwendbar — kein öffentliches Repository 3 | 11.08.2026 6 | 29.08.2025 5 |
| Öffentliches Adoptionssignal | 0 Sterne, 0 Forks 1 | 1 Stern, 2 Forks 2 | Nicht veröffentlicht 3 | 5 Sterne, 0 Forks 6 | 16 Sterne, 9 Forks 5 |
| Reifegrad (Selbstauskunft) | Keine Angabe 1 | "Production ready" 2 | Als Produktions-Connector vermarktet 3 | Gateway ist pre-1.0; das Checkmk-DADL ist live verifiziert 6 | „Alpha stage and under development" 5 |
| Tools / Aktionen | 8 Tools 1 | 37 Tools in 8 Kategorien 2 | 68 Aktionen insgesamt; die CRUD-Filter des Anbieters decken davon 49 ab (12 create, 15 read, 11 update, 11 delete), die restlichen 19 sind nicht aufgeschlüsselt 3 | 146 Tools + 3 Composites — 63% von ~230 REST-Endpunkten 4 | Nicht dokumentiert; das README nennt fünf Funktionsbereiche 5 |
| Lesen / Schreiben / Löschen | Nur lesend — „currently only supports read operations" 1 | Lesen und Schreiben (Downtimes, Acknowledgements) 2 | Lesen, Schreiben und Löschen 3 | Lesen, Schreiben und Löschen; jedes Tool trägt eine Zugriffsstufe 4 | Lesen und Schreiben — Hosts, Ordner, Regeln, Benutzer, Tags, Massenanlage 5 |
| Monitoring vs. Setup | Monitoring-Lesezugriffe plus Ordner und Tags 1 | Beides — Host-/Service-Verwaltung und Wartungsplanung 2 | Beides — CRUD über Hosts, Ordner, Services und Konfiguration 3 | Beides — Statusabfragen über die Livestatus-Query-Ausdrücke der REST-API plus breite Abdeckung des Setup-Baums 4 | Beides — Live-Monitoring und Konfigurationsverwaltung 5 |
| Event Console, BI, Metriken, Inventur | Keines davon 1 | Event Console, Metrics API und Business Intelligence 2 | Nicht dokumentiert 3 | Event Console, Business Intelligence und Metriken seit dem 14.08.2026 alle abgedeckt; HW/SW-Inventur, Agent Registration, Agent Bakery und DCD nicht 4 | Metriken; BI und Agent Bakery als Enterprise-Features gelistet 5 |
| Verfahren gegenüber Checkmk | Checkmk-Credentials aus einer YAML-Konfigdatei (CONFIG_PATH) 1 | Automation-User über YAML-Konfigdatei oder Umgebungsvariablen 2 | OAuth über eine StackOne Connect Session 3 | Automation-User-Bearer-Token („<user> <secret>"), serverseitig zur Aufrufzeit injiziert 4 | Automation-User, Administrator-Rolle empfohlen 5 |
| Wo das Secret liegt | Auf dem Host, der CheckMCP betreibt 1 | Auf dem Client-Rechner (Konfigdatei oder .env) 2 | In der Cloud von StackOne — der Anbieter speichert und erneuert 3 | Serverseitig im Credential Store des Gateways; es wird zur Aufrufzeit injiziert und nicht an Client oder Modell gegeben 8 | In der LLM-Client-Konfiguration oder einer .env auf dem Client 9 |
| Wer den Server aufrufen darf | OAuth-2.0-JWT-Prüfung gegen einen externen IdP, oder keine 1 | Nicht anwendbar — lokaler Subprozess eines Clients 2 | StackOne-API-Key; Nutzer über origin_owner_id isoliert 3 | Authentifizierte Gateway-Nutzer mit eigener Identität 8 | Nicht anwendbar — lokaler Subprozess eines Clients 5 |
| Least Privilege | Konstruktionsbedingt nur lesend 1 | Über die Checkmk-Rolle des Automation-Users 2 | Aktionen lassen sich im StackOne-Dashboard einschränken 3 | Checkmk-Rolle plus Autorisierung je Tool und Nutzer im Gateway 10 | Über die Checkmk-Rolle; das README empfiehlt eine Read-only-Rolle für reine Analysen 5 |
| Betriebsmodus | Selbst gehosteter HTTP-Dienst (Docker Compose, Docker oder Python) 1 | Lokaler Subprozess auf dem Client-Rechner 2 | SaaS — vom Anbieter betriebener Endpunkt 3 | Selbst gehostetes Gateway (Binary oder Container) 6 | Lokaler Subprozess auf dem Client-Rechner 5 |
| Datenpfad | Client → CheckMCP → Checkmk; kein Dritter 1 | Client → lokaler Server → Checkmk; kein Dritter 2 | Client → StackOne-Cloud → Checkmk; Monitoring-Daten und Credentials laufen durch die Infrastruktur des Anbieters 3 | Client → eigenes Gateway → Checkmk; kein Dritter 6 | Client → lokaler Server → Checkmk; kein Dritter 5 |
| Funktioniert mit abgeschottetem On-Prem-Checkmk | Ja — läuft im eigenen Netz 1 | Ja — läuft auf dem Rechner des Betreibers 2 | Nicht dokumentiert — ein gehosteter Endpunkt muss Checkmk erreichen 3 | Ja — das Gateway läuft im eigenen Netz 6 | Ja — läuft auf dem Rechner des Betreibers 5 |
| Checkmk-Versionen | Getestet mit Raw Edition 2.3.0p23 1 | 2.4.0 oder neuer erforderlich 2 | Nicht dokumentiert 3 | Zielt auf 2.4/2.5, live verifiziert auf 2.5.0p11; die meisten Tools laufen auch auf 2.2/2.3, Ausnahmen je Tool dokumentiert 4 | 2.4.x und 2.3.x vollständig; 2.2/2.1/2.0 ungetestet; 1.6 nicht unterstützt 5 |
| Editions-Abhängigkeiten | Raw Edition getestet 1 | Nicht je Edition angegeben 2 | Nicht dokumentiert 3 | Auf einer Community-(Raw-)Edition verifiziert, einschließlich Event Console und BI, die Checkmk für alle Editionen registriert; CEE-only-Endpunkte wie Agent Bakery und Signaturschlüssel sind nicht abgedeckt 4 | Raw = Basisfunktionen; BI, Agent Bakery und Metriken unter Enterprise/Cloud gelistet 5 |
| Tool-Allow/Deny | Nicht dokumentiert 1 | Nicht dokumentiert 2 | Ja — Aktionen je Connector schaltbar, und Session-Tokens lassen sich auf bestimmte Aktionen eingrenzen 3 | Ja — Policies je Tool und Nutzer; vier Zugriffsstufen je Tool 10 | Nicht dokumentiert 5 |
| Read-only-Modus | Inhärent — es gibt keine Schreib-Tools 1 | Nicht dokumentiert — Read-only-Checkmk-Rolle verwenden 2 | Annäherung durch Abwählen der Schreibaktionen 3 | Über Autorisierungs-Policy und/oder Read-only-Checkmk-Rolle 10 | Nicht dokumentiert — Read-only-Checkmk-Rolle verwenden 5 |
| Audit-Trail im Connector | Nicht dokumentiert — das Checkmk-Audit-Log greift weiterhin 1 | Nicht dokumentiert — das Checkmk-Audit-Log greift weiterhin 2 | Anbieterseitiges Logging; Details nicht veröffentlicht 3 | SQL-abfragbares Log je Aufruf, Nutzer und Caller zugeordnet 6 | Nicht dokumentiert — das Checkmk-Audit-Log greift weiterhin 5 |
| DLP / Redaction von Antworten | Nicht dokumentiert 1 | Nicht dokumentiert 2 | Keine Redaction von Antworten dokumentiert; die Exposition wird stattdessen über Aktions- und Session-Token-Scoping begrenzt 3 | Output Gate — JS-Policies vor und nach der Ausführung, mit Redaction 11 | Nicht dokumentiert 5 |
| Distribution & Pinning | Docker-Image oder git clone; kein signiertes Release dokumentiert 1 | git clone; kein veröffentlichtes Paket, kein signiertes Release 2 | Vom Anbieter betrieben; kein Artefakt zum Pinnen 3 | Getaggte Releases und Container-Images; die Checkmk-Beschreibung ist eine versionierte YAML-Datei in einer öffentlichen Registry 4 | git clone; ein Dritter hat es unter anderem Namen auf PyPI wiederveröffentlicht — nicht der Kanal des Maintainers 12 |
| Dependency-Fläche | Python plus requirements.txt 1 | Python plus requirements.txt 2 | Undurchsichtig — vom Anbieter betrieben 3 | Ein statisches Go-Binary; Checkmk hinzuzufügen bringt keine weitere Laufzeitabhängigkeit, nur eine YAML-Datei 6 | Python plus requirements.txt 5 |
| Abwehr von Prompt Injection | Nicht dokumentiert 1 | Nicht dokumentiert 2 | Bringt einen Klassifikator mit (StackOne Defender, Apache-2.0, Anbieterangabe F1 90,8%); ob er auf diesem Connector standardmäßig aktiv ist, ist nicht dokumentiert 13 | Kein Klassifikator mitgeliefert; Antworttext lässt sich in einer Output-Gate-Post-Policy prüfen, standardmäßig tut das keine 11 | Nicht dokumentiert 5 |
| Transport | HTTP, standardmäßig Port 8000 1 | stdio 2 | Remote-HTTP-Endpunkt 3 | Streamable HTTP; stdio beim lokalen Betrieb des Gateways als Einzelnutzer-Subprozess 14 | stdio, aus der LLM-Client-Konfiguration gestartet 5 |
| Remote-/mehrbenutzerfähig | Ja — HTTP mit optionaler OAuth-JWT-Prüfung 1 | Nein — ein Subprozess je Client 2 | Ja — mehrbenutzerfähig mit Isolation je Nutzer 3 | Ja — mehrbenutzerfähig mit Autorisierung je Nutzer 10 | Nein — ein Subprozess je Client 5 |
| Katalogkosten im Kontext | 8 Tools — vernachlässigbar 1 | 37 Tools werden vorab geladen 2 | 68 Aktionen, aber Tool-Discovery und ein „Code Mode", der rohe Antworten in einer Sandbox hält, drücken den geladenen Kontext — laut Anbieter massive Token-Einsparungen 15 | 146 Tools, aber Code Mode ersetzt den Katalog durch zwei Meta-Tools und hält den geladenen Kontext nahezu konstant — massive Token-Einsparungen, die genaue Rate hängt vom Anwendungsfall ab 16 | Nicht dokumentiert 5 |
| Discovery | Statische Tool-Liste 1 | Statische Tool-Liste 2 | Dynamische Tool-Discovery — laut Anbieter werden je Anfrage nur passende Aktionen geladen, über eine hybride lexikalische Suche 15 | Progressive, gerankte Tool-Discovery 16 | Statische Tool-Liste 5 |
| Pending Changes & Aktivierung | Nicht anwendbar — nur lesend 1 | Nicht dokumentiert 2 | Nicht dokumentiert 3 | Explizit — Tools zum Auflisten und Aktivieren von Pending Changes plus ein Composite, das sie anwendet; die Trennung Monitoring/Setup ist für das Modell dokumentiert 4 | Im README nicht dokumentiert 5 |
| Nebenläufigkeit (ETag / If-Match) | Nicht anwendbar — nur lesend 1 | Nicht dokumentiert 2 | Nicht dokumentiert 3 | Sendet standardmäßig If-Match, das Checkmk für schreibende Requests verlangt (sonst HTTP 428) 4 | Nicht dokumentiert 5 |
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:
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.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.Wer einen dieser Fälle hat, ist mit einem REST-Gateway grundsätzlich falsch bedient — unabhängig davon, wer es baut.
Ein Gateway rechnet sich, wenn Checkmk nicht das einzige System im Bild ist:
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.
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. Er weist 146 Tools plus drei Composites aus, 63% von etwa 230 Endpunkten, mit ausdrücklich benannten Lücken.
Nein. Stand August 2026 hat die Checkmk GmbH keinen MCP-Server veröffentlicht. Checkmk 2.5 hat im April 2026 die Funktion „Explain with AI" ergänzt, die aber in der Checkmk-GUI läuft, auf die Cloud Edition beschränkt ist und von einem externen KI-Agenten nicht aufgerufen werden kann. Als vibeMK im August 2025 im Checkmk-Forum vorgestellt wurde, antwortete ein Checkmk-Mitarbeiter, dass intern an KI-Initiativen gearbeitet werde — ohne einen MCP-Server anzukündigen.
Beides, je nach Option. CheckMCP ist bewusst nur lesend. Die anderen vier unterstützen Schreibzugriffe in unterschiedlicher Tiefe: Der Checkmk MCP Server dokumentiert Downtimes und Acknowledgements, vibeMK, StackOne und ToolMesh dokumentieren darüber hinaus Konfigurationszugriffe wie das Anlegen von Hosts und Ordnern oder das Bearbeiten von Regeln. Zu beachten: Checkmk trennt zwei Welten. Monitoring-Aktionen wie Downtimes wirken sofort, Setup-Änderungen werden als Pending Changes vorgemerkt und tun nichts, bis sie aktiviert werden.
Zwei davon. Der Checkmk MCP Server (jlk/checkmk-llm-server) dokumentiert Abdeckung von Event Console, Metrics API und Business Intelligence. Das ToolMesh-Checkmk-DADL hat beides am 14. August 2026 ergänzt — sieben Event-Console- und vierzehn BI-Tools, verifiziert gegen eine laufende Checkmk-2.5.0p11-Site. vibeMK führt BI und Agent Bakery als Enterprise-Features, obwohl Checkmk BI und Event Console tatsächlich für jede Edition registriert, Raw eingeschlossen. CheckMCP deckt keines von beidem ab. Eine Grenze gilt für alle: Historische Event-Console-Events gibt Checkmk nur auf einer als unstable markierten API-Version heraus, keine REST-basierte Option erreicht sie.
Das ist einer der deutlichsten Unterschiede zwischen den Optionen. vibeMK und der Checkmk MCP Server lesen das Secret des Automation-Users aus der Konfiguration des LLM-Clients oder einer .env-Datei auf dem Rechner des Operators. CheckMCP liest es aus einer YAML-Datei auf dem Host, auf dem es läuft. StackOne speichert und erneuert das Credential in der eigenen Cloud, und die Monitoring-Daten laufen durch die Infrastruktur von StackOne. ToolMesh hält es serverseitig im Gateway und injiziert es zur Aufrufzeit, sodass es nie in einer Client-Konfiguration auftaucht.
Die vier selbst gehosteten Optionen ja, weil sie im eigenen Netz laufen. Für den gehosteten StackOne-Connector ist das nicht dokumentiert, und ein vom Anbieter betriebener Endpunkt braucht einen Weg, die eigene Checkmk-Site zu erreichen.
Das variiert und ist relevant. CheckMCP ist gegen Raw Edition 2.3.0p23 getestet. Der Checkmk MCP Server verlangt 2.4.0 oder neuer. vibeMK meldet volle Unterstützung für 2.4.x und 2.3.x, ältere Releases ungetestet und 1.6 nicht unterstützt. Das ToolMesh-DADL zielt auf 2.4 und 2.5 und wurde auf 2.5.0p11 live verifiziert. StackOne dokumentiert keine Versionsunterstützung.
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.
Offenlegung. Diese Seite wird von der Dunkel Cloud GmbH 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. 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.