Ir al contenido

npm y npx

GitLab MCP Server está publicado en npm como @jmrp.io/gitlab-mcp-server. Es el mismo binario nativo en Go que distribuyen todos los demás canales, empaquetado para que npx pueda lanzarlo sin paso de instalación y npm install -g pueda ponerlo en tu PATH. No se compila nada y nada se ejecuta durante la instalación.

El conjunto publicado es un lanzador más seis paquetes por plataforma, siguiendo el modelo que usan esbuild y Biome:

  • @jmrp.io/gitlab-mcp-server es un pequeño shim de Node.js (cli.js) registrado como el comando gitlab-mcp-server. Resuelve el binario de la plataforma actual, lo arranca con tu stdio y tus argumentos intactos, y replica el código de salida y la señal de terminación del binario, de modo que el cliente ve el resultado real.
  • @jmrp.io/gitlab-mcp-server-<plataforma> son los paquetes que llevan el binario en sí, uno por plataforma: linux-x64, linux-arm64, darwin-x64, darwin-arm64, win32-x64 y win32-arm64. Se declaran como dependencias opcionales del lanzador, fijadas a su versión exacta, y cada uno está limitado por os y cpu, así que npm instala exactamente uno: el que coincide con tu máquina.

Como el binario llega dentro de un paquete corriente, no hay script de postinstalación, no se descarga nada después de instalar y no se compila nada. Por eso la instalación funciona con --ignore-scripts, tras un proxy y en un job de CI gobernado por un lockfile.

Requisitos: Node.js 18 o superior y, en Linux, glibc: los binarios son ejecutables independientes de la posición (PIE) que necesitan el cargador dinámico de glibc. Desde la primera release posterior a 2.7.5 los paquetes de Linux declaran libc: ["glibc"], así que npm los omite en distribuciones musl como Alpine y el lanzador te remite a la imagen Docker, que está basada en musl. En 2.7.5 el paquete se instala en Alpine y el binario falla después al arrancar con “no such file or directory”; usa ahí la imagen Docker.

Sin instalar nada: el cliente lanza el comando directamente, y npx conserva una copia en su caché tras la primera ejecución.

Ventana de terminal
npx -y @jmrp.io/gitlab-mcp-server

La opción -y suprime la pregunta de npx de si quieres instalar el paquete, que un cliente MCP no tiene forma de responder.

Tras una instalación global, el comando en tu PATH es gitlab-mcp-server:

Ventana de terminal
gitlab-mcp-server --version
# gitlab-mcp-server 2.7.5 (commit: ...)

Si lo arrancas en una terminal sin GITLAB_URL y GITLAB_TOKEN definidos, el binario imprime qué es y los dos valores que necesita, y después espera a que pulses Enter. Es la pantalla de primer arranque, no un error: un cliente MCP conecta tuberías en lugar de una terminal y nunca la ve. No hay asistente de configuración; la configuración va en el JSON de tu cliente, más abajo.

gitlab-mcp-server: the @jmrp.io/gitlab-mcp-server-<plataforma> package is not installed significa que la plataforma está soportada pero su paquete se omitió. Las causas habituales son una instalación con --no-optional, un lockfile generado en otro sistema operativo o un sistema musl. Reinstala sin --no-optional, o borra node_modules y el lockfile e instala de nuevo. En una plataforma sin binario precompilado el lanzador termina con un mensaje que apunta a los binarios de la release y a compilar desde el código fuente.

La forma portable no necesita instalar nada. Apunta el cliente a npx:

{
"mcpServers": {
"gitlab": {
"command": "npx",
"args": ["-y", "@jmrp.io/gitlab-mcp-server"],
"env": { "GITLAB_TOKEN": "glpat-xxxxxxxxxxxxxxxxxxxx" }
}
}
}

Tras una instalación global, usa el comando en su lugar:

{
"mcpServers": {
"gitlab": {
"command": "gitlab-mcp-server",
"env": { "GITLAB_TOKEN": "glpat-xxxxxxxxxxxxxxxxxxxx" }
}
}
}

GITLAB_TOKEN es el único valor obligatorio: un token de acceso personal con el scope api (read_api también sirve; acompáñalo de GITLAB_MCP_READ_ONLY=true, porque sobre stdio el servidor no recorta la superficie de herramientas al scope del token). GITLAB_URL usa por defecto https://gitlab.com; añádela a env solo para una instancia autogestionada. Un cliente que no herede el PATH de tu shell puede necesitar la ruta completa al comando; which gitlab-mcp-server (o where gitlab-mcp-server en Windows) la imprime. Para fijar una release en lugar de seguir la más reciente, nómbrala en el argumento: "@jmrp.io/gitlab-mcp-server@2.7.5".

Las rutas de archivo y las formas de cada cliente (VS Code usa servers con "type": "stdio", Zed usa context_servers) están en las pestañas por cliente del Inicio rápido.

El servidor nunca comprueba si hay actualizaciones ni reemplaza su propio binario; aquí es npm quien lo gestiona, igual que cada canal gestiona lo que instaló. Cada release mueve a la vez el lanzador y sus seis paquetes de plataforma con versiones fijadas de forma exacta, así que actualizar el lanzador actualiza el binario, y un lanzador antiguo nunca resuelve un binario más nuevo ni al revés.

npx resuelve la versión publicada más reciente en una ejecución en frío y reutiliza su caché después. Para forzar la última release, nómbrala explícitamente:

Ventana de terminal
npx -y @jmrp.io/gitlab-mcp-server@latest

No se instaló nada, así que no hay nada que desinstalar más allá de la entrada en la configuración de tu cliente.

El resto de canales se comparan en la vista general de instalación.