Install
npx -y @modelcontextprotocol/server-gitlabFür wen
Für alle, die ein Modell über die GitLab API Projektverwaltung und Dateioperationen machen lassen und in GitLab bereits ein persönliches Zugriffstoken ausstellen können. Passend, wer @modelcontextprotocol/server-gitlab im Client per npx starten kann und akzeptiert, dass der erste Aufruf ins Repository schreibt. Nicht geeignet ohne Token oder wenn das Modell keine Dateien erstellen/aktualisieren soll (und bei fehlendem Branch automatisch einen anlegt). Offizielle Seite: https://github.com/modelcontextprotocol/servers-archived/tree/main/src/gitlab
Erster Versuch in 3 Minuten
Nur einen offiziellen Weg gehen: das offizielle Paket mit npx ausführen und ein GitLab-Persönliches-Zugriffstoken in den Client-Umgebungsvariablen bereitstellen. Das Token nicht in die Kommandozeile oder den Chat schreiben.
Voraussetzung: In GitLab User Settings > Access Tokens öffnen und ein persönliches Zugriffstoken mit ausreichenden Rechten anlegen. Token-Hinweise: https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html
Installations- und Konfigurationsort: Im MCP-Client den Befehl so schreiben:
npx -y @modelcontextprotocol/server-gitlab
Zusätzlich die Umgebungsvariable GITLAB_PERSONAL_ACCESS_TOKEN auf das gerade erzeugte Token setzen, keinen Platzhalter eintragen.
Aktion mit geringem Risiko: Das im Auszug genannte Tool ist create_or_update_file, und es schreibt. Vor dem Aufruf die Nebenwirkungen klar machen: Es erstellt oder aktualisiert eine Datei im Projekt; fehlt der Zielbranch, legt der Server ihn automatisch an. Prüfpunkt ist ein neuer Commit (und ggf. ein neuer Branch) auf der GitLab-Webseite, nicht nur das Wort „Erfolg“ im Client. Parameter umfassen mindestens project_id (Projekt-ID oder URL-kodierter Pfad); die Hinweise listen außerdem file_path, content, commit_message, branch. Beim ersten Mal einen neuen Branch nutzen, von dem niemand abhängt; nicht gegen den Standardstamm experimentieren.
Erfolgssignal: Im angegebenen Projekt auf GitLab erscheint eine neue Datei oder eine Dateiaktualisierung mit deiner Commit-Nachricht. Kommt nur ein Auth-Fehler, zu Access Tokens zurückkehren, prüfen ob das Token noch gilt und der Variablenname GITLAB_PERSONAL_ACCESS_TOKEN ist.
Anwendungsfälle
Fall 1: Eine Datei ändern. Entspricht create_or_update_file. Damit das Modell eine Ein-Datei-Änderung committet. Nebenwirkungen wie oben: Datei schreiben, fehlenden Branch anlegen. Die Belege beschreiben weder Konfliktauflösung noch Force-Push; nicht annehmen, fremde Remote-Historie überschreiben zu können.
Fall 2: Projektverwaltung. Der Server ist als “project management, file operations, and more” positioniert. Neben create_or_update_file entfaltet der Auszug Namen und Parameter eines zweiten Tools nicht. Dieser Fall reicht deshalb nur so weit: auf anderen Tools arbeiten, die der Client tatsächlich auflistet; fehlt ein schreibgeschütztes Projekt-Browsing-Tool, keine list/search-Befehle erfinden. Bei der bereits beschriebenen Ein-Datei-Schreibfähigkeit bleiben.
Nutzungsgrenzen
Kein schreibgeschütztes Tool ist genannt. create_or_update_file ändert das Remote-Repository; automatisches Branch-Anlegen heißt, dass ein falsches branch auf GitLab einen neuen Branch hinterlässt, den du danach aufräumen musst.
Ein Token mit „angemessenen Rechten“ reicht; der Auszug legt keine konkreten Scope-Namen fest, die Rechte menge nicht anhand anderer Dokumente selbst umbauen.
Eine alternative Installationsform wird nicht separat genannt; Kern des offiziellen Konfigurationsschnipsels ist der npx-Paketname @modelcontextprotocol/server-gitlab. Kein Platzhalter-Token in eine Konfigurationsdatei schreiben. Aufrufe treffen die GitLab API; das ist weder null Netz noch eine null Identitätsgrenze. Das “and more” in der Funktionsübersicht ist kein veröffentlichtes Toolinventar.