Package Version Check

Devuelve las últimas versiones de paquetes, dependencias y herramientas para Python, NPM, Go, Docker, Helm, etc.

GitHub
8
Prueba este MCPPatrocinado

Documentación

package-version-check-mcp

Un servidor MCP que devuelve las versiones estables más recientes de los paquetes que usas como dependencias en una variedad de ecosistemas, como Python, NPM, Go o GitHub Actions.

También admite la búsqueda de las versiones más recientes de casi 1000 herramientas, como runtimes de desarrollo como python, node, dotnet, herramientas de desarrollo como gradle, y varias herramientas de DevOps como kubectl o terraform, a través de la herramienta mise-en-place.

¿Por qué necesito esto?

Cada vez que un agente de codificación de IA genera archivos que fijan versiones de dependencias, inserta versiones desactualizadas porque su entrenamiento ocurrió hace semanas o meses, y desde entonces se han lanzado nuevas versiones de dependencias. Como desarrollador, es molesto tener que corregir manualmente estas versiones desactualizadas.

Este MCP soluciona este problema. Úsalo junto con un MCP como Context7 para evitar que tu agente de IA genere código desactualizado.

Características

Ecosistemas / herramientas compatibles:

  • Ecosistemas de desarrollo:
    • NPM - paquetes de Node.js de registry.npmjs.org
    • PyPI - paquetes de Python de PyPI
    • NuGet - paquetes de .NET de NuGet
    • Maven / Gradle - paquetes de Java/Kotlin/Scala de repositorios Maven (Maven Central, Google Maven, etc.)
    • Go - módulos de Go de proxy.golang.org
    • PHP - paquetes de PHP de Packagist (usado por Composer)
    • Ruby - gemas de Ruby de rubygems.org
    • Rust - crates de Rust de crates.io
    • Swift - paquetes de Swift de repositorios de GitHub
    • Dart - paquetes de Dart de pub.dev
  • Ecosistemas de DevOps:
    • Docker - imágenes de contenedores Docker de registros Docker
    • Helm - charts de Helm de repositorios ChartMuseum y registros OCI
    • GitHub Actions - Actions alojadas en GitHub.com, que devuelven su versión actual, sus entradas y salidas, y (opcionalmente) su README completo con ejemplos de uso
    • Terraform Providers y Modules - Providers y Modules de Terraform Registry, OpenTofu Registry o registros personalizados
    • Varias herramientas como kubectl, terraform, gradle, maven, etc. compatibles con mise-en-place

Uso

Añadir el MCP a tu agente

Hay tres formas de hacer que este MCP esté disponible para tu agente de codificación de IA:

Opción 1: Usar el servicio alojado (la más fácil)

Apunta tu agente al servicio alojado gratuito:

https://package-version-check-mcp.onrender.com/mcp

en modo HTTP (transmisible).

Esta es la forma más rápida de empezar. Ten en cuenta que el servicio alojado puede tener límites de tasa de los registros de paquetes subyacentes.

Opción 2: Ejecutar con uvx (para uso local)

Usa uvx para ejecutar el servidor MCP localmente:

uvx package-version-check-mcp --mode=stdio

Esto instala y ejecuta automáticamente la última versión desde PyPI.

Requisitos:

  • Necesitas el binario mise en PATH si quieres llamar a las herramientas get_supported_tools o get_latest_tool_versions

Opcional pero recomendado: Establece la variable de entorno GITHUB_PAT a un token de acceso personal de GitHub (no se requieren alcances) para evitar los límites de tasa de la API de GitHub.

Opción 3: Ejecutar con Docker (para uso local)

Usa la imagen Docker preconstruida:

docker run --pull=always --rm -i ghcr.io/mshekow/package-version-check-mcp:latest --mode=stdio

Opcional pero recomendado: Pasa la variable de entorno GITHUB_PAT usando -e GITHUB_PAT=your_token_here para evitar los límites de tasa de la API de GitHub.

Configuración de caché

Para mejorar el rendimiento y reducir las llamadas API a los registros de paquetes, puedes habilitar el caché:

  • PACKAGE_VERSION_CACHE_ENABLED: Establécelo a true para habilitar el caché (deshabilitado por defecto)
  • PACKAGE_VERSION_CACHE_TTL_SECONDS: Duración del caché en segundos (por defecto: 3600 / 1 hora)
  • PACKAGE_VERSION_CACHE_MAX_SIZE_MB: Tamaño máximo de caché en MB (por defecto: 64)

El caché es un caché TTL (Time-To-Live) en memoria. Se restablece cuando se reinicia el servidor MCP.

Configurando tu agente

Una vez que hayas añadido el servidor MCP, necesitas:

  1. Habilitar las herramientas MCP en la configuración de tu agente. Las herramientas disponibles están documentadas a continuación

  2. Incentiva al agente a usar el MCP en tus indicaciones. La mayoría de los LLM no invocan automáticamente las herramientas de este MCP sin una guía explícita. Incluye instrucciones como:

    • "Usa MCP para obtener las últimas versiones"
    • "Comprueba las últimas versiones de paquetes usando las herramientas MCP"
    • "Usa get_latest_package_versions para encontrar la versión actual"

En caso de que olvidaras añadir esta indicación y tu agente generara código con versiones desactualizadas, puedes simplemente pedirle a tu agente que actualice las versiones después (por ejemplo, "Actualiza las dependencias que acabas de añadir a la última versión mediante MCP").

Herramientas disponibles

get_latest_package_versions

Obtiene las últimas versiones de paquetes de varios ecosistemas.

Entrada:

  • packages: Matriz de especificaciones de paquetes, donde cada elemento contiene:
    • ecosystem (obligatorio): Ya sea "npm", "pypi", "nuget", "maven_gradle", "go", "php", "rubygems", "rust", "swift", "dart", "docker", "helm", "terraform_provider" o "terraform_module"
    • package_name (obligatorio): El nombre del paquete
      • Para npm: nombre del paquete (por ejemplo, "express")
      • Para pypi: nombre del paquete (por ejemplo, "requests")
      • Para nuget: nombre del paquete (por ejemplo, "Newtonsoft.Json")
      • Para maven_gradle: formato "[registry:]:" (por ejemplo, "org.springframework:spring-core"). Si se omite el registro, se asume Maven Central.
      • Para go: identificador de módulo absoluto (por ejemplo, "github.com/gin-gonic/gin")
      • Para php: nombre del paquete en formato "vendor/package" (por ejemplo, "monolog/monolog", "laravel/framework")
      • Para rubygems: nombre de la gema (por ejemplo, "rails", "devise")
      • Para rust: nombre del crate (por ejemplo, "serde", "tokio")
      • Para swift: URL de GitHub (por ejemplo, "https://github.com/Alamofire/Alamofire.git" o "github.com/owner/repo.git"). Solo se admite github.com.
      • Para dart: nombre del paquete de pub.dev (por ejemplo, "http", "flutter")
      • Para docker: nombre de imagen completamente calificado, incluidos registro y espacio de nombres (por ejemplo, "index.docker.io/library/busybox")
      • Para helm: ya sea URL de ChartMuseum ("https://host/path/chart-name") o referencia OCI ("oci://host/path/chart-name")
      • Para terraform_provider: formato "[registry/]/" (por ejemplo, "hashicorp/aws" o "registry.terraform.io/hashicorp/aws"). Si se omite el registro, se asume registry.terraform.io. Admite registros alternativos como registry.opentofu.org.
      • Para terraform_module: formato "[registry/]//" (por ejemplo, "terraform-aws-modules/vpc/aws" o "registry.terraform.io/terraform-aws-modules/vpc/aws"). Si se omite el registro, se asume registry.terraform.io. Admite registros alternativos como registry.opentofu.org.
    • version_hint (opcional):
      • Para docker: sugerencia de compatibilidad de etiqueta (por ejemplo, "1.36-alpine") para encontrar la última etiqueta que coincida con el mismo patrón de sufijo. Si se omite, devuelve la última etiqueta de versión semántica.
      • Para helm (solo OCI): sugerencia de compatibilidad de etiqueta similar a Docker
      • Para npm/pypi/nuget/maven_gradle/go/php/rubygems/rust/swift/dart/helm (ChartMuseum)/terraform_provider/terraform_module: no se usa actualmente

Salida:

  • result: Matriz de búsquedas exitosas con:
    • ecosystem: El ecosistema del paquete (tal como se proporcionó)
    • package_name: El nombre del paquete (tal como se proporcionó)
    • latest_version: El número de versión más reciente (por ejemplo, "1.2.4") o etiqueta de Docker
    • digest: (opcional) Resumen/hash del paquete si está disponible. Para Docker, este es el resumen del manifiesto (sha256).
    • published_on: (opcional) Fecha de publicación si está disponible (no disponible para Docker)
  • lookup_errors: Matriz de errores con:
    • ecosystem: El ecosistema del paquete (tal como se proporcionó)
    • package_name: El nombre del paquete (tal como se proporcionó)
    • error: Descripción del error

get_github_action_versions_and_args

Obtiene las últimas versiones y metadatos de GitHub Actions alojadas en github.com.

Entrada:

  • action_names (obligatorio): Matriz de nombres de acciones en formato "owner/repo" (por ejemplo, ["actions/checkout", "docker/login-action"])
  • include_readme (opcional): Booleano (por defecto: false), si se debe incluir el README.md de la acción con instrucciones de uso

Salida:

  • result: Matriz de búsquedas exitosas con:
    • name: El nombre de la acción (tal como se proporcionó)
    • latest_version: La etiqueta Git más reciente (por ejemplo, "v3.2.4")
    • metadata: Los metadatos de action.yml como un objeto con campos:
      • inputs: Parámetros de entrada de la acción
      • outputs: Salidas de la acción
      • runs: Configuración de ejecución
    • readme: (opcional) El contenido del README de la acción si include_readme era verdadero
  • lookup_errors: Matriz de errores con:
    • name: El nombre de la acción (tal como se proporcionó)
    • error: Descripción del error

get_supported_tools

Devuelve una lista de todos los nombres de herramientas compatibles con la herramienta MCP get_latest_tool_versions.

Esta herramienta consulta el registro mise para recuperar todos los nombres de herramientas disponibles que pueden ser gestionados por mise.

Entrada:

  • No se requieren parámetros

Salida:

  • Matriz de nombres cortos de herramientas (por ejemplo, ["1password", "act", "node", "python", ...])

get_latest_tool_versions

Obtiene las últimas versiones estables de herramientas de desarrollo y DevOps compatibles con mise-en-place.

Esta herramienta es para herramientas que NO forman parte de ecosistemas de lenguajes como PyPI o NPM. Para paquetes de ecosistemas de lenguajes (incluidos providers y modules de Terraform), usa get_latest_package_versions en su lugar.

Casos de uso:

  • gradle o maven: Fija la versión de Gradle o Maven en el distributionUrl en gradle-wrapper.properties o maven-wrapper.properties
    • Ejemplo: distributionUrl=https://services.gradle.org/distributions/gradle-8.5-bin.zip
    • Ejemplo: distributionUrl=https://repo.maven.apache.org/.../apache-maven-3.9.6-bin.zip
  • terraform: Fija terraform.required_version en un archivo como version.tf o versions.tf
    • Ejemplo: terraform { required_version = "~> 1.6.0" }
  • kubectl o azure: Fija la versión en una URL de descarga llamada con curl o wget, por ejemplo, en un Dockerfile
    • Ejemplo: RUN curl -LO https://dl.k8s.io/release/v1.28.0/bin/linux/amd64/kubectl

Para ver todas las herramientas disponibles, usa la herramienta get_supported_tools.

Entrada:

  • tool_names (obligatorio): Matriz de nombres de herramientas (por ejemplo, ["terraform", "gradle", "kubectl"])

Salida:

  • result: Matriz de búsquedas exitosas con:
    • tool_name: El nombre de la herramienta (tal como se proporcionó)
    • latest_version: El número de versión estable más reciente (por ejemplo, "1.6.5")
  • lookup_errors: Matriz de errores con:
    • tool_name: El nombre de la herramienta (tal como se proporcionó)
    • error: Descripción del error

¿Por qué construir otro MCP?

Este MCP ciertamente no es el primero en abordar el problema de las "dependencias desactualizadas". Sin embargo, creemos que tiene varias ventajas sobre otros MCP:

  • Ofrecemos una cobertura de ecosistemas (mucho) mejor que otros MCP
  • Hay una cobertura de pruebas completa, con actualizaciones automáticas de dependencias (impulsadas por Renovate) y compilaciones de lanzamiento regulares y automatizadas. En contraste, otros proyectos a menudo están codificados al azar, tienen pruebas deficientes (o ninguna) y ya están abandonados, porque los autores solo estaban jugando
  • Este MCP proporciona varias alternativas para ejecutarlo localmente (uvx o docker), o puedes simplemente usar la oferta alojada gratuita (que otros MCP no tienen)
  • Este MCP utiliza una imagen Docker/OCI mínima, endurecida para la seguridad. Los SBOM que generes con herramientas como Trivy se sabe que son correctos, y la imagen está firmada con Cosign (lo que te permite verificar su autenticidad en caso de que quieras autoalojar el MCP)

Desarrollo

Requisitos previos

mise-en-place

El servidor MCP depende del paquete mise-en-place para buscar versiones de herramientas. Consulta https://mise.jdx.dev/installing-mise.html para obtener instrucciones de instalación.

Ejecutar el servidor manualmente (para desarrollo)

Si estás desarrollando o probando el servidor MCP localmente, puedes ejecutarlo directamente.

Primero, sigue las instrucciones de Gestión de paquetes con Poetry -> Configuración para configurar tus entornos virtuales.

A continuación:

.poetry/bin/poetry run python -m package_version_check_mcp.main

O si tienes el .venv activado:

python src/package_version_check_mcp/main.py

Gestión de paquetes con Poetry

Configuración

En una máquina nueva, crea un venv para Poetry (en la ruta <project-root>/.poetry) y otro para el proyecto en sí (en la ruta <project-root>/.venv), por ejemplo, mediante C:\Users\USER\AppData\Local\Programs\Python\Python312\python.exe -m venv <path>.

Esta separación es necesaria para evitar conflictos de dependencias entre el proyecto y Poetry. Usando el pip del venv de Poetry, instala Poetry mediante pip install -r requirements-poetry.txt

Luego, ejecuta poetry sync --all-extras, pero asegúrate de que no haya ningún venv activo, o que esté activo el de .venv, pero no el de .poetry (de lo contrario, Poetry instalaría tontamente las dependencias en ese, a menos que hayas ejecutado previamente poetry config virtualenvs.in-project true). La bandera --all-extras es necesaria para instalar dependencias de desarrollo, como pytest.

Actualización de dependencias

  • Cuando las dependencias cambian desde el exterior, por ejemplo, porque Renovate actualizó el archivo pyproject.toml y poetry.lock, ejecuta poetry sync --all-extras para actualizar tu entorno local. Esto elimina cualquier dependencia obsoleta de tu venv .venv.
  • Si tú actualizaste una dependencia en pyproject.toml, ejecuta poetry update && poetry sync --all-extras para actualizar el archivo de bloqueo e instalar las dependencias actualizadas, incluyendo los extras.
  • Para actualizar solo las dependencias transitivas (manteniendo las de pyproject.toml iguales), ejecuta poetry update && poetry sync --all-extras, que actualiza el archivo de bloqueo e instala las actualizaciones en el venv activo.

Asegúrate de que no haya ningún venv activo (o que el venv de .venv esté activo) al ejecutar cualquiera de los comandos poetry anteriores.