Instalación

GitLab MCP Server es un único binario autocontenido escrito en Go. Todos los canales de esta página entregan ese mismo binario, o un contenedor que lo envuelve, y el mismo comando gitlab-mcp-server, así que la elección depende de lo que ya tengas en la máquina y de cómo quieras recibir las actualizaciones, no de las funcionalidades. Elijas lo que elijas, el servidor necesita un solo valor para arrancar: un personal access token de GitLab en GITLAB_TOKEN (scope api; un token read_api también sirve: el servidor lo detecta al arrancar y le sirve las acciones que GitLab acepta con él, tanto en stdio como en modo HTTP y en el endpoint alojado). GITLAB_URL usa https://gitlab.com por defecto, así que solo la estableces para una instancia autogestionada.

Elige un canal

Canal	Qué obtienes	Necesita	Vía de actualización	Plataformas
Binario nativo	El binario de la release, colocado por un script de instalación o a mano	Nada (el script necesita curl o wget; PowerShell en Windows)	Vuelve a ejecutar el script, o descarga la release nueva	Linux, macOS, Windows; amd64 y arm64
Homebrew	El binario de la release, instalado por una fórmula del tap jmrplens/tap	Homebrew	brew upgrade	macOS y Linux; Apple Silicon, Intel y arm64
Windows (winget)	El ejecutable de la release como paquete portable con un alias en el PATH	winget	winget upgrade	Windows; x64 y arm64
Docker	Una imagen de contenedor en GHCR, replicada en Docker Hub	Docker o un runtime compatible	Descarga una etiqueta más nueva y recrea el contenedor	Imágenes linux/amd64 y linux/arm64, allá donde corra Docker
npm y npx	Un paquete lanzador más un paquete de plataforma que lleva el binario	Node.js 18 o superior	npm update -g; npx -y resuelve la versión más nueva en cada arranque en frío	Linux (glibc), macOS, Windows; x64 y arm64
PyPI, uvx y pipx	Una wheel que coloca el binario en la ruta de scripts del entorno	Python 3.9 o superior (uv o pipx opcionales)	pipx upgrade, pip install -U o uv tool upgrade; uvx resuelve la versión más nueva en un arranque en frío	Linux (glibc), macOS 11 o superior, Windows; x64 y arm64
NuGet y dnx	Una herramienta .NET cuyo punto de entrada es el binario, un paquete por identificador de runtime	El SDK de .NET 10 o superior	dotnet tool update -g; dnx resuelve la versión más nueva en cada arranque	Linux (glibc), macOS, Windows; x64 y arm64
Plugins de agente	Un manifiesto de plugin que ejecuta la imagen Docker sobre stdio	Un host conforme (Cursor, Claude Code, VS Code, OpenCode) y Docker	La etiqueta latest de la imagen, descargada de nuevo	Allá donde corran el host y Docker
Claude Desktop (.mcpb)	Una extensión de escritorio por sistema operativo: el binario universal de macOS, el ejecutable de Windows o los binarios de Linux x64 y arm64 (a partir de la primera release posterior a 3.1.0; hasta la 3.1.0, un único paquete universal para los tres)	Claude Desktop 0.10.0 o superior	Con cada release se publica una versión nueva de la extensión	macOS (Apple Silicon e Intel), Windows (x64), Linux (glibc; x64 y arm64)
Endpoint alojado	Nada instalado: un endpoint público de streamable HTTP	Un cliente MCP con soporte HTTP y un token de GitLab.com	Avanza por sí solo, normalmente a la última release	Cualquiera

El servidor no se actualiza a sí mismo

Nunca comprueba si hay actualizaciones ni reemplaza su propio binario, en ningún canal. Las actualizaciones vienen de lo que lo instaló: brew upgrade, winget upgrade, npm update, dotnet tool update, una etiqueta de imagen más nueva, una versión nueva de la extensión o una descarga nueva. Un antiguo subsistema de autoactualización se eliminó: el gestor de paquetes que instaló los archivos es quien los gestiona. gitlab-mcp-server --version imprime gitlab-mcp-server <versión> (commit: <commit>), así que siempre puedes ver qué tienes; la release actual es la 3.2.0.

¿Cuál elegir?

• Quieres la huella más pequeña y ningún runtime. El binario nativo. Homebrew y winget instalan ese mismo binario y se ocupan de las actualizaciones.
• Tu cliente ya lanza servidores con npx, uvx o dnx. Los paquetes de npm, PyPI y NuGet: nada que instalar de antemano, y el cliente resuelve la versión más nueva por su cuenta.
• Prefieres no poner nada en el host, o despliegas para un equipo. Docker, sobre stdio para un cliente o en modo HTTP tras un puerto.
• Usas Claude Desktop. La extensión .mcpb: un clic, y el token se cifra con una clave del almacén de credenciales del sistema operativo, donde lo hay.
• Solo quieres echar un vistazo. El endpoint alojado, desde cualquier cliente con soporte HTTP o directamente desde el inspector del navegador.

Binario nativoScript de instalación, una línea de PowerShell o una descarga desde GitHub Releases. Verifica el checksum y la firma.

Homebrewbrew install jmrplens/tap/gitlab-mcp-server en macOS o Linux; se actualiza con brew upgrade.

Windows (winget)winget install --id jmrplens.gitlab-mcp-server -e, un paquete portable con un alias en el PATH.

Dockerghcr.io/jmrplens/gitlab-mcp-server sobre stdio para un cliente de escritorio, o como servicio HTTP en un puerto.

npm y npxnpx -y @jmrp.io/gitlab-mcp-server, o una instalación global; solo se descarga el binario de tu plataforma.

PyPI, uvx y pipxuvx jmrplens-gitlab-mcp-server, pipx o pip; la wheel lleva el binario nativo.

NuGet y dnxdnx gitlab-mcp-server o dotnet tool install; una herramienta .NET cuyo punto de entrada es el binario nativo.

Plugins de agente/plugin install jmrplens/gitlab-mcp-server en Cursor, Claude Code, VS Code u OpenCode.

Claude Desktop (.mcpb)La extensión de escritorio de un clic para macOS, Windows y Linux (x64 y arm64).

Endpoint alojadohttps://mcp.jmrp.io/gitlab: prueba el servidor sin instalar nada, y luego ejecútalo en local.

Después de instalar

Todos los canales terminan en el mismo sitio: tu cliente MCP lanza gitlab-mcp-server (o el comando docker, npx, uvx o dnx que lo envuelve) con GITLAB_TOKEN en su entorno. Cada página de canal cierra con el fragmento mínimo de cliente para su comando, y el Inicio rápido tiene las pestañas por cliente para VS Code, Claude Desktop, Cursor, Claude Code, Windsurf, JetBrains, Zed, Kiro, Cline y Codex. La entrada de cada cliente por stdio, y por HTTP con un token o con OAuth, está en Configuración de clientes.

Dos cosas que conviene saber antes de la primera ejecución:

• Si arrancas el binario en una terminal, o le haces doble clic en Windows, sin GITLAB_URL y GITLAB_TOKEN definidos, imprime qué es y los dos valores que necesita, y espera a que pulses Enter. Un cliente MCP nunca ve esa pantalla, porque se conecta por tuberías y no por una terminal. No hay asistente de configuración.
• El token puede quedarse fuera del JSON del cliente por completo: una variable de entorno explícita gana al archivo que nombre GITLAB_MCP_ENV_FILE, que gana a ~/.gitlab-mcp-server.env (un CLAVE=valor por línea). Un .env en el directorio de trabajo no se lee. Consulta Configuración.

Después abre tu cliente y pregunta “¿Quién soy en GitLab?”. En la superficie dynamic por defecto, el asistente llama a gitlab_find_action y después a gitlab_execute_action con la acción user.current, y responde con tu perfil de GitLab.

Cómo llega una release a cada canal

El binario nativo, Homebrew, winget, npm, PyPI, NuGet y la extensión de Claude Desktop llevan todos el binario que GoReleaser compiló para la release, byte a byte; la imagen de contenedor, y la entrada de Plugins de agente que la ejecuta, llevan una compilación propia. El workflow de release los publica en un orden que mantiene oculta cualquier release a medias:

1. La imagen de contenedor la construye un job propio a partir de la misma etiqueta, con su propia copia del binario (consulta Docker). Las dos variantes de plataforma se arrancan y se les pide su versión antes de publicar la imagen, y se firma y se atesta antes de que se publique ningún otro canal.
2. La GitHub release se crea como borrador con los binarios, checksums.txt y su firma Cosign, los SBOM y los paquetes de Claude Desktop, que se montan en el mismo job a partir de los mismos binarios. Solo se publica cuando todos sus archivos están adjuntos y atestados, así que una release que puedes ver nunca está a medias.
3. npm, PyPI y NuGet se empaquetan después, cada uno en un job propio que descarga los archivos publicados de la release y los comprueba contra el checksums.txt firmado antes de empaquetar nada.
4. Un job de relectura descarga después lo que sirven npm, PyPI y NuGet y compara los binarios de dentro de los paquetes con ese mismo checksums.txt firmado; a partir de la primera release posterior a 3.1.0 también contrasta cada paquete de NuGet, sin la firma de repositorio de NuGet.org, con el digest que la release atestó para él.
5. Nada que anuncie la versión se ejecuta antes de que esa comparación pase: el tap de Homebrew, la entrada del MCP Registry, el commit de los manifiestos a main y el pull request de winget esperan a ella. Una release cuya publicación en npm, PyPI o NuGet falló los deja en la versión anterior.

Cómo comprobar tú mismo una descarga está en la página Binario nativo, y el contexto en Verificación de la integridad del release.