glab CLI: Strukturierter GitLab-Zugriff für KI-Agenten

Wenn Teams GitLab Duo, Claude, Cursor und andere KI-Assistenten einsetzen, läuft ein wachsender Teil des Entwicklungs-Workflows über einen KI-Agenten, der im eigenen Auftrag handelt – Issues liest, Merge Requests prüft, Pipelines ausführt und dabei hilft, schneller zu liefern. Die meisten Entwickler(innen) nutzen glab bereits vom Terminal aus, um mit GitLab zu interagieren. Beides zu kombinieren ist der naheliegende nächste Schritt.

Das Problem: Ohne die richtigen Werkzeuge rät ein KI-Agent im Wesentlichen, wenn es um GitLab-Projekte geht. Er könnte die Details eines Issues halluzinieren, den er nie gesehen hat, einen Merge Request auf Basis veralteter Trainingsdaten zusammenfassen statt anhand seines tatsächlichen Zustands – oder verlangen, dass Kontext manuell aus einem Browser-Tab kopiert und in ein Chat-Fenster eingefügt wird, bevor überhaupt begonnen werden kann. Jede dieser Umgehungslösungen ist Reibung: Sie verlangsamt die Arbeit, eröffnet Fehlermöglichkeiten und setzt eine harte Obergrenze dafür, was der Agent tatsächlich leisten kann. Das GitLab CLI (glab) ändert das, indem es Agenten eine direkte, zuverlässige Schnittstelle zu Projekten gibt.

Mit glab ruft der Agent das Benötigte direkt von GitLab ab, handelt darauf und meldet das Ergebnis zurück – sodass weniger Zeit damit verbracht wird, Informationen weiterzugeben, und mehr Zeit für die eigentliche Arbeit bleibt.

In diesem Tutorial wird gezeigt, wie glab KI-Agenten strukturierten, zuverlässigen Zugriff auf GitLab-Projekte ermöglicht – und wie das einen schnelleren, leistungsfähigeren Entwicklungs-Workflow freischaltet.

KI-Agent über MCP mit GitLab verbinden

Der direkteste Weg, KI-Workflows deutlich leistungsfähiger zu machen, besteht darin, dem KI-Agenten nativen Zugriff auf glab über das Model Context Protocol (MCP) zu geben.

MCP ist ein offener Standard, der KI-Werkzeugen ermöglicht, externe Fähigkeiten zur Laufzeit zu entdecken und zu nutzen. Nach der Verbindung kann der KI-Assistent Issues lesen, Merge Requests kommentieren, Pipeline-Status prüfen und zurück in GitLab schreiben – ohne etwas aus der UI zu kopieren oder auch nur einen einzigen API-Aufruf selbst zu schreiben.

Einstieg mit:

      # MCP-Server von glab starten
glab mcp serve

    

Sobald der MCP-Client konfiguriert ist, kann die KI Fragen wie „Was ist der Status meiner offenen MRs?" oder „Gibt es fehlgeschlagene Pipelines auf main?" beantworten, indem sie GitLab direkt abfragt – nicht durch Scraping der Web-UI, nicht durch veraltete Trainingsdaten. Die vollständige Setup-Dokumentation enthält Konfigurationsschritte für Claude Code, Cursor und andere Editoren.

Ein wichtiges Detail: glab fügt automatisch --output json hinzu, wenn es über MCP aufgerufen wird – für jeden Befehl, der das unterstützt. Der Agent erhält saubere, strukturierte Daten, ohne dass über Ausgabeformate nachgedacht werden muss. Und da glab das offizielle MCP SDK verwendet, bleibt es kompatibel, wenn sich das Protokoll weiterentwickelt.

Wir haben bewusst entschieden, welche Befehle über MCP zugänglich sind. Befehle, die interaktive Terminalausgabe erfordern, sind absichtlich ausgeschlossen – der Agent bleibt nie in einem Wartezustand für Eingaben, die nie kommen. Was zugänglich ist, funktioniert zuverlässig im Agenten-Kontext.

KI am Code-Review beteiligen

Die meisten Entwickler(innen) haben einen Rückstand an MRs, die auf Review warten. Das ist einer der zeitintensivsten Teile der Arbeit – und einer der besten Ansatzpunkte für KI. Mit glab beobachtet der Agent die Review-Queue nicht nur, sondern arbeitet sie gemeinsam durch.

Genau sehen, was noch offen ist

Einstieg mit:

      glab mr view 2677 --comments --unresolved --output json

    

Dieser Befehl gibt den vollständigen MR zurück: Metadaten, Beschreibung und jede ungelöste Diskussion als einzelnes strukturiertes JSON-Payload. Das gibt der KI alles, was sie braucht: welche Threads offen sind, was der Reviewer angefragt hat und in welchem Kontext. Kein Tab-Wechsel, kein manuelles Kopieren einzelner Kommentare.

      {
  "id": 2677,
  "title": "feat: add OAuth2 support",
  "state": "opened",
  "author": { "username": "jdwick" },
  "labels": ["backend", "needs-review"],
  "blocking_discussions_resolved": false,
  "discussions": [
    {
      "id": "3107030349",
      "resolved": false,
      "notes": [
        {
          "author": { "username": "dmurphy" },
          "body": "This error handling will swallow panics — consider wrapping with recover()",
          "created_at": "2026-03-14T09:23:11.000Z"
        }
      ]
    },
    {
      "id": "3107030412",
      "resolved": false,
      "notes": [
        {
          "author": { "username": "sreeves" },
          "body": "Token refresh logic needs a test for the expired token case",
          "created_at": "2026-03-14T10:05:44.000Z"
        }
      ]
    }
  ]
}

    

Statt jeden Thread selbst durchzulesen, lässt sich der Agent fragen: „Was muss ich in MR 2677 noch beheben?" – und erhält eine priorisierte Zusammenfassung mit Änderungsvorschlägen. Das alles aus einem einzigen Befehl.

Den Kreislauf programmatisch schließen

Sobald der KI geholfen hat, das Feedback zu adressieren, kann sie Diskussionen auflösen:

      # Alle Diskussionen auflisten – strukturiert, bereit für den Agenten
glab mr note list 456 --output json

# Diskussion auflösen, sobald das Feedback adressiert wurde
glab mr note resolve 456 3107030349

# Wieder öffnen, wenn etwas erneut geprüft werden muss
glab mr note reopen 456 3107030349

    

      [
  {
    "id": 3107030349,
    "body": "This error handling will swallow panics — consider wrapping with recover()",
    "author": { "username": "dmurphy" },
    "resolved": false,
    "resolvable": true
  },
  {
    "id": 3107030412,
    "body": "Token refresh logic needs a test for the expired token case",
    "author": { "username": "sreeves" },
    "resolved": false,
    "resolvable": true
  }
]

    

Note-IDs sind direkt in der GitLab-UI und der API sichtbar – kein zusätzlicher Lookup nötig. Der Agent kann die vollständige Liste durcharbeiten, jeden Fix prüfen und dabei auflösen.

Mit der KI effektiver über Code sprechen

Auch ohne laufenden MCP-Server gibt es eine einfachere Umstellung, die einen großen Unterschied macht: glab einsetzen, um der KI bessere Informationen zu liefern.

Beim letzten Mal, als ein KI-Assistent bei der Issue-Triage oder beim Debuggen einer fehlgeschlagenen Pipeline geholfen hat, wurde wahrscheinlich etwas Text aus der GitLab-UI kopiert und in den Chat eingefügt. Das ist es, womit der Agent tatsächlich arbeitet:

      open issues: 12 • milestone: 17.10 • label: bug, needs-triage ...

    

Im Vergleich dazu, was er mit glab erhält:

      [
  {
    "iid": 902,
    "title": "Pipeline fails on merge to main",
    "labels": ["bug", "needs-triage"],
    "milestone": { "title": "17.10" },
    "assignees": []
  },
  ...
]

    

Strukturiert, typisiert, vollständig – keine Mehrdeutigkeit, kein Interpretationsaufwand beim Parsen. Das ist der Unterschied zwischen einem Agenten, der handeln kann, und einem, der Rückfragen stellen muss.

Mit dem MCP-Server passiert das automatisch: glab fügt --output json für jeden Befehl hinzu, der das unterstützt. Beim direkten Arbeiten im Terminal einfach das Flag selbst ergänzen:

      # Offene Issues für Triage abrufen
glab issue list --label "needs-triage" --output json

# Pipeline-Status prüfen
glab ci status --output json

# Vollständige MR-Details abrufen
glab mr view 456 --output json

    

Die JSON-Ausgabe wurde in letzten Releases erheblich erweitert. Sie deckt jetzt CI-Status, Milestones, Labels, Releases, Schedules, Cluster-Agenten, Work Items, MR-Genehmiger, Repository-Mitwirkende und mehr ab. Was glab abrufen kann, kann die KI sauber verarbeiten.

Ein echter Workflow

      $ glab issue list --label "needs-triage" --milestone "17.10" \
--output json

    

      Agent: I found 2 unassigned bugs in the 17.10 milestone that need triage:
1. #902 — Pipeline fails on merge to main (opened 5 days ago)
2. #903 — Auth token not refreshing on expiry (opened 4 days ago)
Both are unassigned. Want me to draft triage notes and suggest assignees based on recent commit history?

    

Der Agent ist keineswegs auf eingebaute Befehle beschränkt

Die nativen Befehle von glab decken die gängigsten Workflows ab – aber der Agent ist nicht darauf beschränkt. Über glab api hat er authentifizierten Zugriff auf die vollständige GitLab REST- und GraphQL-API-Oberfläche, mit derselben Session, ohne zusätzliche Credentials oder Konfiguration.

Das ist ein wesentlicher Unterschied. Die meisten CLI-Werkzeuge beschränken sich auf das, was ihre Befehle abbilden. Mit glab gilt: Wenn GitLabs API es unterstützt, kann der Agent es tun – immer aus einem vertrauenswürdigen, authentifizierten Kontext heraus.

Ein praktisches Beispiel: nur die Liste der geänderten Dateien in einem MR abrufen, bevor entschieden wird, welche Diffs vollständig geladen werden:

      # Geänderte Dateipfade abrufen – leichtgewichtig, noch kein Diff-Inhalt
glab api "/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/diffs?per_page=100" \
| jq '.[].new_path'

# Dann nur die spezifische Datei laden, die der Agent benötigt
glab api "/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID/diffs?per_page=100" \
| jq '.[] | select(.new_path == "path/to/file.go")'

    

      "internal/auth/token.go"
"internal/auth/token_test.go"
"internal/oauth/refresh.go"

    

Für alles, was die REST API nicht abdeckt (Epics, bestimmte Work-Item-Abfragen, komplexe projektübergreifende Daten), bietet glab api graphql die vollständige GraphQL-Schnittstelle:

      glab api graphql -f query='
{
  project(fullPath: "gitlab-org/gitlab") {
    mergeRequest(iid: "12345") {
      title
      reviewers { nodes { username } }
    }
  }
}'

    

      {
  "data": {
    "project": {
      "mergeRequest": {
        "title": "feat: add OAuth2 support",
        "reviewers": {
          "nodes": [
            { "username": "dmurphy" },
            { "username": "sreeves" }
          ]
        }
      }
    }
  }
}

    

Ein einziger, authentifizierter Einstiegspunkt zu allem, was GitLab bereitstellt – ohne Token-Jonglieren, separate API-Clients oder Konfigurationsaufwand.

Was als Nächstes kommt – und Feedback

Zwei Verbesserungen, an denen aktiv gearbeitet wird, werden glab für Agenten-Workflows noch nützlicher machen:

Auf Agenten abgestimmter Hilfetext. Heute ist die --help-Ausgabe für Menschen am Terminal geschrieben. Sie wird aktualisiert, um für jeden interaktiven Befehl die nicht-interaktive Alternative anzuzeigen, Befehle mit --output json-Unterstützung zu kennzeichnen und Hilfe generell zu einer nützlichen Ressource für Agenten zu machen, die Fähigkeiten zur Laufzeit entdecken – nicht nur für Menschen.

Besser maschinenlesbare Fehlermeldungen. Wenn heute etwas schiefläuft, erhalten Agenten dieselben menschenlesbaren Fehlermeldungen wie Terminal-Nutzende. Das wird geändert: Fehler im JSON-Modus geben strukturierte Ausgaben zurück, die dem Agenten die Informationen liefern, die er braucht, um Fehler sauber zu behandeln, intelligent zu wiederholen oder den richtigen Kontext zurückzugeben.

Beide Punkte sind in aktiver Entwicklung. Wer glab bereits mit einem KI-Werkzeug einsetzt, ist genau die Zielgruppe, deren Erfahrungen uns interessieren.

• Welche Reibungspunkte gibt es? Befehle, die sich in Agenten-Kontexten nicht gut verhalten, Fehlermeldungen ohne Handlungsanleitung, Lücken in der JSON-Ausgabe. Feedback ist willkommen.
• Welche Workflows wurden erschlossen? Reale Nutzungsmuster helfen dabei, Prioritäten für die weitere Entwicklung zu setzen.

Die Diskussion findet im Feedback-Issue statt – dort wird die Roadmap für Agenten-Freundlichkeit gestaltet, und Beiträge haben dort den direktesten Einfluss. Wer eine spezifische Lücke gefunden hat, kann ein Issue öffnen. Wer einen Fix im Sinn hat: Beiträge sind willkommen. Details unter CONTRIBUTING.md.

Das GitLab CLI stand schon immer dafür, Entwickler(inne)n mehr Kontrolle über ihren Workflow zu geben. Da KI ein immer größerer Teil der täglichen Arbeit wird, bedeutet das, glab zur bestmöglichen Schnittstelle zwischen KI-Werkzeugen und GitLab-Projekten zu machen. Wir stehen am Anfang – und freuen uns darauf, den nächsten Teil gemeinsam zu gestalten.