Neue MCP-Tools skalieren Automatisierung für Platform-Teams

Agentische Tools gehen längst über Code-Vervollständigung hinaus: Sie führen Pipelines aus, öffnen Merge Requests und triagieren Arbeit im Auftrag eines Teams. Das Model Context Protocol (MCP) hat sich als gängiger Weg etabliert, über den diese Agenten auf die vorhandenen Tools eines Teams zugreifen. Das bedeutet: Die Agenten, die auf die Software-Delivery-Pipeline einer Organisation zugreifen, sind nicht mehr nur diejenigen, die ein Platform-Team selbst ausgewählt und konfiguriert hat.

Genau diese Reichweite ist auch der Punkt, an dem Automatisierung typischerweise ins Stocken gerät. Je mehr ein Agent kann, desto mehr muss ein Platform-Team darüber nachdenken, was er ohne vorherige Rückfrage tun darf – ein Governance-Problem, das meist eher durch Einschränken als durch Erweitern des Zugriffs gelöst wird. Unbeachtet löst sich das nicht von selbst: Teams sperren Agenten entweder auf eine Handvoll sicherer, lesender Aktionen ein, oder sie öffnen alles und hoffen das Beste – keines von beidem skaliert.

GitLabs Antwort: breiter Tool-Zugriff und konsistente Governance gehören zusammen. Rollen Platform Engineers Agenten in der eigenen Organisation aus, ob als GitLab Flow oder als Drittanbieter-Client über den GitLab MCP Server angebunden, braucht es denselben Zugriff auf GitLab. Doch größere Reichweite erhöht auch die Anforderungen an die Kontrolle: Ein Mensch sollte entscheiden, welche Aktionen ein Agent eigenständig ausführen darf und welche Reviewer(innen) brauchen, damit routinemäßige, lesende Abfragen schnell laufen, während alles, was schreibt, mergt oder löscht, auf die vom Team gewählte Prüfung wartet.

GitLab Transcend ist im Oktober zurück

Coding-Agenten beschleunigen die Entwicklung, doch Reviews, Sicherheitsrichtlinien und Release-Zyklen müssen mithalten können. Das Transcend-Event am 6. Oktober zeigt, wie GitLab Teams dabei hilft, diese Lücke zu schließen, und beleuchtet, was nötig ist, um das Tempo agentischer KI über den gesamten Software-Lebenszyklus hinweg mitzugehen.

Jetzt für den Livestream registrieren!

Gebaut für skalierende Automatisierung in Platform-Teams

Mit GitLab 19.4 können Platform-Teams mehr vom Software-Lebenszyklus durchgängig automatisieren: Ein Agent kann eine Pipeline ausführen, einen Merge Request öffnen und aktualisieren oder eine Schwachstelle bearbeiten, nicht nur nachschlagen. Lesende Aktionen laufen standardmäßig ohne Mensch im Loop, sodass Agenten im Tempo der eigentlichen Arbeit vorankommen. Alles, was schreibt, mergt oder löscht, wartet weiterhin auf die vom Team gewählte Prüfung – breiterer Zugriff für Agenten erweitert also nicht, was sie unbeaufsichtigt tun dürfen.

Das Tool-Set des GitLab MCP Servers wächst mit diesem Release erheblich: Es kommen Tools für CI/CD, Merge Requests, Work Items, Schwachstellen und Projekte hinzu.

Diese MCP-Server-Tools in Aktion:

Eine breitere Automatisierungsfläche, Tool für Tool

GitLab fügt ein umfangreiches Set neuer MCP-Server-Tools hinzu und gibt Agenten damit die Abdeckung, die sie brauchen, um reale Arbeit durchgängig zu erledigen.

• CI/CD-Tools. save_pipeline führt eine Pipeline aus, wiederholt, storniert oder benennt sie um. get_job gibt standardmäßig den Job zurück. Wird include: ["log"] übergeben, kommt der Job-Trace hinzu, paginiert über byte_offset und byte_limit (512 KB pro Seite), sodass ein Agent das Log eines fehlgeschlagenen Builds abrufen und das Problem direkt diagnostizieren kann.
• Merge-Request-Tools. save_merge_request öffnet und aktualisiert einen MR. get_merge_request liefert Diffs, Konflikte oder Approvals (jeweils einzeln über den Include-Parameter), wobei Diffs standardmäßig auf Stats-Ebene liegen, sofern nicht detail: full_patch für den vollständigen Patch-Text angefordert wird. list_merge_requests arbeitet auf Gruppenebene. save_merge_request_review deckt den gesamten Review-Ablauf in einem Tool ab: einen zeilenbezogenen Kommentar oder eine Zusammenfassung posten, in einer Diskussion antworten oder sie auflösen, ein vollständiges Review einreichen, ein Duo-Review auslösen sowie genehmigen oder die Genehmigung zurückziehen. accept_merge_request merged einen MR standardmäßig sofort, wartet mit strategy: merge_when_checks_pass auf bestandene Checks oder fügt ihn mit add_to_merge_train_when_checks_pass einem Merge Train hinzu.
• Repository-Tools. list_repository_tree ermöglicht das Erkunden des Dateibaums. list_branches und list_tags listen Refs auf. list_releases ermöglicht die Einsicht veröffentlichter Releases. list_commits, get_commit und add_commit ermöglichen direkte Interaktion mit Inhalt und Historie eines Repositorys. fork_repository forkt ein Projekt, damit ein Agent Änderungen vornehmen kann, ohne das Upstream-Repository zu beeinflussen.
• Projekt- und Nutzer-Tools. get_project und list_projects finden und lesen Projektdetails. list_project_members listet Mitglieder und ihre Rollen auf. get_user schlägt Nutzerdetails für Zuweisungen und Erwähnungen nach.
• Work-Item-Tools. get_work_item liest ein einzelnes Item im Detail und deckt ab, was zuvor get_issue tat. list_work_items durchsucht eine Gruppe oder ein Projekt. save_work_item erstellt oder aktualisiert jeden unterstützten Work-Item-Typ und deckt ab, was zuvor create_issue tat. Issues und Epics sind selbst Work-Item-Typen. save_note kommentiert ein Work Item oder einen Merge Request und kann innerhalb eines bestehenden Threads antworten. Es ersetzt create_merge_request_note und create_workitem_note.
• Schwachstellen-Tools (verfügbar auf Ultimate). list_vulnerabilities listet Schwachstellen in einem Projekt auf, filterbar nach Schweregrad und Report-Typ, mit Cursor-Pagination. get_vulnerability liefert vollständige Details zu einer einzelnen Schwachstelle per ID. save_vulnerability konsolidiert fünf Schreibaktionen zu einem einzigen Tool: verwerfen, bestätigen, auf "erkannt" zurücksetzen, Schweregrad aktualisieren und ein verknüpftes Issue erstellen.
• Ein neuer Merge-Request-Trigger. GitLab 19.4 führt die Trigger-Aktion Created für Merge Requests ein: Ein Flow oder externer Agent kann jetzt in dem Moment laufen, in dem jemand einen Merge Request öffnet, sobald GitLab den Diff erzeugt hat. Nutzbar für ein erstes Review oder um Kontext aus verwandten Issues heranzuziehen. Konfigurierbar unter AI > Triggers im eigenen Projekt oder beim Aktivieren eines Flows.

Automatisierung skalieren, einen Agenten nach dem anderen

Das erweiterte Tool-Set ist aktuell als Beta verfügbar. Es markiert einen ersten Schritt hin zu einer Plattform, auf der jeder Agent (intern oder von Drittanbietern) denselben Governance-Regeln unterliegt und dieselbe Tiefe an GitLab-Kontext erreicht. Mit jedem weiteren Tool und Trigger wächst dieses Governance-Modell mit, sodass Platform Engineers Leitplanken einmal konfigurieren, statt für jeden neuen Client erneut.

Bereit, es auszuprobieren? Los geht's mit der Dokumentation zu den MCP-Server-Tools und der Dokumentation zur Tool-Governance.

Die neuen MCP-Server-Tools sind als Beta auf Free, Premium und Ultimate verfügbar, mit Ausnahme der Schwachstellen-Tools, die Ultimate voraussetzen. Der Merge request created-Trigger setzt Premium oder Ultimate sowie aktivierte GitLab Duo Agent Platform voraus. Die Trigger-Dokumentation beschreibt die Konfiguration für das eigene Projekt.

Bereits auf Premium oder Ultimate und der Merge request created-Trigger gewünscht? Zuerst Duo Agent Platform aktivieren und die im eigenen Abonnement enthaltenen GitLab Credits nutzen.