Checks mit MCP migrieren oder erstellen

Mit dem octoja MCP kann ein KI-Assistent bestehende Monitoring-Skripte an octoja anpassen oder aus deiner Beschreibung einen neuen eigenen Check erstellen. Du prüfst den Entwurf, lässt ihn auf einem ausgewählten Testgerät ausführen und speicherst ihn anschließend in der Check-Bibliothek. Für diesen Weg brauchst du keinen Zugang zum Migrationsportal.

Wenn du mehrere PowerShell-Skripte gesammelt hochladen und übersetzen möchtest, nutze alternativ den Check-Importer. Der MCP-Weg eignet sich besonders, wenn du Anforderungen im Gespräch klären und den Check schrittweise verbessern möchtest. Er verbindet sich nicht automatisch mit deinem alten RMM: Stelle das Quellskript oder eine Beschreibung der bisherigen Überwachung bereit.

Voraussetzungen

• Ein verbundener MCP-Client, etwa ChatGPT oder Claude. Die Einrichtung und die Berechtigung MCP-Nutzung erklärt Überblick und Zugriffe.
• Ein geeignetes Testgerät mit installiertem, online erreichbarem octoja-Agent und den vom Skript benötigten Programmen.
• Die folgenden Freigaben und Berechtigungen:

Erteile Skriptausführungsrechte nur einem vertrauenswürdigen Client. Ein Live-Test führt echten Code auf dem Gerät aus, auch wenn der Check noch nicht gespeichert ist. Die Freigabe Live-Gerätezugriff ist für live_test_script nicht zusätzlich erforderlich.

Schritt 1 – Vorlage oder Anforderungen vorbereiten

Für eine Migration exportierst oder kopierst du das Monitoring-Skript aus deinem bisherigen RMM. Notiere zusätzlich die Einstellungen, die dort außerhalb des Skripts hinterlegt sind. Wenn kein Skript vorhanden ist, beschreibe stattdessen die gewünschte Überwachung.

Halte in beiden Fällen fest:

• Betriebssystem und benötigte Programme oder Module.
• Eingabeparameter, Standardwerte und Einheiten.
• Bedingungen für OK, Warnung und kritisch, einschließlich der Grenzwerte und des Verhaltens bei fehlenden Daten.
• Prüfintervall und gewünschte Ausgabe, etwa Messwerte, Statustext und Verlauf.

Variablen, Module und Exitcodes deines alten RMM funktionieren nicht automatisch unverändert in octoja. Lass den Assistenten solche Abhängigkeiten und offene Annahmen benennen, statt sie stillschweigend zu ersetzen.

Schritt 2 – Den Check im Gespräch entwerfen

Beginne mit einem Check. Ersetze die Platzhalter in den folgenden Prompts durch deine Anforderungen und füge das bereinigte Quellskript bei einer Migration als Datei oder Text hinzu.

Bestehenden Check migrieren

Verwende den octoja MCP und übertrage das beigefügte Monitoring-Skript aus [Quell-RMM] in einen eigenen octoja-Check für [Betriebssystem]. Lies zuerst describe_custom_check_authoring und prüfe mit list_custom_checks, ob bereits ein passender eigener Check vorhanden ist. Erhalte die bisherige Bedeutung der Statuswerte und Grenzwerte. Mache bisherige RMM-Variablen zu konfigurierbaren Eingabeparametern. Zeige mir den angepassten Code, die Parameter, Ausgabefelder, Ergebnisanzeige und alle Annahmen. Führe noch nichts aus und speichere nichts; frage bei unklarer Logik nach.

Einen neuen Check erstellen

Verwende den octoja MCP und entwirf einen eigenen Windows-Check für das Alter einer Sicherungsdatei. Lies zuerst describe_custom_check_authoring und prüfe, ob bereits ein passender eigener Check vorhanden ist. Dateipfad und Grenzwerte sollen konfigurierbar sein: ab 24 Stunden Warnung, ab 48 Stunden kritisch, bei fehlender Datei ebenfalls kritisch. Intervall: 15 Minuten. Zeige Alter und Zeitpunkt der letzten Änderung im Ergebnis und das Alter im Verlauf. Der Check darf nur lesen, keine Dateien ändern. Zeige mir zuerst Code, Parameter und Ergebnisanzeige; führe noch nichts aus und speichere nichts.

Der Assistent erhält das aktuelle Format über describe_custom_check_authoring; du musst ihm kein vollständiges JSON-Schema vorgeben. Bei eigenen Skript-Checks wird der Status über checkResult gemeldet: 0 für OK, 1 für Warnung und 2 für kritisch. PowerShell nutzt dafür $output.checkResult und liest Parameter aus $checkInput; Bash nutzt set_result, set_output und get_input. octoja ergänzt das Ausgabeformat. Lass Status-Exitcodes ersetzen und zusätzliche Konsolenausgaben entfernen, damit sie die Ergebnisausgabe nicht stören. Details stehen unter Benutzerdefiniertes Skript.

Schritt 3 – Prüfen und live testen

Lies den Entwurf und prüfe besonders die Statuszuordnung, Einheiten, Abhängigkeiten und das Verhalten bei Fehlern. Der Check sollte fehlende oder unlesbare Daten nicht stillschweigend als OK melden.

Wenn der Entwurf passt, kannst du den Test gezielt freigeben:

Ermittle [Testgerät] mit list_devices und zeige mir die Geräte-ID und das Betriebssystem zur Bestätigung. Führe nach meiner Bestätigung nur den geprüften Entwurf dort mit live_test_script aus. Übergib die Eingabedefinition und die vereinbarten Testparameter. Berichte verified, Status, Ausgabewerte und Fehler. Speichere weiterhin keinen Check und teste keine anderen Geräte.

live_test_script testet das Skript, ohne einen Check zu speichern. verified: true bedeutet, dass die Ausführung erfolgreich war und ein gültiges Ergebnis mit Status OK, Warning oder Critical vorliegt. Es bestätigt weder ausschließlich OK noch die fachliche Richtigkeit der Überwachung. Prüfe deshalb die gemeldeten Werte gegen den tatsächlichen Zustand.

Teste neben dem Normalfall auch Warnung, kritisch und fehlende Daten. Beim Beispiel mit der Sicherungsdatei gehören die Grenzen von genau 24 und 48 Stunden dazu. Nutze kontrollierte Testdaten oder Testparameter, statt produktive Sicherungen zu verändern. Bei einer Migration vergleiche die Ergebnisse mit dem ursprünglichen Check. Ein einzelner erfolgreicher Lauf reicht nicht aus, um alle Statusfälle zu prüfen.

Schritt 4 – Speichern und schrittweise zuweisen

1. Gib das Speichern erst frei, wenn Code und Tests passen. Der Assistent legt den Check mit create_custom_check an und liest ihn mit get_custom_check anhand der zurückgegebenen ID erneut ein. Prüfe Name, Plattformen, Intervall, Parameter und Ergebnisanzeige.
2. Öffne in octoja Konfiguration → Check-Bibliothek und aktiviere bei Bedarf Nur eigene Checks. Das Erstellen macht den Check in der Bibliothek verfügbar, weist ihn aber noch keinem Gerät zu.
3. Weise ihn zunächst nur dem Testgerät unter Checks → Check hinzufügen zu und prüfe einen geplanten Lauf mit den tatsächlichen Parametern. Die Zuweisung erfolgt in der octoja-Oberfläche, nicht über die MCP-Werkzeuge zur Check-Erstellung.
4. Rolle den Check erst danach über Konfigurationspakete breiter aus. Der Assistent kann mit get_device_checks die Zuweisung und mit get_check_history die gemeldeten Ergebnisse prüfen.

Soll ein vorhandener eigener Check angepasst werden, lass ihn zuerst mit get_custom_check einlesen und Änderungen mit update_custom_check speichern, statt einen zweiten Check anzulegen. Prüfe vorher, auf welchen Geräten er bereits eingesetzt wird: Änderungen an einem verwendeten Check können bestehende Zuweisungen betreffen.

Für einen einfachen OID-basierten Netzwerkcheck gibt es außerdem den Modus Einfaches SNMP, bei dem octoja die Skripte erzeugt. Den passenden Prompt und die Testvoraussetzungen findest du unter Einfache SNMP-Checks erstellen und testen.