Eigene KI-Workflows bauen: Skills, Cron-Jobs & Custom MCP Tools) in OpenClaw

KI-Workflows: Skills, Cron-Jobs & MCP-Tools in OpenClaw steht im Mittelpunkt dieses Guides. Die meisten nutzen KI-Agenten als bessere Chatbots. Du tippst, er antwortet, vielleicht sucht er im Web. Nett, aber das ist wie einen Sportwagen kaufen und nur zum Supermarkt fahren.

So sieht unsere Realität aus: Wir betreiben 13 Cron-Jobs, 78 eigene MCP-Tools und mehrere Skills im Produktivbetrieb. Unser Agent veröffentlicht Blog-Posts in vier Sprachen, pflegt Social-Media-Engagement, überwacht unseren Posteingang, generiert gebrandete Bilder und managt Content-Pipelines — vollautomatisch. Jeden einzelnen Tag.

Das hier ist kein Einsteiger-Guide. Dafür lies unseren Kompletten OpenClaw-Guide. Dieser Beitrag handelt davon, echte Automatisierung zu bauen. Du bekommst Copy-Paste-Beispiele für Skills, Cron-Jobs und Custom MCP Tools — plus die Lektionen, die wir beim Produktiveinsatz gelernt haben.

Los geht's.

---

1. Skills — Deinem Agenten neue Tricks beibringen — KI-Workflows: Skills, Cron-Jobs & MCP-Tools in OpenClaw

Ein Skill in OpenClaw ist täuschend einfach: eine Markdown-Datei mit YAML-Frontmatter. Das war's. Kein spezielles SDK, kein Kompilierschritt, keine Deployment-Pipeline. Du schreibst eine SKILL.md-Datei, legst sie im richtigen Verzeichnis ab, und dein Agent kann plötzlich etwas Neues.

Anatomie eines Skills

~/.openclaw/workspace/skills/my-skill/
├── SKILL.md          # Pflicht: Instruktionen + Frontmatter
├── reference/        # Optional: zusätzliche Docs
│   └── api-docs.md
└── scripts/          # Optional: Hilfsskripte
    └── validate.sh

Das Frontmatter der SKILL.md sagt OpenClaw, was der Skill ist. Der Body sagt dem Agenten, wie er ihn nutzt. Hier ein echtes Beispiel — eine vereinfachte Version unseres Content-Publishing-Skills:

---
name: content-publisher
description: Blog-Posts und Social-Media-Content über MCP-Tools veröffentlichen.
---

# Content Publisher Skill

## Wann verwenden
- Nutzer möchte einen Blog-Post veröffentlichen
- Nutzer möchte Social-Media-Content erstellen

## Workflow
1. Thema mit `web_search` recherchieren
2. Keywords mit MCP `generate_keywords` generieren
3. Content nach SEO-Richtlinien schreiben
4. Hero-Image generieren
5. Im CMS veröffentlichen
6. Auf Social Media verbreiten

## Wichtige Regeln
- IMMER die Blog-URL auf Status 200 prüfen, bevor Social-Posts rausgehen
- Hero-Image in ALLEN Social-Posts einbinden
- In der angegebenen Sprache schreiben — keine Sprachen mischen
- Social-Media-Posts gehen auf ENGLISCH mit der englischen Blog-URL raus

Prioritäten zählen

OpenClaw lädt Skills aus drei Quellen, in dieser Reihenfolge:

1. Workspace (~/.openclaw/workspace/skills/) — deine eigenen Skills, höchste Priorität
2. Managed — über ClawHub installierte Skills
3. Bundled — mitgelieferte Skills

Das bedeutet: Du kannst jeden eingebauten Skill überschreiben, indem du einen mit dem gleichen Namen in deinem Workspace anlegst. Wir haben das gemacht, um den Web-Browsing-Skill mit unseren Login-Flows anzupassen.

Best Practices (auf die harte Tour gelernt)

Sei bestimmt. Schreib nicht „ziehe in Betracht, web_search zu verwenden, wenn es passt." Schreib „IMMER das Thema mit web_search recherchieren, bevor du schreibst." Der Agent arbeitet besser mit klaren Anweisungen.

Baue Leitplanken ein. Unser Content-Skill hat eine Regel: „IMMER die Blog-URL auf Status 200 prüfen, bevor Social-Posts rausgehen." Die haben wir hinzugefügt, nachdem der Agent kaputte Links auf Twitter gepostet hat. Zweimal.

Halte es kurz. Skills werden in das Kontextfenster des LLM injiziert. Ein 5.000-Wort-Skill frisst Tokens und verwirrt das Modell. Unsere effektivsten Skills haben unter 500 Wörter.

Füge einen „Wann verwenden"-Abschnitt hinzu. Das hilft OpenClaws Skill-Routing bei der Entscheidung, wann der Skill aktiviert wird. Ohne kann der Agent deinen Skill laden, wenn er ihn gar nicht braucht.

Pro-Tipp: Skills sind einfach strukturierte Prompts — das LLM liest sie als Kontext. Stell sie dir als „Expertenwissen auf Abruf" vor. Der Agent führt den Skill nicht wie Code aus; er liest den Skill und folgt den Anweisungen nach eigenem Ermessen. Das ist mächtig: Du kannst komplexe Workflows in einfachem Deutsch abbilden.

---

2. Cron-Jobs — Der Herzschlag deines Agenten

Wenn Skills deinem Agenten Wissen geben, geben Cron-Jobs ihm einen Zeitplan. OpenClaw hat einen eingebauten Scheduler, der über Neustarts hinweg persistiert — kein externer Cron-Daemon, keine systemd-Timer, kein Drittanbieter-Schedulingservice. Du definierst einen Job, und OpenClaw wacht auf und führt ihn pünktlich aus.

Zwei Ausführungsmodi

Hier wird es interessant. Cron-Jobs können in zwei Modi laufen:

systemEvent — Injiziert eine Nachricht in deine Hauptsession. Der Agent sieht sie wie eine Benachrichtigung und kann im Kontext reagieren. Ideal für Erinnerungen und Checks, die vom Gesprächsverlauf profitieren.

agentTurn — Spawnt eine isolierte Session. Der Agent wacht auf, erledigt den Job und geht wieder schlafen. Kein Gesprächsverlauf, keine Störung deines Hauptchats. Das willst du für autonome Workflows.

Beispiel 1: Einfache Erinnerung

{
  "name": "Daily Standup Reminder",
  "schedule": {
    "kind": "cron",
    "expr": "0 9 * * 1-5",
    "tz": "Europe/Berlin"
  },
  "payload": {
    "kind": "systemEvent",
    "text": "Erinnerung: E-Mails und Kalender für heutige Meetings prüfen."
  },
  "sessionTarget": "main"
}

Das feuert Montag bis Freitag um 9:00 Uhr Berliner Zeit. Es schiebt eine Erinnerung in deine Hauptsession, und der Agent kann dann dein Postfach und den Kalender mit seinen verfügbaren Tools prüfen.

Beispiel 2: Autonome Engagement-Pipeline

So sieht ein echter Produktions-Cron-Job aus — unser morgendliches Social-Media-Engagement:

{
  "name": "Social Media Engagement",
  "schedule": {
    "kind": "cron",
    "expr": "0 10 * * *",
    "tz": "Europe/Berlin"
  },
  "payload": {
    "kind": "agentTurn",
    "message": "Run the EU morning engagement round. Read memory/daily-intel.md for today's news. Find trending posts on X and LinkedIn. Reply to 5-8 posts with genuine, specific comments. Log results to memory/engagement-log.md.",
    "model": "anthropic/claude-opus-4-6"
  },
  "sessionTarget": "isolated",
  "delivery": {
    "mode": "announce"
  }
}

Achte auf ein paar Dinge:

• sessionTarget: "isolated" — Läuft in einer eigenen Session. Verschmutzt deinen Hauptchat nicht mit Engagement-Logs.
• model ist explizit — Wir geben das Modell an, weil sich Defaults ändern können. Du willst nicht, dass deine komplexe Pipeline plötzlich auf einem kleineren Modell läuft.
• delivery.mode: "announce" — Wenn der Job fertig ist, schickt OpenClaw eine Zusammenfassung in deine Hauptsession. Du bleibst informiert, ohne im Loop zu sein.

Cron vs. Heartbeat

OpenClaw hat auch ein Heartbeat-System — einen periodischen Poll, der prüft, ob etwas Aufmerksamkeit braucht. Wann nutzt man was?

Gelernte Lektionen

Keine Sub-Agenten aus Cron-Jobs spawnen. Wir haben versucht, unseren Engagement-Cron-Job Sub-Agenten für Parallelverarbeitung spawnen zu lassen. Die verloren den Kontext, duplizierten Arbeit und antworteten gelegentlich auf denselben Tweet zweimal. Halte Cron-Jobs eigenständig.

Immer das Modell explizit angeben. Unsere Content-Pipeline lief einmal auf einem kleineren Modell, weil wir uns auf den Default verlassen haben. Die Qualität sank merklich, und wir merkten es zwei Tage lang nicht.

Nutze memory/-Dateien für State. Cron-Jobs in isolierten Sessions sehen deinen Gesprächsverlauf nicht. Stattdessen lesen und schreiben wir in Dateien im memory/-Verzeichnis. Der Engagement-Job liest daily-intel.md und schreibt in engagement-log.md. Dateien sind die geteilte State-Schicht.

---

3. Custom MCP Tools — Gib deinem Agenten Hände

Skills geben Wissen. Cron gibt den Zeitplan. MCP-Tools geben deinem Agenten die Fähigkeit, tatsächlich Dinge zu tun in der echten Welt.

Was ist MCP?

MCP (Model Context Protocol) ist ein offener Standard zur Verbindung von KI-Modellen mit externen Tools und Datenquellen. Stell es dir als universelles Plugin-System vor: Du definierst Tools mit Name, Beschreibung und Input-Schema, und jeder MCP-kompatible Client (wie OpenClaw) kann sie entdecken und nutzen.

Warum eigene Tools bauen?

Out of the box gibt dir OpenClaw Websuche, Dateioperationen, Browser-Steuerung und mehr. Aber irgendwann brauchst du domänenspezifische Aktionen:

• In dein CMS veröffentlichen
• Gebrandete Bilder aus Templates generieren
• Deine interne Datenbank abfragen
• CI/CD-Pipelines auslösen
• Auf Social Media mit deinem Marken-Account posten

Dafür sind Custom MCP Tools da.

Architektur: Monolith vs. Microservices

Wir starteten mit der Idee separater MCP-Server für verschiedene Bereiche — einen für Blog-Management, einen für Bildgenerierung, einen für Social Media. Nach zwei Wochen haben wir alles in einen einzigen Server mit 78 Tools konsolidiert.

Warum? Praktische Gründe:

1. Weniger Verbindungen — OpenClaw verbindet sich mit einem Server, nicht zehn
2. Geteilte Authentifizierung — Ein API-Key, ein Auth-Flow
3. Geteilte Utilities — Bild-Upload, Error-Handling, Logging — alles wiederverwendbar
4. Einfacheres Deployment — Ein Vercel-Projekt, ein Set Umgebungsvariablen

Der Nachteil ist eine größere Codebase, aber für unsere Größenordnung (78 Tools) ist es sehr überschaubar.

Echtes Beispiel: Hero-Image-Generator bauen

Hier eine vereinfachte Version unseres tatsächlichen Hero-Image-Tools. Es nimmt Artikel-Metadaten, rendert ein HTML-Template mit Puppeteer und lädt den Screenshot hoch:

const generateHeroImage: Tool = {
  name: "generate_hero_image",
  description: "Generiert ein gebrandetes Hero-Image aus HTML-Templates. Akzeptiert Artikeltyp, Titel, optionale Logos und Akzentfarbe. Gibt eine URL zum hochgeladenen Bild zurück.",
  inputSchema: {
    type: "object",
    properties: {
      type: {
        type: "string",
        enum: ["product-launch", "tutorial", "comparison", "news"],
        description: "Template-Typ — bestimmt Layout und Styling"
      },
      title: {
        type: "string",
        description: "Artikeltitel für die Anzeige auf dem Bild"
      },
      logos: {
        type: "array",
        items: { type: "string" },
        description: "Logo-IDs aus der Registry (z.B. 'openclaw', 'vercel')"
      },
      accentColor: {
        type: "string",
        description: "Hex-Farbe für Brand-Theming (Default: #3B82F6)"
      }
    },
    required: ["type", "title"]
  },
  handler: async (args) => {
    // 1. HTML-Template für den gegebenen Typ laden
    const template = await loadTemplate(args.type);

    // 2. Daten injizieren — Titel, Logos, Farben
    const html = renderTemplate(template, {
      title: args.title,
      logos: await resolveLogos(args.logos || []),
      accentColor: args.accentColor || "#3B82F6"
    });

    // 3. Screenshot mit Puppeteer (1200x630 für Social Sharing)
    const screenshot = await puppeteerScreenshot(html, {
      width: 1200, height: 630
    });

    // 4. In Storage hochladen
    const url = await uploadToStorage(screenshot, "hero-images");

    // 5. Strukturierte Daten zurückgeben
    return {
      success: true,
      url: url,
      dimensions: { width: 1200, height: 630 }
    };
  }
};

Tool-Beschreibungen sind alles

Hier etwas, das nicht offensichtlich ist: Das LLM liest deine Tool-Beschreibungen, um zu entscheiden, welches Tool es aufruft. Eine vage Beschreibung wie „generiert Bilder" führt dazu, dass dein Tool aus falschen Gründen aufgerufen wird. Eine spezifische Beschreibung wie „Generiert ein gebrandetes Hero-Image aus HTML-Templates. Akzeptiert Artikeltyp, Titel, optionale Logos und Akzentfarbe." — das sorgt dafür, dass der Agent es korrekt nutzt.

Wir haben mehr Zeit mit dem Verfeinern von Tool-Beschreibungen verbracht als mit der eigentlichen Tool-Logik. Es lohnt sich.

Strukturierte Daten zurückgeben, keine Prosa

Anfangs gaben unsere Tools Nachrichten wie „Bild erfolgreich generiert unter https://..." zurück. Der Agent musste den String dann parsen, um die URL zu extrahieren. Jetzt geben wir strukturiertes JSON zurück:

{
  "success": true,
  "url": "https://storage.example.com/hero-images/abc123.png",
  "dimensions": { "width": 1200, "height": 630 }
}

Der Agent kann die URL direkt in nachfolgenden Tool-Aufrufen verwenden. Kein Parsing, keine Mehrdeutigkeit.

Testen mit mcporter

OpenClaw enthält mcporter, ein CLI-Tool zum direkten Testen von MCP-Servern:

mcporter call myserver.generate_hero_image \
  type="tutorial" \
  title="Mein Post" \
  logos='["openclaw"]' \
  accentColor="#EF4444"

Das ist unschätzbar wertvoll bei der Entwicklung. Du kannst Tools testen, ohne den vollen Agenten-Loop zu durchlaufen — schnellere Iteration, einfacheres Debugging.

---

4. Alles zusammenfügen

Hier passiert die Magie. Kein einzelnes Teil ist für sich beeindruckend. Eine Markdown-Datei? Ein Cron-Ausdruck? Ein JSON-Schema? Na und. Aber zusammengesetzt verwandeln sie deinen Agenten vom Chatbot zum autonomen Kollegen.

Unsere morgendliche Content-Pipeline

So funktioniert unsere tatsächliche Produktions-Pipeline, jeden einzelnen Morgen:

1. 06:00 — Ein Cron-Job triggert einen isolierten Agent-Turn
2. Agent liest den Content-Skill — Jetzt kennt er den kompletten Publishing-Workflow: Recherche → Schreiben → Bild → Veröffentlichen → Social
3. Sucht nach Trend-News über MCP-Research-Tools — research_topic, search_knowledge_base
4. Generiert Themenvorschläge mit SEO-Keywords von generate_keywords
5. Erstellt ein Hero-Image über unser templatebasiertes MCP-Tool
6. Sendet Vorschläge an Telegram mit Inline-Buttons — „Genehmigen", „Bearbeiten" oder „Überspringen"
7. Bei Genehmigung — Schreibt den Post in 4 Sprachen (EN, DE, FR, IT), veröffentlicht alle Versionen, generiert Social-Posts und verbreitet auf X, LinkedIn und Facebook

Die gesamte Pipeline — vom Cron-Trigger bis zum veröffentlichten, beworbenen Blog-Post — dauert etwa 8 Minuten. Ohne menschliches Eingreifen (es sei denn, wir wollen reviewen).

Das Kompositions-Muster

Denk an drei Schichten:

• Skills = Wissen („so veröffentlicht man einen Blog-Post")
• Cron = Zeitplan („mach es jeden Morgen um 6 Uhr")
• MCP-Tools = Aktionen („so erstellst du den Post, generierst das Bild, veröffentlichst im CMS")

Jede Schicht allein ist nützlich. Alle drei zusammen schaffen autonome Workflows, die tatsächlich funktionieren.

Was wir anders machen würden

Wenn wir von vorne anfangen würden:

1. Mit einem Skill, einem Cron-Job, einem MCP-Tool starten. Den Loop End-to-End zum Laufen bringen, bevor man skaliert. Wir haben 30 Tools gebaut, bevor wir die volle Pipeline getestet haben, und mussten die Hälfte umschreiben.
2. Alles in Dateien loggen. Gesprächsverläufe werden komprimiert. Dateien bleiben. Jeder Pipeline-Schritt sollte seinen Output auf die Platte schreiben.
3. Isolierte Sessions für Cron-Jobs von Anfang an nutzen. Wir starteten mit Hauptsession-Events und bereuten es schnell — der Chat wurde laut.

---

Wie geht es weiter

OpenClaw ist noch jung, und das Ökosystem wächst. ClawHub wird zu einem Community-Repository für Skills — du kannst deine teilen und andere nutzen. Die OpenClaw-Docs haben detaillierte Referenzen für alles, was hier behandelt wurde.

Wenn du die volle Produktions-Setup-Story willst — wie wir OpenClaw konfigurieren, Multi-Agenten-Workflows managen und Browser-Automatisierung handhaben — schau dir unseren Kompletten OpenClaw-Guide an.

Die Bausteine sind alle da. Skills für Wissen, Cron für Zeitplanung, MCP-Tools für Aktionen. Was wirst du bauen?

Schreib uns bei Context Studios oder finde uns auf X @_contextstudios.