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 acht MCP-Werkzeuge

Der Server mcp-server-zuuna spricht die Zuuna-v1-API und ist bewusst Board-Ein-und-Ausgabe: kein Deploy-Werkzeug, kein Git-Schreibzugriff.

Werkzeug	Was es tut
zuuna_me	Token-Identität: Organisation, Plan, Scopes
zuuna_boards	Boards auflisten
zuuna_board	Ein Board komplett: Spalten in Reihenfolge, dazu alle Karten
zuuna_card	Kartendetail per Schlüssel (ZNA-2001) oder ID
zuuna_create_card	Karte anlegen, Spalte per ID oder Titel
zuuna_update_card	Titel, Beschreibung und Priorität bearbeiten
zuuna_move_card	Karte in eine andere Spalte verschieben
zuuna_comment	Karte kommentieren

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.1.2 auf npm: öffentlich installierbar, getestet (CI mit ESLint, TypeScript-Build und vitest), MIT-lizenziert. Das Paket ist öffentlich, das Quellcode-Repository dahinter ist privat. 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: Das Repository ist privat, du brauchst also Zugang. Danach gilt:

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.

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.