Zuuna für KI-Agenten: Agent baut, Git-Regeln bewegen die Karte

Dein Coding-Agent arbeitet ohnehin im Repo. Ab jetzt sieht er auch das Board: Der Zuuna-MCP-Server gibt ihm Karten, Spalten und Kommentare, und Zuunas Git-Integration hält den Board-Stand an der Wirklichkeit fest statt an der letzten manuellen Aktualisierung. Der ganze Kreislauf ist in vier Schritten durch:

Der Kreislauf in vier Schritten

1. Der Agent liest das Board. Über den MCP-Server sieht er das Board, wie es ist: Spalten in Reihenfolge, Karten mit Schlüssel wie ZNA-2001, Priorität, Typ. Du nennst die Karte, oder du lässt ihn selbst wählen.
2. Der Agent baut im Repo. Claude Code, Cursor oder Codex schreiben den Code, mit ihren eigenen Werkzeugen, in deinem Repository. Der Karten-Schlüssel wandert in den Commit.
3. Der Pull Request merged. Review läuft wie immer, über deine Tools und deine Regeln. Nichts daran wird automatisiert.
4. Git verknüpft die Karte. Commits, PRs und Releases landen ohne eine einzige manuelle Board-Aktualisierung auf der Karte; Releases und Deploy-Gates kippen, wenn dein Git-Tag und deine Pipeline es belegen. In die nächste Spalte wandert die Karte erst durch eine Automatisierungsregel auf deinem Board, etwa „Pull Request gemerged → Review“. Vorinstalliert ist keine, du legst sie einmal pro Board an.

Kein „Ist die Karte schon gezogen?“ im Standup. Das Board ist hier nicht die Erinnerung daran, was jemand hätte eintragen sollen, sondern der Beleg dafür, was im Repo passiert ist. Wie Commits und Karten verknüpft werden, zeigt das Tutorial Commits automatisch mit Karten verknüpfen; wie Regeln Karten anhand von Git-Ereignissen bewegen, Karten automatisch durch Git bewegen.

Die MCP-Werkzeuge: gehostet oder lokal

Der einfachste Weg ist der gehostete Connector unter app.zuuna.de/mcp: Claude, ChatGPT und jeder andere MCP-fähige Client fügt Zuuna direkt per URL hinzu, ganz ohne lokale Installation. Die Anmeldung läuft über OAuth 2.1: Du meldest dich einmal mit deinem Zuuna-Konto an und wählst auf der Zustimmungsseite Workspace und Rechte. Der Connector steht im Developer-Tarif zur Verfügung.

Für einen lokalen Prozess, etwa einen CI-Runner, einen abgeschotteten Agenten oder einen Workflow, der lieber einen einfachen Bearer-Token statt einer OAuth-Anmeldung will, gibt es denselben Werkzeugsatz als npm-Paket: mcp-server-zuuna. Beide Wege sprechen dieselbe Zuuna-v1-API und sind bewusst Board-Ein-und-Ausgabe: kein Deploy-Werkzeug, kein Git-Schreibzugriff. Die Git- und Deployment-Werkzeuge tragen nur Commits, CI-Checks und Deploy-Status auf die Karte ein: Sie pushen nichts und lösen keinen Deploy aus.

73 Werkzeuge in 15 Kategorien:

Kategorie	Werkzeuge	Beispiel
Identität	1	zuuna_me: Token-Identität, Organisation, Plan, Scopes
Gruppen, Mitglieder, Epics	6	Gruppen und ihre Mitglieder auflisten, Epics anlegen, bearbeiten und auflisten, Karten einer Gruppe
Boards, Spalten, Automationen	7	Board und Spalten anlegen und auflisten, die eigenen Felder eines Boards lesen, Automationsregeln lesen (nur lesend)
Karten	12	Im ganzen Workspace suchen, anlegen (auch bis zu 50 auf einmal), bearbeiten, verschieben, archivieren, löschen, wiederherstellen
Kommentare	2	Lesen und kommentieren
Checklisten	4	Einträge lesen, anlegen, bearbeiten, löschen
Verknüpfungen	3	Karten als blockiert, abhängig oder Subtask verknüpfen
Anhänge	4	Hochladen, auflisten, Metadaten lesen, löschen; den Dateiinhalt liest kein Werkzeug
Zeiterfassung	8	Zeit buchen, Timer starten und stoppen, Einträge lesen und bearbeiten
Sprints	6	Anlegen, Karten zuordnen und entfernen, bearbeiten
Wiederkehrende Karten	4	Regeln anlegen, bearbeiten, löschen
Releases	5	Anlegen, bearbeiten, löschen
Deployments	2	Deploy-Status auf die Karte melden
Webhooks	6	Endpunkte anlegen, testen, Zustellungen einsehen
Git	3	Commits, CI-Checks und Branches an die Karte melden

Zwei Details, die in der Praxis zählen: Eine harte WIP-Grenze bleibt auch für Agenten eine harte WIP-Grenze (der Fehler kommt als Tool-Fehler mit der API-Antwort zurück), und 4xx-Antworten werden nie still wiederholt.

Wie der Agent das Board selbst führt, statt nur Karten abzuarbeiten, zeigt Kanban-Board für KI-Agenten; wie Claude Code ein App-Projekt über viele Sitzungen hinweg im Blick behält, Claude Code Projektmanagement.

Einrichtung: Claude Code, Cursor, Codex

Zwei Zutaten: ein API-Token aus deinem Zuuna-Workspace und der Server selbst. Dem Token gibst du genau die Scopes, die der Agent haben soll. Ein stiller Beobachter kommt mit boards:read und cards:read aus; für den vollen Kreislauf kommen cards:write und comments:write dazu. Wie du den Token anlegst, zeigt API-Token erstellen und erste Abfrage.

Stand heute: Der Server ist als mcp-server-zuuna in Version 0.3.0 auf npm: öffentlich installierbar, getestet (CI mit ESLint, TypeScript-Build und vitest), MIT-lizenziert. Paket und Quellcode-Repository sind öffentlich. Der Normalweg ist eine Zeile über npx:

Konfiguriert wird er per Umgebungsvariablen: ZUUNA_API_TOKEN (Pflicht), ZUUNA_BASE_URL (Voreinstellung https://app.zuuna.de) und optional ZUUNA_TIMEOUT_MS (Voreinstellung 15000). Node.js ab Version 20.

Claude Code:

claude mcp add zuuna \
  -e ZUUNA_API_TOKEN=zk_live_dein_token \
  -- npx -y mcp-server-zuuna

Cursor (in ~/.cursor/mcp.json oder .cursor/mcp.json im Projekt):

{
  "mcpServers": {
    "zuuna": {
      "command": "npx",
      "args": ["-y", "mcp-server-zuuna"],
      "env": { "ZUUNA_API_TOKEN": "zk_live_dein_token" }
    }
  }
}

Codex (in ~/.codex/config.toml):

[mcp_servers.zuuna]
command = "npx"
args = ["-y", "mcp-server-zuuna"]
env = { "ZUUNA_API_TOKEN" = "zk_live_dein_token" }

Aus dem Quellcode (Alternative): Wer bauen will statt npx:

git clone https://github.com/kenzotp/mcp-server-zuuna && cd mcp-server-zuuna && npm install && npm run build

…und in allen drei Konfigurationen oben ersetzt du npx -y mcp-server-zuuna durch node /pfad/zu/mcp-server-zuuna/dist/index.js.

Wie sich das vergleicht

Linear stellt Agenten als Teammitglieder ein: Der Agent nimmt ein Issue und arbeitet im Repository. Das Board zeigt danach, was der Agent über seine Arbeit berichtet hat. Zuuna dreht das um: Das Board speichert keinen Statusbericht, es liest das Repository. Eine Karte bewegt sich, wenn ein Commit landet, ein Pull Request merged, ein Release-Tag existiert oder deine Pipeline zurückmeldet. Das Board kann keinen Fortschritt behaupten, den das Repository nicht zeigt.

Atlassians Rovo bringt KI-Suche, Chat und Agenten in den Atlassian-Stack. Das Work-Item bleibt die Akte, aktualisiert per Konvention; Jira kennt kein Board, dessen Zustand sich aus dem Repository ableitet. Genau diese Lücke schließt ein Git-abgeleitetes Board: Die Arbeit der Agenten braucht keine separate Buchhaltungsebene, denn der Merge ist der Moment der Wahrheit.

Ehrlich: was Zuuna für Agenten nicht tut

• Zuuna schreibt keinen Code. Die Agenten bauen: Claude Code, Cursor, Codex. Zuuna stellt die Schnittstelle bereit und die überprüfbare Board-Wahrheit. Mehr nicht.
• Zuuna entscheidet nichts. Es gibt keine eingebaute Projektverwaltungs-KI, die Aufgaben plant, priorisiert oder abschließt. Das Board spiegelt das Repo wider; Agenten und Menschen erledigen den Rest.
• Zuuna deployt nicht. Der MCP-Server ist absichtlich ohne Deploy- und Git-Schreib-Werkzeuge. Deploys laufen über deine Pipeline; die Gates auf dem Board kippen erst, wenn dein Prozess es belegt.

Selbst sehen

Wir zeigen dir den Kreislauf gern an deinem eigenen Board statt an einer aufgenommenen Demo: Kontakt aufnehmen. Wer zuerst in Ruhe lesen will: Projektmanagement für Entwickler und Git auf dem Board.