Claude + MCP + Routines: Toolzugriff, Ausführung, Orchestrierung

Wer Entwicklungsworkflows automatisieren will, hatte bisher zwei Optionen: ein Skript schreiben oder ein Workflow-Tool wie n8n aufsetzen. Skripte können kein kontextabhängiges Urteil fällen. Workflow-Tools können nicht interpretieren. Beide setzen voraus, dass man den Ablauf vollständig kennt, bevor man ihn baut.

Mit MCP, Routines und OpenClaw entsteht eine dritte Option: Claude als aktiver Teilnehmer in Entwicklungsprozessen — mit Zugriff auf echte Tools, wiederholbaren Abläufen und der Fähigkeit, Kontext zu bewerten. Das klingt nach Feature-Marketing. Die Frage ist, wann es tatsächlich trägt — und wann nicht.

Was dabei wegfällt: Glue-Code, der verschiedene APIs verbindet und wartbar gehalten werden muss. Und das Vorab-Durchdenken von Workflows, bevor man überhaupt weiß, ob sie so funktionieren. Stattdessen: Ablauf grob beschreiben, laufen lassen, iterativ schärfen — das System nimmt Form an, während es läuft.

MCP: einen Server anbinden, was das bedeutet

Das Model Context Protocol definiert, wie Claude mit externen Tools, APIs und Datenquellen kommuniziert. Der Unterbau ist eine .mcp.json-Datei im Projektverzeichnis — oder die globale Konfiguration in Claude Desktop. Ein typischer Einstieg mit GitHub und Linear sieht so aus:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "<token>"
      }
    },
    "linear": {
      "command": "npx",
      "args": ["-y", "mcp-linear"],
      "env": {
        "LINEAR_API_KEY": "<key>"
      }
    }
  }
}

Sobald die Server laufen, kann Claude direkt auf Repositories und Issues zugreifen. Konkret heißt das: Claude kann Pull Requests auflisten, Diff-Inhalte lesen, Kommentare schreiben, Issues erstellen oder Status ändern — ohne dass man das explizit implementiert. Der MCP-Server übernimmt die Übersetzung zwischen Claudes Anfragen und der jeweiligen API.

Was sich in der Praxis sofort zeigt: Claude fragt gezielt nach, wenn Informationen fehlen. Wer „zeig mir alle offenen PRs” eingibt, bekommt eine strukturierte Liste. Wer „welche Issues wurden heute zugewiesen und haben keinen Kommentar?” fragt, bekommt eine gefilterte Auswertung — solange der MCP-Server diese Filter unterstützt.

Ein wichtiger Punkt zur Architektur: MCP-Server selbst sind zustandslos. Sie nehmen eine Anfrage entgegen, sprechen die externe API an und geben das Ergebnis zurück. Den Zustand — was bisher passiert ist, was noch aussteht, welche Entscheidung warum getroffen wurde — hält Claude in der Session. Das bedeutet auch: Fällt die Session weg, ist der Kontext weg.

Bewährte MCP-Server: ein Überblick

Die offizielle Registry unter registry.modelcontextprotocol.io listet tausende Server. Für den Einstieg sind diese besonders relevant:

Entwicklung

• @modelcontextprotocol/server-github — Repositories, PRs, Issues, Code-Review
• @modelcontextprotocol/server-filesystem — Lokale Dateien lesen und schreiben
• mcp-server-git (via uvx) — Git-History, Commits, Diffs
• @playwright/mcp — Browser-Automatisierung und E2E-Tests
• getsentry/sentry-mcp — Error-Events, Stack Traces, Issue-Verknüpfung

Projektmanagement & Kommunikation

• Linear — Offiziell via claude mcp add --transport http linear-server https://mcp.linear.app/mcp
• makenotion/notion-mcp-server — Notion-Seiten und Datenbanken lesen und schreiben
• Slack — Kanal-Nachrichten, Automationen (offiziell und Community)
• Jira — Issues und Projektdaten (offiziell)

Daten

• @modelcontextprotocol/server-postgres — PostgreSQL-Abfragen (read-only)
• @modelcontextprotocol/server-fetch — Webinhalte abrufen und als Markdown zurückgeben
• @modelcontextprotocol/server-memory — Persistenter Wissensgraph über Sessions hinweg

Mehrere Server können gleichzeitig aktiv sein. Die .mcp.json listet alle Server, die Claude für eine Session zur Verfügung stehen sollen.

Für wen lohnt sich das?

Nicht jeder Setup-Aufwand zahlt sich sofort aus. Eine grobe Einordnung:

Gut geeignet — Solo-Entwickler und kleine Teams, die wiederkehrende Aufgaben haben, die bisher manuell oder gar nicht erledigt wurden. Dependency-Audits, Dokumentationschecks, Bug-Vorsortierung. Der Aufwand für eine Routine ist in vielen Fällen vergleichbar mit dem, was man bisher einmalig manuell getan hat.

Sinnvoll mit Vorbedingung — Teams mit mehreren bestehenden Automatisierungen, die koordiniert werden müssen. Hier wird OpenClaw relevant — aber erst, wenn die einzelnen Routines funktionieren.

Eher nicht geeignet — Businesskritische Prozesse, die Audit-Trails, präzise Fehlerbehandlung und maximale Zuverlässigkeit erfordern. Dafür ist n8n oder Make nach wie vor die bessere Wahl. Auch nicht geeignet für hochfrequente Events: bei hundert Webhook-Triggern pro Stunde wird die API-Kostenfrage schnell relevant.

Routines: von der Idee zur laufenden Automation

Claude Code Routines, seit dem 14. April 2026 verfügbar, gehen einen entscheidenden Schritt weiter. Sie verwandeln einmalige Abfragen in definierte, wiederholbare Abläufe mit eigenem Trigger-Mechanismus.

Eine Routine besteht aus drei Teilen: dem Auslöser (Zeitplan, Webhook oder API-Call), den verfügbaren Tools (welche MCP-Server stehen zur Verfügung) und der Instruktion — dem Prompt, der beschreibt, was Claude tun soll.

name: daily-ticket-triage
trigger:
  schedule: "0 8 * * 1-5"   # Mo–Fr um 8 Uhr
tools:
  - linear
  - github
instruction: |
  Hole alle Issues aus Linear, die in den letzten 24 Stunden
  geöffnet oder aktualisiert wurden.
  Bewerte jeden Issue nach:
  - Severity-Label (critical / high / medium / low)
  - Ob ein Assignee gesetzt ist
  - Ob es einen verknüpften GitHub-PR gibt
  Erstelle einen kommentierten Tagesplan als Markdown-Liste
  und schreibe ihn als Kommentar in das Daily-Issue #DAILY.

Der entscheidende Unterschied zu einem Scheduled Prompt: Routines sind sessionbasiert. Sie behalten den Kontext über mehrere Tool-Aufrufe hinweg. Claude kann also zuerst Issues abrufen, dann zu jedem Issue den verknüpften PR lesen, dann prüfen, ob ein Review aussteht — alles in einem zusammenhängenden Ablauf, nicht als isolierte Einzelanfragen.

Was dabei nicht vergessen werden sollte: Die Instruktion ist ein Prompt, kein Code. Das Ergebnis ist probabilistisch, kein deterministischer Output. Zwei identische Läufe können unterschiedlich reagieren — nicht weil etwas schiefläuft, sondern weil das Modell interpretiert, nicht ausführt. Wer das nicht in Kauf nehmen kann, braucht ein anderes System.

Drei Szenarien, konkret durchgespielt

Bug-Triage per Webhook

Das Setup: Ein Sentry-Webhook triggert die Routine, wenn ein neues Error-Event eintrifft.

name: sentry-bug-triage
trigger:
  webhook: /hooks/sentry-new-error
tools:
  - github
  - linear
instruction: |
  Du erhältst einen Sentry-Error-Event als JSON.
  1. Lies den Stack Trace und identifiziere die betroffene Datei und Zeile.
  2. Suche im GitHub-Repository nach ähnlichen Fehlern in der Git-History
     (git log --grep mit Fehlermeldung, max. 10 Commits).
  3. Prüfe, ob im Linear-Board ein offener Issue mit ähnlichem Titel existiert.
  4. Falls ja: Füge den Stack Trace als Kommentar hinzu.
  5. Falls nein: Erstelle einen neuen Issue mit Titel, Stack Trace,
     betroffener Datei und Link zum Sentry-Event.

Was passiert in der Praxis: Der Webhook sendet den Event-Payload an Claude Code. Claude parst den Stack Trace, extrahiert den Fehlerort und sucht in der Git-History nach NameError: name 'user_id' is not defined oder ähnlichen Treffern. Findet es einen Match, verknüpft es den neuen Event mit dem bestehenden Issue. Findet es keinen, öffnet es einen neuen Issue mit allen relevanten Daten vorausgefüllt.

Das ersetzt nicht den Entwickler. Es ersetzt die manuelle Arbeit, die jemand erledigt, bevor der Entwickler überhaupt anfängt.

Dokumentationsprüfung nach Merge

name: doc-drift-check
trigger:
  webhook: /hooks/github-merge
  filter: "ref == 'refs/heads/main'"
tools:
  - github
instruction: |
  Ein neuer Commit wurde auf main gemergt.
  1. Lies die geänderten Dateien aus dem Commit-Diff.
  2. Für jede geänderte .ts oder .py Datei: prüfe, ob eine
     korrespondierende Datei in /docs existiert.
  3. Falls ja: Vergleiche Funktionssignaturen und Parameter
     mit der Dokumentation.
  4. Falls Abweichungen existieren: Öffne einen GitHub-Issue
     mit Titel "Doc drift: [Dateiname]" und liste die Abweichungen auf.
  5. Falls keine Abweichung: Keine Aktion.

Der Mehrwert hier: Dokumentations-Drift ist ein bekanntes Problem, das manuell kaum kontrollierbar ist. Die Routine läuft nach jedem Merge automatisch — und eröffnet nur dann einen Issue, wenn tatsächlich etwas auseinanderläuft.

Wöchentliche Dependency-Analyse

name: weekly-dep-audit
trigger:
  schedule: "0 9 * * 1"   # Montags um 9 Uhr
tools:
  - github
instruction: |
  Lies package.json und package-lock.json aus dem Repository.
  Identifiziere:
  - Packages, die seit mehr als 6 Monaten nicht aktualisiert wurden
  - Packages mit bekannten CVEs (prüfe anhand des npm audit-Outputs
    in der letzten CI-Run-Log-Datei unter /logs/audit.json)
  - Direkte Abhängigkeiten, für die ein Major-Update verfügbar ist
  Erstelle einen wöchentlichen Issue "Dependency Audit KW[X]" mit
  einer priorisierten Liste der Handlungsempfehlungen.

Das ist ein typischer Fall für Routines: Die Aufgabe ist zu kleinteilig für einen dedizierten Prozess, zu zeitaufwändig für manuelle Ausführung und inhaltlich komplex genug, dass ein simples Skript nicht reicht.

Typische Failure Modes

Bevor ein Setup produktiv geht, lohnt es sich, diese vier Fehlermuster zu kennen:

Silent Failure. Die Routine läuft durch, ohne Fehler zu werfen — aber tut nicht das, was gewünscht war. Claude hat die Instruktion interpretiert und eine plausible Variante geliefert. Ohne explizite Ausgabe oder Logging ist das schwer zu erkennen.

Tool Drift. Ein MCP-Server ändert seine verfügbaren Operationen, ändert Feldnamen oder bekommt neue Rate Limits. Die Routine funktionierte gestern — heute liefert sie Teilergebnisse oder schlägt still fehl. Versionskontrolle auf Server-Ebene existiert meist nicht.

Overreach. Die Instruktion war zu offen formuliert. Claude hat auf Ressourcen zugegriffen oder Aktionen ausgelöst, die technisch verfügbar, inhaltlich aber nicht erwünscht waren. Minimal-Permissions und explizite Scope-Grenzen in der Instruktion sind keine Option, sondern Pflicht.

Context Loss. Bei langen Routines mit vielen Tool-Calls kann der Kontext aus frühen Schritten am Ende des Ablaufs wegfallen oder an Gewicht verlieren. Die Routine „vergisst” eine Bedingung, die am Anfang gesetzt wurde. Dagegen hilft: Schlüsselinformationen explizit in der Instruktion wiederholen oder als Zwischenzustand in ein Dokument schreiben lassen.

OpenClaw: wann ein Agent-Layer sinnvoll wird

Einzelne Routines decken gut definierte, abgeschlossene Aufgaben ab. Sobald Aufgaben aber kontextabhängig werden — „führe Bug-Triage durch, aber nur wenn der Fehler production-kritisch ist, und eskaliere zu einem On-Call, wenn kein Assignee verfügbar ist” — stoßen einzelne Routines an ihre Grenzen.

OpenClaw funktioniert als Agent-Layer über Claude Code. Es verwaltet eine Bibliothek von Skills und Routines und entscheidet kontextbasiert, welche davon relevant ist. In der Praxis bedeutet das: OpenClaw erhält einen Eingangs-Event oder eine Anfrage, bewertet den Kontext und ruft die passende Routine auf — oder eine Sequenz davon.

Das verändert die Fragestellung grundlegend. Statt „welchen Webhook triggert welche Routine?” lautet sie: „Was soll das System tun, wenn X passiert?” — und der Agent entscheidet, wie.

Ein konkretes Muster:

Eingang: Sentry-Event (production, severity: fatal)
→ OpenClaw evaluiert: Ist ein On-Call definiert? → ja
→ OpenClaw ruft auf: sentry-bug-triage
→ OpenClaw evaluiert: Hat die Routine einen Issue erstellt? → ja
→ OpenClaw ruft auf: escalate-to-oncall (mit Issue-Link)
→ OpenClaw wartet 30 min
→ OpenClaw evaluiert: Wurde der Issue assigned? → nein
→ OpenClaw ruft auf: escalate-to-lead

Das ist kein Trigger-Workflow mehr. Es ist ein Agent, der Entscheidungen trifft.

Eine Einschränkung, die früh klar sein sollte: OpenClaw wird zum Overkill, solange einzelne Routines noch nicht stabil laufen. Wer einen Agent-Layer über Routines legt, die selbst inkonsistent sind, multipliziert das Problem — er macht es nicht kleiner. Erst wenn einzelne Routines zuverlässig und vorhersagbar laufen, macht die Koordinationsschicht Sinn.

Wo Grenzen sichtbar werden

Sprache ist nicht präzise. Eine Routine, die „meine Inbox priorisiert”, liefert ein anderes Ergebnis als eine, die „alle Mails von Absendern aus dem CRM mit offenem Support-Ticket, eingegangen in den letzten 48 Stunden, absteigend nach letzter Kundenaktivität” sortiert. Die Einstiegshürde sinkt — aber Qualität hängt weiterhin an Spezifikationsqualität.

Debugging ist schwerer als bei visuellen Workflows. Bei n8n sieht man jeden Schritt als Node, jede Ausführung als Log. Bei einer sessionbasierten Routine ist der Fehlerfall schwerer zu lokalisieren: An welchem Schritt hat Claude eine falsche Annahme getroffen? Warum wurde der dritte Tool-Call nicht ausgelöst? Die Observability von Routine-Abläufen ist noch keine gelöste Aufgabe.

Lock-in ist real. Wer Automatisierungslogik in Claude-nativen Routines aufbaut, ist an Anthropics Infrastruktur, Preismodell und Plattformentscheidungen gebunden. Das ist keine Ablehnung des Ansatzes — aber eine Frage, die vor dem Aufbau beantwortet sein sollte.

Security braucht expliziten Scope. Ein Agent, der eigenständig auf Repositories, Ticketsysteme und externe APIs zugreift und Issues schreibt oder schließt, ist eine andere Risikooberfläche als ein Chatbot. Write-Permissions sollten minimal gehalten werden. Logs sollten auditierbar sein.

n8n und Make: nicht erledigt, aber anders positioniert

Wer kritische Geschäftsprozesse mit Fehlerbehandlung, Retry-Logik und präziser Connector-Kontrolle abbilden muss, ist mit n8n oder Make besser bedient. Diese Tools sind auditierbar, haben breitere Integrationen und sind für Präzision bei definierten Abläufen gebaut.

Die sinnvolle Arbeitsteilung: n8n für alles, was klar beschreibbar und businesskritisch ist. Claude-Routines für alles, was Interpretation, Kontext oder natürlichsprachliche Komplexität erfordert — oder für Aufgaben, die zu kleinteilig oder zu selten sind, um eine dedizierte Integration zu rechtfertigen.

Claude ist kein Ersatz für Workflow-Engines. Es ist eine neue Schicht für die Fälle, die bisher keinen sauberen Platz hatten: zu komplex für ein Skript, zu variabel für einen festen Workflow, zu selten für eine eigene Integration.

Situation	Empfehlung
Einzelne kontextbezogene Abfrage	MCP direkt in Claude
Wiederkehrender, klar definierter Ablauf	Routine
Mehrere Routines, die koordiniert werden müssen	OpenClaw
Kritischer Prozess mit Retry und Audit-Trail	n8n oder Make
Hochfrequente Events (100+/h)	n8n/Make wegen Kosten
Ad-hoc-Automation ohne feste Trigger	Claude Code manuell
Exploratives Problem ohne klaren Ablauf	Claude + MCP (ohne Routine)

Neue Rolle des Entwicklers

Was ändert sich für jemanden, der mit diesen Systemen arbeitet? Die eigentliche Aufgabe verschiebt sich: weniger Implementierung, mehr Spezifikation. Statt Code zu schreiben, der einen Ablauf beschreibt, beschreibt man den Ablauf in natürlicher Sprache — mit allen Unschärfen, die das mitbringt.

Das klingt einfacher. Es ist anders. Eine gute Routine-Instruktion erfordert dasselbe Denken wie eine gute Anforderungsspezifikation: Was genau soll passieren? Unter welchen Bedingungen nicht? Was ist ein Erfolgsfall, was ein Fehlerfall? Wer diese Fragen bisher im Code beantwortet hat, muss sie jetzt im Prompt beantworten — und dabei akzeptieren, dass das Ergebnis nicht deterministisch ist.

Die Debugging-Kompetenz verlagert sich von Stack Traces zu Verhaltensmustern: Warum hat das System in dieser Situation anders reagiert als erwartet? Was in der Instruktion war zu vage? Welcher Kontext hat gefehlt? Das ist keine einfachere Aufgabe — es ist eine andere.

Einordnung

MCP, Routines und OpenClaw zusammen sind kein Endprodukt, sondern eine frühe Version einer Infrastruktur, die gerade entsteht. Wer damit anfangen will, sollte schrittweise vorgehen: erst MCP anbinden und mit direkten Abfragen Erfahrung sammeln, dann eine einfache Routine definieren, OpenClaw erst dann, wenn mehrere Routines koordiniert werden müssen. Den Agent-Layer vor den Routines zu bauen ist wie ein Dirigent ohne Orchester.

Der echte Wert liegt nicht in einzelnen Fähigkeiten, sondern darin, dass Automatisierungen für Aufgaben entstehen können, für die bisher keine saubere Lösung existierte: zu komplex für ein Skript, zu variabel für n8n, zu selten für eine eigene Integration. Genau dort ist Claude stark — und genau dort bleiben auch die größten offenen Fragen: Observability, Kosten bei Skalierung, Verlässlichkeit unter Last.

Man automatisiert nicht mehr Prozesse. Man automatisiert Entscheidungen.