Install
npx -y @modelcontextprotocol/server-gitlabÀ qui ça s’adresse
À ceux qui ont besoin qu’un modèle fasse de la gestion de projet et des opérations sur fichiers via l’API GitLab, et qui peuvent déjà émettre un jeton d’accès personnel dans GitLab. Convient si l’on peut lancer @modelcontextprotocol/server-gitlab avec npx dans le client et si l’on accepte que le premier appel écrive dans le dépôt. Ne convient pas sans jeton, ou si l’on ne veut pas que le modèle crée/mette à jour des fichiers (et crée automatiquement une branche si elle n’existe pas). Page officielle : https://github.com/modelcontextprotocol/servers-archived/tree/main/src/gitlab
Premier essai en 3 minutes
Une seule voie officielle : exécuter le paquet officiel avec npx, et fournir un jeton d’accès personnel GitLab dans les variables d’environnement du client. Ne pas écrire le jeton dans la ligne de commande ni dans le chat.
Prérequis : dans GitLab, ouvrir User Settings > Access Tokens et créer un jeton d’accès personnel avec des droits suffisants. Page du jeton : https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html
Emplacement d’installation et de configuration : dans le client MCP, écrire la commande ainsi :
npx -y @modelcontextprotocol/server-gitlab
Définir aussi la variable d’environnement GITLAB_PERSONAL_ACCESS_TOKEN avec le jeton venant d’être créé ; ne pas mettre un espace réservé.
Action à faible risque : l’outil nommé dans l’extrait est create_or_update_file, et il écrit. Avant l’appel, avoir les effets de bord en tête : il crée ou met à jour un fichier dans le projet ; si la branche cible n’existe pas, le serveur la crée automatiquement. Le point de contrôle est un nouveau commit (et éventuellement une nouvelle branche) sur la page web GitLab, pas seulement le mot « succès » dans le client. Les paramètres incluent au moins project_id (ID de projet ou chemin encodé URL) ; les notes listent aussi file_path, content, commit_message, branch. La première fois, utiliser une nouvelle branche dont personne d’autre ne dépend ; ne pas expérimenter sur le tronc par défaut.
Signal de succès : le projet indiqué sur GitLab montre un nouveau fichier ou une mise à jour avec votre message de commit. S’il n’y a qu’une erreur d’authentification, revenir à Access Tokens, vérifier que le jeton est encore valide et que le nom de variable est GITLAB_PERSONAL_ACCESS_TOKEN.
Cas d’usage
Cas 1 : modifier un fichier. Correspond à create_or_update_file. Sert à faire commiter au modèle un changement d’un seul fichier. Effets de bord identiques : écrire un fichier, créer la branche si elle manque. Les preuves ne décrivent ni la gestion des conflits ni un force-push ; ne pas supposer pouvoir écraser l’historique distant d’autrui.
Cas 2 : gestion de projet. Le serveur est positionné comme “project management, file operations, and more”. Hormis create_or_update_file, l’extrait n’étend ni le nom ni les paramètres d’un second outil. Ce cas ne peut donc aller que jusque-là : opérer sur les autres outils que le client liste réellement ; s’il n’y a pas d’outil de parcours de projet en lecture seule, ne pas inventer de commandes list/search. S’arrêter à l’écriture d’un seul fichier déjà documentée.
Limites d’usage
Aucun outil en lecture seule n’est nommé. create_or_update_file modifie le dépôt distant ; la création automatique de branche signifie qu’un branch erroné laissera aussi une nouvelle branche sur GitLab, à nettoyer ensuite.
Un jeton avec des « droits appropriés » suffit ; l’extrait ne fige pas de noms de scope précis, ne pas changer l’ensemble des droits d’après d’autres documents.
Aucune forme d’installation alternative n’est donnée à part ; le cœur du fragment de configuration officiel est le nom de paquet npx @modelcontextprotocol/server-gitlab. Ne pas écrire un jeton factice dans un fichier de configuration. Les appels atteignent l’API GitLab ; ce n’est ni zéro réseau, ni une frontière d’identité nulle. Le “and more” de l’aperçu fonctionnel n’est pas un inventaire d’outils déjà listé.