Install
npx -y @modelcontextprotocol/server-gitlabPara quién
Para quien necesita que un modelo haga gestión de proyectos y operaciones de archivos a través de la API de GitLab, y ya puede emitir un token de acceso personal en GitLab. Encaja si puedes arrancar @modelcontextprotocol/server-gitlab con npx en el cliente y aceptas que la primera llamada escribirá en el repositorio. No encaja sin token, o si no quieres que el modelo cree/actualice archivos (y cree la rama automáticamente cuando no exista). Página oficial: https://github.com/modelcontextprotocol/servers-archived/tree/main/src/gitlab
Primer intento en 3 minutos
Sigue una sola ruta oficial: ejecuta el paquete oficial con npx y proporciona un token de acceso personal de GitLab en las variables de entorno del cliente. No pongas el token en la línea de comandos ni en el chat.
Requisito previo: en GitLab abre User Settings > Access Tokens y crea un token de acceso personal con permisos suficientes. Página del token: https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html
Dónde instalar y configurar: en el cliente MCP escribe el comando así:
npx -y @modelcontextprotocol/server-gitlab
También establece la variable de entorno GITLAB_PERSONAL_ACCESS_TOKEN con el token que acabas de crear; no rellenes un marcador de posición.
Acción de bajo riesgo: la herramienta nombrada en el extracto es create_or_update_file y escribe. Antes de llamarla, ten claros los efectos secundarios: crea o actualiza un archivo en el proyecto; si la rama destino no existe, el servidor la crea automáticamente. El punto de confirmación es un commit nuevo (y quizá una rama nueva) en la página web de GitLab, no solo la palabra «éxito» en el cliente. Los parámetros incluyen al menos project_id (ID de proyecto o ruta codificada en URL); las notas también listan file_path, content, commit_message, branch. La primera vez usa una rama nueva de la que nadie más dependa; no experimentes contra el tronco predeterminado.
Señal de éxito: el proyecto indicado en GitLab muestra un archivo nuevo o una actualización con tu mensaje de commit. Si solo hay un error de autenticación, vuelve a Access Tokens, comprueba que el token siga vigente y que el nombre de la variable sea GITLAB_PERSONAL_ACCESS_TOKEN.
Casos de uso
Caso 1: cambiar un archivo. Corresponde a create_or_update_file. Sirve para que el modelo confirme un cambio de un solo archivo. Los efectos secundarios son los mismos: escribir un archivo y crear la rama si falta. La evidencia no describe el manejo de conflictos ni un force-push; no asumas que puedes sobrescribir el historial remoto de otra persona.
Caso 2: gestión de proyectos. El servidor se posiciona como “project management, file operations, and more”. Además de create_or_update_file, el extracto no desarrolla el nombre ni los parámetros de una segunda herramienta. Por eso este caso solo llega hasta aquí: operar en otras herramientas que el cliente liste de verdad; si la lista no tiene una herramienta de solo lectura para recorrer el proyecto, no inventes comandos list/search. Detente en la escritura de un solo archivo ya documentada.
Límites de uso
No se nombra ninguna herramienta de solo lectura. create_or_update_file cambia el repositorio remoto; la creación automática de ramas significa que un branch incorrecto también dejará una rama nueva en GitLab que deberás limpiar después.
Basta un token con «permisos adecuados»; el extracto no fija nombres de scope concretos, no cambies el conjunto de permisos por tu cuenta a partir de otros documentos.
No se da por separado una forma de instalación alternativa; el núcleo del fragmento de configuración oficial es el nombre de paquete npx @modelcontextprotocol/server-gitlab. No escribas un token de relleno en un archivo de configuración. Las llamadas llegan a la API de GitLab; no es red cero ni un límite de identidad nulo. El “and more” del resumen de funciones no es un inventario de herramientas ya listado.