PyPI, uvx y pipx

GitLab MCP Server está publicado en PyPI como jmrplens-gitlab-mcp-server. Las wheels siguen el modelo que usan uv y ruff: cada una lleva el binario nativo en Go de una plataforma, el instalador coloca ese binario en la ruta de scripts del entorno como el propio comando, y no se ejecuta Python mientras corre el servidor.

Qué obtienes

Seis wheels de plataforma, una por sistema operativo y arquitectura, etiquetadas py3-none (sin dependencia de una ABI de Python) y que requieren Python 3.9 o superior:

Plataforma	Etiqueta de plataforma de la wheel
Linux x86_64 (glibc 2.17+)	`manylinux_2_17_x86_64`
Linux aarch64 (glibc 2.17+)	`manylinux_2_17_aarch64`
macOS Intel	`macosx_11_0_x86_64`
macOS Apple Silicon	`macosx_11_0_arm64`
Windows x64	`win_amd64`
Windows ARM64	`win_arm64`

Dentro de cada wheel el binario va en el directorio .data/scripts, que la especificación de wheels obliga al instalador a colocar en la ruta de scripts del entorno (bin/ o Scripts/) con el bit de ejecución activado. Eso lo convierte directamente en el comando gitlab-mcp-server. La wheel también incluye un pequeño paquete Python gitlab_mcp_server con dos cometidos: un console script jmrplens-gitlab-mcp-server que cede el control al binario, que es lo que permite a uvx resolver la herramienta por el nombre de la distribución, y python -m gitlab_mcp_server para localizarlo desde código. A partir de la primera release posterior a 3.1.0 cada wheel lleva además el LICENSE del repositorio y THIRD_PARTY_NOTICES bajo .dist-info/licenses/. PyPI tiene todas las releases desde la 2.7.5 hasta la actual, 3.2.0.

Por tanto, tras instalar aparecen dos comandos:

Comando	Qué es
`gitlab-mcp-server`	El binario nativo. Usa este en la configuración del cliente.
`jmrplens-gitlab-mcp-server`	Un envoltorio en Python que ejecuta el binario. Existe para que `uvx` encuentre la herramienta por el nombre de la distribución.

Por qué el nombre lleva prefijo

El nombre sin prefijo gitlab-mcp-server en PyPI es un registro vacío en manos de una cuenta ajena, y hay abierta una solicitud de reclamación PEP 541 sobre él. Hasta que se resuelva, la distribución con el prefijo del autor es la oficial. El paquete importable y el comando nativo ya usan el nombre sin prefijo, así que una configuración de cliente construida sobre gitlab-mcp-server no cambiará cuando se renombre la distribución; solo cambiará el nombre que escribes en uvx, pipx o pip.

Linux necesita glibc

Las wheels de Linux son manylinux_2_17: los binarios son ejecutables independientes de la posición (PIE) que necesitan el cargador dinámico de glibc. En sistemas musl como Alpine, usa en su lugar la imagen de contenedor ghcr.io/jmrplens/gitlab-mcp-server; consulta Docker.

Instalación

Sin instalar nada: uv descarga la wheel a su caché y ejecuta el comando. Los clientes pueden lanzarlo así directamente.

uvx jmrplens-gitlab-mcp-server

pipx install jmrplens-gitlab-mcp-server

pipx crea un entorno aislado para la distribución y enlaza sus aplicaciones en ~/.local/bin, así que ambos comandos quedan en tu PATH.

uv tool install jmrplens-gitlab-mcp-server

pip install jmrplens-gitlab-mcp-server

Instala en el entorno activo; los comandos quedan en la ruta de scripts de ese entorno, así que actívalo (o usa su ruta completa) cuando configures el cliente.

Comprueba la instalación:

gitlab-mcp-server --version
# gitlab-mcp-server 3.2.0 (commit: ...)

Con uvx no queda ningún comando en tu PATH; uvx jmrplens-gitlab-mcp-server --version hace la misma comprobación. 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.

Configura tu cliente

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

{
  "mcpServers": {
    "gitlab": {
      "command": "uvx",
      "args": ["jmrplens-gitlab-mcp-server"],
      "env": { "GITLAB_TOKEN": "glpat-xxxxxxxxxxxxxxxxxxxx" }
    }
  }
}

Tras instalar con pipx, uv tool o pip, usa el comando nativo 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; el servidor lo detecta al arrancar y le sirve las acciones que GitLab acepta con él). 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 con uvx en lugar de seguir la más reciente, nómbrala en el argumento: "jmrplens-gitlab-mcp-server@3.2.0".

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.

Verifica el binario

El comando gitlab-mcp-server que instala una wheel es el binario de la release byte a byte, así que la atestación de procedencia de compilación que GitHub guarda para ese asset de la release (releases posteriores a la 2.7.5) lo verifica directamente con la CLI de GitHub:

# pip, pipx o uv tool install: el comando de tu PATH es el binario
gh attestation verify "$(command -v gitlab-mcp-server)" \
  -R jmrplens/gitlab-mcp-server --signer-workflow jmrplens/gitlab-mcp-server/.github/workflows/release.yml

# uvx: el binario está en la caché de uv, y el paquete dice dónde
gh attestation verify "$(uvx --from jmrplens-gitlab-mcp-server python -c 'import gitlab_mcp_server as m; print(m.find_binary())')" \
  -R jmrplens/gitlab-mcp-server --signer-workflow jmrplens/gitlab-mcp-server/.github/workflows/release.yml

--signer-workflow exige que la atestación venga del workflow de release, porque -R por sí solo acepta una emitida por cualquier workflow del repositorio; añade --source-ref refs/tags/v<versión> para exigir además la release que instalaste. En Windows, (Get-Command gitlab-mcp-server).Source da la ruta para la primera forma. Para un uvx fijado a una versión, nombra la misma versión en --from (jmrplens-gitlab-mcp-server==<versión>). Las ubicaciones de pip, uv tool install y uvx se comprobaron en la 3.1.0 contra el checksums.txt firmado de la release. Las wheels llevan además la atestación de publicación del propio PyPI (PEP 740), visible en la página de cada archivo en PyPI. La firma de la release y el resto de canales se explican en integridad del release.

Actualizar y desinstalar

El servidor nunca comprueba si hay actualizaciones ni reemplaza su propio binario; lo gestiona la herramienta de Python con la que lo instalaste, igual que cada canal gestiona lo que instaló.

uv 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:

uvx jmrplens-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.

pipx upgrade jmrplens-gitlab-mcp-server
pipx uninstall jmrplens-gitlab-mcp-server

uv tool upgrade jmrplens-gitlab-mcp-server
uv tool uninstall jmrplens-gitlab-mcp-server

pip install -U jmrplens-gitlab-mcp-server
pip uninstall jmrplens-gitlab-mcp-server

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

Mantenido por José Manuel Requena PlensGitHub LinkedIn Mastodon Google Scholar Todos los proyectos