NuGet y dnx

GitLab MCP Server está publicado en NuGet.org como gitlab-mcp-server. Es una herramienta .NET con la disposición que el SDK de .NET 10 introdujo para las herramientas que distribuyen un ejecutable específico de cada plataforma: el punto de entrada es el mismo binario nativo en Go que distribuyen todos los demás canales, dotnet tool install y dnx eligen el paquete de tu sistema operativo y arquitectura, y no se ejecuta código .NET una vez arranca el servidor.

Qué obtienes

Siete paquetes, publicados juntos en cada release, cada uno con una atestación de procedencia de compilación SLSA hecha antes de subirlo (desde la primera release posterior a la 3.1.0):

gitlab-mcp-server es el paquete puntero. Declara el comando gitlab-mcp-server y nombra, para cada identificador de runtime, el paquete que lo lleva. También contiene el README del paquete y un .mcp/server.json, que es de donde NuGet.org genera su fragmento de instalación.
gitlab-mcp-server.<rid> son los paquetes que llevan el binario en sí, uno por identificador de runtime: linux-x64, linux-arm64, osx-x64, osx-arm64, win-x64 y win-arm64. El SDK instala exactamente uno, el que corresponde a tu máquina, y ejecuta el binario directamente (Runner="executable" en el manifiesto de la herramienta, así que no hay ningún host de .NET por medio).

Plataforma	Identificador de runtime
Linux x64 (glibc)	`linux-x64`
Linux arm64 (glibc)	`linux-arm64`
macOS Intel	`osx-x64`
macOS Apple Silicon	`osx-arm64`
Windows x64	`win-x64`
Windows ARM64	`win-arm64`

Requisitos: el SDK de .NET 10 o superior. La disposición por identificador de runtime es la versión 2 del manifiesto de herramientas, que los SDK anteriores no leen, y el propio dnx llegó con .NET 10. En Linux los binarios necesitan glibc; en sistemas musl como Alpine, usa en su lugar la imagen Docker.

Sin instalar nada: dnx descarga los dos paquetes a la caché de NuGet en la primera ejecución y ejecuta la herramienta. Los clientes pueden lanzarlo así directamente.

dnx gitlab-mcp-server

Dos cosas de dnx con las que es fácil tropezar:

Interpreta sus propias opciones en cualquier posición de la línea. Los argumentos destinados al servidor van después de --: dnx gitlab-mcp-server -- --version imprime la versión del servidor, mientras que dnx gitlab-mcp-server --version se lee como la opción --version <VERSION> del propio dnx e imprime su ayuda.
No pregunta nada cuando su entrada estándar no es una terminal. La documentación de Microsoft muestra dnx <paquete> --yes para saltarse la pregunta “¿descargar esta herramienta?”; un cliente MCP conecta tuberías, así que la pregunta nunca aparece y el flag es innecesario (los SDK de .NET 10.0.400 y 10.0.401 lo aceptan de todos modos, así que una plantilla de cliente que lo añada no hace daño). En una terminal, la primera ejecución pregunta una vez.

dotnet tool install -g gitlab-mcp-server

El SDK deja un shim gitlab-mcp-server en ~/.dotnet/tools (un enlace simbólico al almacén de herramientas en Linux y macOS), directorio que el instalador del SDK ya puso en tu PATH.

Comprueba la instalación:

gitlab-mcp-server --version
# gitlab-mcp-server <versión> (commit: ...)

Con dnx no queda ningún comando en tu PATH; dnx 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 dnx:

{
  "mcpServers": {
    "gitlab": {
      "command": "dnx",
      "args": ["gitlab-mcp-server"],
      "env": {
        "GITLAB_URL": "https://gitlab.com",
        "GITLAB_TOKEN": "glpat-xxxxxxxxxxxxxxxxxxxx"
      }
    }
  }
}

Tras dotnet tool install -g, 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; el servidor lo detecta al arrancar y sirve una superficie de solo lectura). 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 dnx en lugar de seguir la más reciente, nómbrala en el argumento: "gitlab-mcp-server@<versión>", con una versión que NuGet.org liste. Fijarla no permite a dnx arrancar sin NuGet.org (ver Actualizar y desinstalar).

Una precaución para una máquina en la que la CLI de .NET nunca se ha ejecutado: su texto de bienvenida del primer uso sale por la salida estándar, que es el flujo por el que va el protocolo MCP. Ejecuta dotnet --version una vez en una terminal antes del primer arranque desde el cliente, o añade "DOTNET_NOLOGO": "1" al bloque env.

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 lo que ejecutas

El binario que ejecuta el SDK es el asset de la release byte a byte, así que la atestación de procedencia de compilación que GitHub guarda para ese asset lo verifica con la CLI de GitHub, lo hayas instalado como lo hayas instalado:

# dnx: la caché de paquetes de NuGet (<rid> y <versión> como en la tabla de arriba)
gh attestation verify ~/.nuget/packages/gitlab-mcp-server.<rid>/<versión>/tools/any/<rid>/gitlab-mcp-server \
  -R jmrplens/gitlab-mcp-server --signer-workflow jmrplens/gitlab-mcp-server/.github/workflows/release.yml

# dotnet tool install -g: en Linux y macOS el shim enlaza con el almacén de herramientas
gh attestation verify "$(readlink -f "$(command -v gitlab-mcp-server)")" \
  -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 ejecutas.

En Windows la caché está bajo %USERPROFILE%\.nuget\packages y el archivo es gitlab-mcp-server.exe. dnx gitlab-mcp-server -- --version imprime la versión que ejecutas. Las dos rutas se comprobaron en la 3.1.0 contra el checksums.txt firmado de la release.

Desde la primera release posterior a la 3.1.0 también están atestados los siete paquetes, tal como eran antes de que NuGet.org añadiera la firma de repositorio (.signature.p7s) que pone en todo paquete que sirve. Quita esa entrada de una copia descargada y verifica lo que queda:

v=<versión>
curl -sSLO "https://api.nuget.org/v3-flatcontainer/gitlab-mcp-server/$v/gitlab-mcp-server.$v.nupkg"
zip -q -d "gitlab-mcp-server.$v.nupkg" .signature.p7s
gh attestation verify "gitlab-mcp-server.$v.nupkg" -R jmrplens/gitlab-mcp-server \
  --signer-workflow jmrplens/gitlab-mcp-server/.github/workflows/release.yml --source-ref "refs/tags/v$v"

Lo mismo vale para cada paquete gitlab-mcp-server.<rid>. El zip -d de Info-ZIP (zip 3.0) deja cada uno de los demás bytes donde estaba, que es la definición del propio NuGet del paquete sin firmar: en los siete paquetes de la 3.1.0 devuelve exactamente lo que produce una recompilación desde la etiqueta. Una herramienta que reescribe el archivo da otros bytes, y gh entonces no encuentra nada. Recompilar desde la etiqueta con scripts/build_nuget.py y los binarios firmados coincide byte a byte solo con un Python enlazado contra la zlib de siempre: zlib-ng, que es lo que es zlib en Fedora 40 y posteriores, comprime la misma entrada en bytes distintos, así que allí una recompilación difiere sin decir nada de los paquetes publicados.

Actualizar y desinstalar

El servidor nunca comprueba si hay actualizaciones ni reemplaza su propio binario; aquí lo gestiona el SDK, igual que cada canal gestiona lo que instaló. Cada release mueve el puntero y sus seis paquetes de runtime juntos a una misma versión, así que un puntero nunca resuelve un binario de otra release.

dnx
dotnet tool

dnx resuelve la versión contra NuGet.org en cada arranque, así que un dnx gitlab-mcp-server sin versión sigue cada release según se publica, y la descarga se omite cuando la versión resuelta ya está en la caché de NuGet. Para quedarte en una release, nómbrala: dnx gitlab-mcp-server@<versión> (@latest no es una versión de NuGet y se rechaza). La otra cara de la moneda: cada arranque contacta con NuGet.org, con versión fijada o sin ella, en caché o no. Medido con el SDK 10.0.401, con la 3.1.0 ya en la caché y sin red, tanto dnx gitlab-mcp-server@3.1.0 como dnx gitlab-mcp-server terminan con Resource temporarily unavailable (api.nuget.org:443), mientras que el comando que dejó dotnet tool install -g arranca. A una máquina que a veces está sin conexión, o a un host que no llega a NuGet.org en absoluto, le sirve dotnet tool install (con --source <directorio> apuntando a los paquetes descargados donde el feed no está al alcance).

No se instaló nada, así que no hay nada que desinstalar más allá de la entrada en la configuración de tu cliente (y los paquetes en caché bajo ~/.nuget, si quieres eliminarlos).

dotnet tool update -g gitlab-mcp-server
dotnet tool uninstall -g 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