Trigger.dev MCP Server

Der Trigger.dev MCP Server verbindet Ihren KI-Assistenten mit Ihren Trigger.dev-Projekten. Trigger.dev ist eine Open-Source-Plattform, auf der Sie Hintergrundaufgaben, Workflows und KI-Agenten in TypeScript schreiben und ausführen. Solche Aufgaben heißen dort Tasks; jeder einzelne Durchlauf eines Tasks heißt Run. MCP, das Model Context Protocol, ist ein offener Standard, über den Assistenten wie Claude Code, Cursor oder Codex externe Werkzeuge aufrufen. Der Server stammt von Trigger.dev selbst und ist Teil der offiziellen Kommandozeile (CLI). Der Quellcode liegt im öffentlichen Repository triggerdotdev/trigger.dev unter der Apache-2.0-Lizenz. Mit über 16.000 GitHub-Sternen gehört das Projekt zu den bekannteren Werkzeugen für langlebige Hintergrundjobs im TypeScript-Umfeld.

Wofür ist der Trigger.dev MCP Server nützlich?

Wer mit Trigger.dev arbeitet, springt im Alltag ständig zwischen Editor, Terminal und Dashboard. Ein Task schlägt fehl, Sie öffnen das Dashboard, suchen den Run, lesen die Logs und gehen zurück in den Code. Der MCP-Server holt diese Schritte in den Assistenten. Sie fragen etwa, warum der letzte Run eines Tasks fehlgeschlagen ist. Der Assistent ruft die Run-Details samt Logs ab, liest den passenden Code und schlägt eine Korrektur vor. Danach löst er den Task testweise erneut aus und wartet auf das Ergebnis. Der Mehrwert liegt also weniger in einer einzelnen Abfrage als im geschlossenen Kreislauf aus Fehler finden, beheben und prüfen, ohne den Editor zu verlassen.

Was kann der Server?

Laut offizieller Werkzeugliste deckt der Server mehrere Bereiche ab. Er durchsucht die Trigger.dev-Dokumentation, legt neue Projekte an und richtet Trigger.dev in einer bestehenden Codebasis ein. Er zeigt die registrierten Tasks samt Payload-Schemas, löst Tasks mit Optionen wie Verzögerung, Tags, Wiederholungen oder Maschinengröße aus und listet Runs gefiltert nach Status, Task oder Zeitraum. Laufende Runs lassen sich abbrechen oder mit geänderten Werten neu starten. Dazu kommen Deployments auf Staging oder Production, die Liste der Preview-Branches und das Starten und Stoppen des lokalen Dev-Servers. Über TRQL, die Abfragesprache von Trigger.dev, wertet der Assistent Run-, Metrik- und LLM-Nutzungsdaten aus, liest Dashboards und erstellt eigene. Ein Health-Report liefert eine Einschätzung mit empfohlener nächster Aktion. Neuere Werkzeuge betreffen Chat-Agenten, Realtime-Kanäle von Sessions und eingehende Webhooks, deren Zustellungen der Assistent prüfen und erneut auslösen kann.

Lesemodus und Dev-only-Modus

Ein Assistent, der deployen und Runs abbrechen darf, kann auch Schaden anrichten. Trigger.dev bietet deshalb zwei Schutzschalter. Mit der Option --readonly blendet der Server alle schreibenden Werkzeuge aus, darunter deploy, trigger_task, cancel_run, replay_run sowie das Bearbeiten von Dashboards und Webhook-Secrets. Der Assistent kann dann nur noch lesen und analysieren. Mit --dev-only bleibt er auf die Entwicklungsumgebung beschränkt; Deployments und Preview-Branches verschwinden aus der Werkzeugliste. Für den Einstieg in einem Team empfiehlt sich der Lesemodus.

Installation und Anmeldung

Am schnellsten geht es laut Dokumentation mit dem interaktiven Installer npx trigger.dev@latest install-mcp. Er erkennt installierte Clients und trägt den Server ein. Unterstützt werden unter anderem Claude Code, Cursor, Windsurf, VS Code, Zed, Cline, Gemini CLI, Codex CLI und opencode. Der Server läuft lokal über npx. Die Dokumentationssuche und einige lokale Werkzeuge funktionieren ohne Anmeldung. Alles andere setzt eine Anmeldung über die Trigger.dev CLI voraus, zu der der Client beim ersten Aufruf auffordert. Mehrere CLI-Profile, etwa für Cloud und eigene Instanz, lassen sich im laufenden Betrieb wechseln.

Kosten

Der MCP-Server selbst ist kostenlos und Open Source. Für die Werkzeuge rund um Runs und Deployments brauchen Sie ein Trigger.dev-Konto oder eine selbst gehostete Instanz. Laut Preisseite gibt es einen kostenlosen Plan ohne Kreditkarte mit monatlichem Nutzungsguthaben sowie kostenpflichtige Hobby-, Pro- und Enterprise-Pläne. Abgerechnet wird nutzungsbasiert nach Rechenzeit und Anzahl der Runs. Aktuelle Konditionen nennt die offizielle Preisseite.

Für wen lohnt sich der Trigger.dev MCP Server?

Er lohnt sich für Teams, die Trigger.dev bereits für Hintergrundjobs, Cron-Aufgaben oder KI-Agenten einsetzen und Fehler schneller finden wollen. Auch beim Einstieg hilft er, weil der Assistent ein Projekt selbst einrichten und die Dokumentation gezielt durchsuchen kann. Wer nur gelegentlich einen Run nachsieht, kommt mit dem Dashboard ebenso gut zurecht.

Node.js mit npx, ein Trigger.dev-Konto (kostenloser Plan genügt für den Einstieg) oder eine selbst gehostete Instanz und ein MCP-Client wie Claude Code, Cursor oder Codex CLI.

Mit dem Trigger.dev MCP Server liest ein KI-Assistent Ihre Tasks und Runs, löst Tasks aus und hilft beim Debuggen. Dieser Ratgeber führt von der Installation bis zum ersten untersuchten Run.

Schritt 1: Voraussetzungen

Sie brauchen Node.js mit npx, einen MCP-Client wie Claude Code, Cursor oder Codex CLI und ein Trigger.dev-Konto. Für den Einstieg genügt laut Preisseite der kostenlose Plan. Wer Trigger.dev selbst hostet, kann den Server ebenso nutzen und trägt die eigene API-Adresse ein.

Schritt 2: Installation per Installer

Führen Sie im Projektordner npx trigger.dev@latest install-mcp aus. Der Installer erkennt installierte Clients und fragt, wo der Server eingetragen werden soll. Für Claude Code allein genügt npx trigger.dev@latest install-mcp --client claude-code. Mit --scope project landet die Konfiguration in der Datei .mcp.json des Projekts und gilt damit für das ganze Team.

npx trigger.dev@latest install-mcp
npx trigger.dev@latest install-mcp --client claude-code

Schritt 3: Manuelle Konfiguration

Alternativ tragen Sie den Server selbst ein. In Claude Code steht er in ~/.claude.json oder in .mcp.json mit dem Befehl npx und den Argumenten trigger.dev@latest und mcp. VS Code erwartet den Schlüssel servers statt mcpServers. In Codex CLI empfiehlt die Dokumentation ein Start-Timeout von 30 Sekunden, weil npx beim ersten Start das Paket lädt.

Schritt 4: Sicher starten mit Lesemodus

Hängen Sie in der manuellen Konfiguration --readonly an die Argumente an. Dann fehlen alle schreibenden Werkzeuge wie deploy, trigger_task und cancel_run, und der Assistent kann nur lesen. Wer Tasks auslösen, aber nichts deployen lassen will, nutzt stattdessen --dev-only. Das beschränkt den Server auf die Entwicklungsumgebung.

Schritt 5: Anmelden

Die Dokumentationssuche funktioniert sofort. Für alles andere fordert der Client beim ersten Aufruf zur Anmeldung über die Trigger.dev CLI auf. Mit dem Werkzeug whoami prüfen Sie, welches Konto und welches Profil aktiv sind. Mehrere Profile, etwa Cloud und eigene Instanz, wechseln Sie über switch_profile.

Schritt 6: Erster Praxistest

Bitten Sie den Assistenten etwa: Zeige mir die fehlgeschlagenen Runs der letzten 24 Stunden und erkläre die Ursache. Er listet die Runs, öffnet die Details mit Logs und verknüpft sie mit Ihrem Code. Nach einer Korrektur kann er den lokalen Dev-Server starten, den Task in der Entwicklungsumgebung erneut auslösen und auf das Ergebnis warten. Prüfen Sie vorgeschlagene Änderungen wie jede andere Codeänderung.

Anmeldung über die Trigger.dev CLI (CLI-Profil), beim ersten Aufruf vom Client angestoßen. Dokumentationssuche und lokale Dev-Server-Werkzeuge funktionieren ohne Anmeldung.

Projekte und Organisationen lesen und anlegen, Tasks auslösen, Runs lesen, abbrechen und neu starten, auf Staging/Production deployen, TRQL-Abfragen und Dashboards, Chat-Agenten, Session-Kanäle und Webhook-Zustellungen. Mit --readonly nur lesend, mit --dev-only nur Entwicklungsumgebung.

Der Server läuft lokal und spricht mit der Trigger.dev-API (Cloud oder eigene Instanz). Abgerufene Run-Logs, Payloads und Abfrageergebnisse gelangen in den Kontext des KI-Clients und damit zum Modellanbieter.

Ohne --readonly kann der Assistent Tasks mit echten Payloads auslösen, Runs abbrechen, auf Production deployen und Webhook-Secrets neu setzen. Run-Logs und Payloads können personenbezogene Daten oder Zugangsdaten enthalten.