MCP: Beispiele und Arbeitsabläufe

Nutze diese Prompts mit einem verbundenen ChatGPT, Claude oder einem anderen MCP-Client. Lies zuerst Überblick und Zugriffe. Ersetze die Platzhalter in eckigen Klammern durch deine gewünschten Ziele; füge keine Passwörter oder Token in eine Unterhaltung ein.

Lass den Assistenten vor einer Aktion die Ziele ermitteln, Änderungen von dir bestätigen und das Ergebnis erneut abfragen. Prompts sind Anweisungen an das Modell, keine Sicherheitsgrenze: Erteile nur die für die Aufgabe nötigen Zugriffe.

Mit einer rein lesenden Gerätesuche beginnen

Der Client benötigt octoja-Daten anzeigen. Ergebnisse bleiben auf die Geräte und Kunden beschränkt, auf die dein Konto zugreifen darf.

Suche mit octoja nach Geräten, die zu [Gerätename] passen. Zeige die Treffer mit ihren Kunden, damit ich das richtige Gerät auswählen kann. Ändere nichts und führe keine Skripte aus. Melde Zugriffsfehler, statt zu raten.

Prüfe, ob der Assistent tatsächlich list_devices aufruft. Ein erfolgreicher Aufruf ohne Treffer ist kein Verbindungsfehler; prüfe den Suchbegriff und die Zugriffe deines Kontos.

Geräte- und Kundendaten ändern

Finde [Gerätename] in octoja und zeige den aktuellen Anzeigenamen und die ID. Bereite vor, nur den Gerätealias auf [neuer Alias] zu setzen. Warte vor dem Speichern auf meine Bestätigung. Lies dasselbe Gerät danach erneut aus und zeige den aktualisierten Anzeigenamen.

update_device ändert Gerätefelder und benötigt octoja-Daten anzeigen, Änderungen in octoja vornehmen und die Geräteaktion Gerät bearbeiten. update_customer benötigt Schreibzugriff und die Berechtigung Kundenverwaltung. Kunden- und Gerätezugriffsgrenzen gelten weiterhin. Mit list_custom_fields kann der Assistent zunächst verfügbare eigene Felder und deren Typen ermitteln.

Prüfe vor einer Änderung Ziel und gewünschte Felder. Die Aktualisierungswerkzeuge für Geräte, Kunden, Fälle und eigene Checks verwenden Änderungsobjekte: Nur Felder mit hasValue: true werden geändert; value: null leert ein Feld nur, wenn dieses Nullwerte erlaubt. Nicht gesetzte Felder bleiben unverändert. Bei Kunden ersetzen übergebene Tags die gesamte Tag-Liste, sie werden nicht bloß ergänzt. Lass dir das Ergebnis anschließend erneut anzeigen.

Geräteaktionen ausführen oder planen

Finde [Gerätename] und zeige das genaue Ziel. Bereite einen Neustart für [zukünftiges Datum und Ortszeit mit UTC-Offset] vor. Plane ihn erst nach meiner Bestätigung ein. Zeige danach den geplanten Lauf und seinen Status; bezeichne ihn erst als erfolgreich ausgeführt, wenn das Laufergebnis dies bestätigt.

Ein vertrauenswürdiger Client kann Geräte neu starten, herunterfahren oder eine bestehende Automatisierung ausführen — sofort oder zu einem späteren Zeitpunkt. Dafür benötigt er Änderungen in octoja vornehmen und Skripte und Automatisierungen ausführen. Dein Konto benötigt außerdem Automatisierungen anzeigen und Skriptausführungsrechte auf den Zielgeräten. Zum Lesen von Definitionen und Ausführungsverlauf ist zusätzlich octoja-Daten anzeigen nötig.

1. Lass den Assistenten die Geräte mit list_devices ermitteln. Prüfe bei einer Automatisierung zuerst ihre Definition mit list_automations und get_automation.
2. Bestätige Zielgeräte und Aktion. schedule_device_action nimmt höchstens 500 Geräte-IDs und genau eines der Felder automationId oder powerAction (Restart oder Shutdown) an. Gib scheduledFor als zukünftigen Zeitstempel mit UTC-Offset an; ohne dieses Feld startet die Aktion sofort.
3. Prüfe geplante Läufe mit list_automation_runs und futureScheduledOnly: true. Jedes Gerät hat einen eigenen Lauf. Mit get_automation_run siehst du Status und Schrittergebnisse; ein angelegter Zeitplan bestätigt noch keine erfolgreiche Ausführung.
4. Brich einen unerwünschten Lauf mit cancel_automation_run und seiner Lauf-ID ab. Bereits erledigte Arbeit wird dadurch nicht rückgängig gemacht.

Bitte beispielsweise darum, ausdrücklich benannte Geräte zu einer konkreten Ortszeit mit UTC-Offset neu zu starten und dir anschließend die geplanten Läufe zu zeigen. Lass die Zeitzone nicht offen.

Entfernte Computer steuern

Finde [Gerätename] und liste die verfügbaren Benutzersitzungen auf. Frage mich, welche Sitzung du öffnen sollst. Erfasse nach meiner Auswahl den Bildschirm und beschreibe, was sichtbar ist, ohne zu klicken oder zu tippen. Schließe die Sitzung anschließend.

Die zusätzliche Freigabe Entfernte Computer steuern erlaubt einem vertrauenswürdigen Assistenten, Screenshots zu sehen und Maus sowie Tastatur auf einem Online-Gerät unter Windows oder macOS zu bedienen. Sie ist standardmäßig nicht ausgewählt und unabhängig von Live-Daten, Schreibzugriff und Skriptausführung. Bestätige die zusätzliche Warnung nur, wenn der Client diese interaktive Kontrolle erhalten soll. Für eine bestehende Verbindung ohne diese Freigabe musst du die Verbindung erneut autorisieren.

Deine Geräteaktion Remotedesktop und die Einstellungen für Benutzerzustimmung und Sperren beim Trennen gelten weiterhin. Der Client kann eine erforderliche Zustimmung nicht über einen eigenen Umgehungsparameter ersetzen. Unter macOS benötigt der Agent außerdem die Systemfreigaben für Bildschirmaufnahme und Bedienungshilfen; erteile sie am Gerät über den Berechtigungsdialog des Agenten.

1. Lass das Zielgerät identifizieren und mit list_computer_targets die verfügbaren Benutzersitzungen abfragen.
2. Öffne die gewünschte Sitzung mit open_computer. Die Antwort enthält eine Sitzungs-ID, einen PNG-Screenshot von Bildschirm 0 und die verfügbaren Bildschirme.
3. Lass den Assistenten zuerst den Screenshot prüfen. Mit computer und einer leeren Aktionsliste kann er weitere Bildschirme ansehen. Vor Eingaben auf einem anderen Bildschirm muss er diesen ohne Eingaben erfassen; Koordinaten beziehen sich immer auf dessen zuletzt gelieferten Screenshot.
4. Begrenze die Aufgabe ausdrücklich. Klicks, Texteingaben, Tastenkombinationen, Scrollen und Ziehen sind echte Eingaben in den Programmen des angemeldeten Benutzers. Prüfe den zurückgegebenen Screenshot nach jeder Aktion.
5. Beende die Sitzung mit close_computer. Inaktive Sitzungen werden nach etwa zehn Minuten geschlossen. Das Trennen des MCP-Clients beendet ebenfalls seine Computersitzungen.

Diagnosedaten zuverlässig abfragen

Untersuche Windows-Ereignisfehler auf [Gerätename], ohne Änderungen vorzunehmen. Liste zuerst die verfügbaren Ereigniskanäle auf und lass mich einen auswählen. Fasse die zurückgegebenen Fehler zusammen, trenne Beobachtungen von möglichen Ursachen und nenne Einschränkungen oder fehlgeschlagene Abfragen.

Lass den Assistenten das Zielgerät zuerst identifizieren und den Umfang eingrenzen, etwa auf einen bestimmten Ereigniskanal oder einen Ordner. Live-Werkzeuge benötigen zusätzlich zur MCP-Freigabe die jeweilige Geräteaktion; ein sichtbares Gerät allein berechtigt nicht zum Lesen seiner Dateien oder zum Ausführen von Skripten.

• Für Windows-Ereignisse liste zuerst die verfügbaren Kanäle auf. Eine aufgelistete Quelle kann beim Lesen trotzdem vom Gerät abgelehnt werden. Gib dem Assistenten dann den gemeldeten Fehler und wähle einen lesbaren Kanal. Eine Abfrage liefert höchstens 100 Ereignisse; das ist keine vollständige Ereignishistorie.
• Ein Dateiarchiv wird über einen Download-Link zurückgegeben, sowohl als Text als auch als Ressourcenlink für Clients, die diesen darstellen. Der Link ist nur einmal und für fünf Minuten nutzbar. Lade das Archiv zeitnah herunter und behandle den Link vertraulich; nach Verbrauch oder Ablauf fordere ein neues Archiv an.
• Bei Skriptfehlern beachte den Ausführungsstatus und die Fehlerausgabe. Eine Textausgabe allein bestätigt keinen erfolgreichen Lauf. Lass den Assistenten Fehler berichten, statt leere oder unvollständige Daten als gesunden Zustand auszulegen.

Einfache SNMP-Checks erstellen und testen

Lies die octoja-Anleitung zum Erstellen eigener Checks. Hilf mir, einen einfachen SNMP-Check für [Messwert und OID] auf [Netzwerkgerät] vorzubereiten. Frage nach fehlenden Anforderungen, schlage die Konfiguration vor und warte vor einem Live-Test auf meine Bestätigung. Zeige Status und Messwerte. Speichere den Check erst nach einer gesonderten Bestätigung.

Lass den Assistenten zuerst describe_custom_check_authoring lesen. Mit create_custom_check, mode: "Snmp" und snmpConfig erstellt er einen einfachen SNMP-Check; Skripte, Eingabedefinition und Ausgabefelder werden automatisch erzeugt. Dafür benötigt der Client octoja-Daten anzeigen und Änderungen in octoja vornehmen, dein Konto außerdem Verwaltung benutzerdefinierter Checks. Verwende vorzugsweise die SNMP-Verbindungseinstellungen des Netzwerkgeräts, statt Zugangsdaten in einer gemeinsam genutzten Check-Definition zu hinterlegen.

Teste die Konfiguration vor dem Speichern mit live_test_script, der Zielgeräte-ID, der Plattform des ausführenden Agents und snmpConfig; übergib dabei weder script noch inputDefinition. Der Test speichert keinen Check. Ein Netzwerkgerät nutzt seinen zugewiesenen, online erreichbaren Überwachungsagenten. Der Client benötigt Skripte und Automatisierungen ausführen, dein Konto Monitoring-Check-Verwaltung und Skriptausführungsrechte auf Ziel und Überwachungsgerät. verified: true bestätigt eine gültige Ausführung und ein lesbares Ergebnis, nicht zwangsläufig den Status OK: Auch Warning oder Critical können gültige Ergebnisse sein.

Prüfe den gespeicherten Check mit get_custom_check. Bei update_custom_check ersetzt ein gesetztes snmpConfig die gesamte SNMP-Konfiguration; sende keine automatisch erzeugten Skripte oder Felddefinitionen mit.