Package Version Check
Retorna as versões mais recentes de pacotes, dependências e ferramentas para Python, NPM, Go, Docker, Helm, etc.
Documentação
package-version-check-mcp
Um servidor MCP que retorna as versões estáveis mais recentes dos pacotes que você usa como dependências em diversos ecossistemas, como Python, NPM, Go ou GitHub Actions.
Ele também suporta a consulta das versões mais recentes de quase 1000 ferramentas, como runtimes de desenvolvimento como python, node, dotnet, ferramentas de desenvolvimento como gradle, e várias ferramentas de DevOps como kubectl ou terraform, através da ferramenta mise-en-place.
Por que preciso disso?
Sempre que um agente de codificação de IA gera arquivos que fixam versões de dependências, ele insere versões desatualizadas porque seu treinamento ocorreu há semanas ou meses, e novas versões de dependências foram lançadas desde então. Como desenvolvedor, é irritante ter que corrigir manualmente essas versões desatualizadas.
Este MCP resolve esse problema. Use-o junto com um MCP como Context7 para evitar que seu agente de IA produza código desatualizado.
Recursos
Ecossistemas / ferramentas suportados:
- Ecossistemas de desenvolvimento:
- NPM - Pacotes Node.js do registry.npmjs.org
- PyPI - Pacotes Python do PyPI
- NuGet - Pacotes .NET do NuGet
- Maven / Gradle - Pacotes Java/Kotlin/Scala de repositórios Maven (Maven Central, Google Maven, etc.)
- Go - Módulos Go do proxy.golang.org
- PHP - Pacotes PHP do Packagist (usado pelo Composer)
- Ruby - Gems Ruby do rubygems.org
- Rust - Crates Rust do crates.io
- Swift - Pacotes Swift de repositórios GitHub
- Dart - Pacotes Dart do pub.dev
- Ecossistemas de DevOps:
- Docker - Imagens de contêiner Docker de registries Docker
- Helm - Charts Helm de repositórios ChartMuseum e registries OCI
- GitHub Actions - Actions hospedadas no GitHub.com, retornando sua versão atual, entradas e saídas, e (opcionalmente) todo o README com exemplos de uso
- Terraform Providers e Modules - Providers e Modules do Terraform Registry, OpenTofu Registry ou registries personalizados
- Várias ferramentas como
kubectl,terraform,gradle,maven, etc. suportadas pelo mise-en-place
Uso
Adicionando o MCP ao Seu Agente
Existem três maneiras de disponibilizar este MCP para seu agente de codificação de IA:
Opção 1: Use o Serviço Hospedado (Mais Fácil)
Aponte seu agente para o serviço hospedado gratuito:
https://package-version-check-mcp.onrender.com/mcp
no modo HTTP (streamable).
Esta é a maneira mais rápida de começar. Observe que o serviço hospedado pode ter limites de taxa dos registries de pacotes subjacentes.
Opção 2: Execute com uvx (para uso local)
Use uvx para executar o servidor MCP localmente:
uvx package-version-check-mcp --mode=stdio
Isso instala e executa automaticamente a versão mais recente do PyPI.
Requisitos:
- Você precisa do binário
miseno PATH se quiser chamar as ferramentasget_supported_toolsouget_latest_tool_versions
Opcional, mas recomendado: Defina a variável de ambiente GITHUB_PAT com um Personal Access Token do GitHub (nenhum escopo necessário) para evitar limites de taxa da API do GitHub.
Opção 3: Execute com Docker (para uso local)
Use a imagem Docker pré-construída:
docker run --pull=always --rm -i ghcr.io/mshekow/package-version-check-mcp:latest --mode=stdio
Opcional, mas recomendado: Passe a variável de ambiente GITHUB_PAT usando -e GITHUB_PAT=your_token_here para evitar limites de taxa da API do GitHub.
Configuração de Cache
Para melhorar o desempenho e reduzir chamadas de API aos registries de pacotes, você pode habilitar o cache:
PACKAGE_VERSION_CACHE_ENABLED: Defina comotruepara habilitar o cache (desabilitado por padrão)PACKAGE_VERSION_CACHE_TTL_SECONDS: Duração do cache em segundos (padrão: 3600 / 1 hora)PACKAGE_VERSION_CACHE_MAX_SIZE_MB: Tamanho máximo do cache em MB (padrão: 64)
O cache é um cache TTL (Time-To-Live) em memória. Ele é redefinido quando o servidor MCP reinicia.
Configurando Seu Agente
Depois de adicionar o servidor MCP, você precisa:
-
Habilitar as ferramentas MCP na configuração do seu agente. As ferramentas disponíveis estão documentadas abaixo
-
Incentivar o agente a usar o MCP em seus prompts. A maioria dos LLMs não invoca automaticamente as ferramentas deste MCP sem orientação explícita. Inclua instruções como:
- "Use MCP para obter versões mais recentes"
- "Verifique as versões mais recentes dos pacotes usando as ferramentas MCP"
- "Use get_latest_package_versions para encontrar a versão atual"
Caso você tenha esquecido de adicionar este prompt e seu agente gerou código com versões desatualizadas, você pode simplesmente pedir ao seu agente para atualizar as versões depois (por exemplo, "Atualize as dependências que você acabou de adicionar para a versão mais recente via MCP").
Ferramentas Disponíveis
get_latest_package_versions
Busca as versões mais recentes de pacotes de vários ecossistemas.
Entrada:
packages: Matriz de especificações de pacotes, onde cada item contém:ecosystem(obrigatório): "npm", "pypi", "nuget", "maven_gradle", "go", "php", "rubygems", "rust", "swift", "dart", "docker", "helm", "terraform_provider" ou "terraform_module"package_name(obrigatório): O nome do pacote- Para npm: nome do pacote (ex.: "express")
- Para pypi: nome do pacote (ex.: "requests")
- Para nuget: nome do pacote (ex.: "Newtonsoft.Json")
- Para maven_gradle: formato "[registry:]:" (ex.: "org.springframework:spring-core"). Se o registry for omitido, assume-se Maven Central.
- Para go: Identificador absoluto do módulo (ex.: "github.com/gin-gonic/gin")
- Para php: Nome do pacote no formato "vendor/package" (ex.: "monolog/monolog", "laravel/framework")
- Para rubygems: Nome da gem (ex.: "rails", "devise")
- Para rust: Nome da crate (ex.: "serde", "tokio")
- Para swift: URL do GitHub (ex.: "https://github.com/Alamofire/Alamofire.git" ou "github.com/owner/repo.git"). Apenas github.com é suportado.
- Para dart: Nome do pacote do pub.dev (ex.: "http", "flutter")
- Para docker: nome da imagem totalmente qualificado, incluindo registry e namespace (ex.: "index.docker.io/library/busybox")
- Para helm: URL do ChartMuseum ("https://host/path/chart-name") ou referência OCI ("oci://host/path/chart-name")
- Para terraform_provider: formato "[registry/]/" (ex.: "hashicorp/aws" ou "registry.terraform.io/hashicorp/aws"). Se o registry for omitido, assume-se registry.terraform.io. Suporta registries alternativos como registry.opentofu.org.
- Para terraform_module: formato "[registry/]//" (ex.: "terraform-aws-modules/vpc/aws" ou "registry.terraform.io/terraform-aws-modules/vpc/aws"). Se o registry for omitido, assume-se registry.terraform.io. Suporta registries alternativos como registry.opentofu.org.
version_hint(opcional):- Para docker: dica de compatibilidade de tag (ex.: "1.36-alpine") para encontrar a tag mais recente que corresponda ao mesmo padrão de sufixo. Se omitido, retorna a tag de versão semântica mais recente.
- Para helm (somente OCI): dica de compatibilidade de tag semelhante ao Docker
- Para npm/pypi/nuget/maven_gradle/go/php/rubygems/rust/swift/dart/helm (ChartMuseum)/terraform_provider/terraform_module: não usado atualmente
Saída:
result: Matriz de consultas bem-sucedidas com:ecosystem: O ecossistema do pacote (como fornecido)package_name: O nome do pacote (como fornecido)latest_version: O número da versão mais recente (ex.: "1.2.4") ou tag Dockerdigest: (opcional) Digest/hash do pacote, se disponível. Para Docker, é o digest do manifesto (sha256).published_on: (opcional) Data de publicação, se disponível (não disponível para Docker)
lookup_errors: Matriz de erros com:ecosystem: O ecossistema do pacote (como fornecido)package_name: O nome do pacote (como fornecido)error: Descrição do erro
get_github_action_versions_and_args
Busca as versões mais recentes e metadados de GitHub Actions hospedadas no github.com.
Entrada:
action_names(obrigatório): Matriz de nomes de actions no formato "owner/repo" (ex.: ["actions/checkout", "docker/login-action"])include_readme(opcional): Booleano (padrão: false), se deve incluir o README.md da action com instruções de uso
Saída:
result: Matriz de consultas bem-sucedidas com:name: O nome da action (como fornecido)latest_version: A tag Git mais recente (ex.: "v3.2.4")metadata: Os metadados do action.yml como um objeto com campos:inputs: Parâmetros de entrada da actionoutputs: Saídas da actionruns: Configuração de execução
readme: (opcional) O conteúdo do README da action seinclude_readmefor true
lookup_errors: Matriz de erros com:name: O nome da action (como fornecido)error: Descrição do erro
get_supported_tools
Retorna uma lista de todos os nomes de ferramentas suportados pela ferramenta MCP get_latest_tool_versions.
Esta ferramenta consulta o registry mise para recuperar todos os nomes de ferramentas disponíveis que podem ser gerenciados pelo mise.
Entrada:
- Nenhum parâmetro necessário
Saída:
- Matriz de nomes curtos de ferramentas (ex.: ["1password", "act", "node", "python", ...])
get_latest_tool_versions
Busca as versões estáveis mais recentes de ferramentas de desenvolvimento e DevOps suportadas pelo mise-en-place.
Esta ferramenta é para ferramentas que NÃO fazem parte de ecossistemas de linguagem como PyPI ou NPM. Para pacotes de ecossistemas de linguagem (incluindo providers e modules Terraform), use get_latest_package_versions.
Casos de uso:
- gradle ou maven: Fixe a versão do Gradle ou Maven no
distributionUrlemgradle-wrapper.propertiesoumaven-wrapper.properties- Exemplo:
distributionUrl=https://services.gradle.org/distributions/gradle-8.5-bin.zip - Exemplo:
distributionUrl=https://repo.maven.apache.org/.../apache-maven-3.9.6-bin.zip
- Exemplo:
- terraform: Fixe
terraform.required_versionem um arquivo comoversion.tfouversions.tf- Exemplo:
terraform { required_version = "~> 1.6.0" }
- Exemplo:
- kubectl ou azure: Fixe a versão em uma URL de download chamada com
curlouwget, ex.: em um Dockerfile- Exemplo:
RUN curl -LO https://dl.k8s.io/release/v1.28.0/bin/linux/amd64/kubectl
- Exemplo:
Para ver todas as ferramentas disponíveis, use a ferramenta get_supported_tools.
Entrada:
tool_names(obrigatório): Matriz de nomes de ferramentas (ex.: ["terraform", "gradle", "kubectl"])
Saída:
result: Matriz de consultas bem-sucedidas com:tool_name: O nome da ferramenta (como fornecido)latest_version: O número da versão estável mais recente (ex.: "1.6.5")
lookup_errors: Matriz de erros com:tool_name: O nome da ferramenta (como fornecido)error: Descrição do erro
Por que criar mais um MCP
Este MCP certamente não é o primeiro a abordar o problema de "dependências desatualizadas". No entanto, acreditamos que ele tem várias vantagens sobre outros MCPs:
- Oferecemos cobertura de ecossistemas (muito) melhor do que outros MCPs
- Há cobertura completa de testes, com atualizações automatizadas de dependências (alimentadas pelo Renovate) e builds de lançamento regulares e automatizados. Em contraste, outros projetos são frequentemente "vibe coded", têm testes ruins (ou nenhum) e já estão abandonados, porque os autores estavam apenas brincando
- Este MCP fornece várias alternativas para executá-lo localmente (uvx ou docker), ou você pode simplesmente usar a oferta hospedada gratuita (que outros MCPs não têm)
- Este MCP usa uma imagem Docker/OCI mínima, endurecida para segurança. SBOMs que você gera com ferramentas como Trivy são conhecidos por estarem corretos, e a imagem é assinada com Cosign (o que permite verificar sua autenticidade caso queira auto-hospedar o MCP)
Desenvolvimento
Pré-requisitos
mise-en-place
O servidor MCP depende do pacote mise-en-place para consultar versões de ferramentas. Veja https://mise.jdx.dev/installing-mise.html para instruções de instalação.
Executando o Servidor Manualmente (Para Desenvolvimento)
Se você está desenvolvendo ou testando o servidor MCP localmente, pode executá-lo diretamente.
Primeiro, siga as instruções de Gerenciamento de pacotes com Poetry -> Configuração para configurar seus ambientes virtuais.
Em seguida:
.poetry/bin/poetry run python -m package_version_check_mcp.main
Ou se você tiver o .venv ativado:
python src/package_version_check_mcp/main.py
Gerenciamento de pacotes com Poetry
Configuração
Em uma nova máquina, crie um venv para o Poetry (no caminho <project-root>/.poetry) e um para o próprio projeto (no caminho <project-root>/.venv), ex.: via C:\Users\USER\AppData\Local\Programs\Python\Python312\python.exe -m venv <path>.
Essa separação é necessária para evitar conflitos de dependências entre o projeto e o Poetry.
Usando o pip do venv do Poetry, instale o Poetry via pip install -r requirements-poetry.txt
Em seguida, execute poetry sync --all-extras, mas certifique-se de que nenhum venv esteja ativo, ou o venv .venv, mas não o .poetry (caso contrário, o Poetry instalaria estupidamente as dependências nesse venv, a menos que você tenha executado poetry config virtualenvs.in-project true anteriormente). A flag --all-extras é necessária para instalar dependências de desenvolvimento, como pytest.
Atualizando dependências
- Quando as dependências mudam externamente, por exemplo, porque o Renovate atualizou o arquivo
pyproject.tomlepoetry.lock, executepoetry sync --all-extraspara atualizar seu ambiente local. Isso remove quaisquer dependências obsoletas do seu venv.venv. - Se você atualizou uma dependência em
pyproject.toml, executepoetry update && poetry sync --all-extraspara atualizar o arquivo de bloqueio e instalar as dependências atualizadas, incluindo extras. - Para atualizar apenas as dependências transitivas (mantendo as de
pyproject.tomlas mesmas), executepoetry update && poetry sync --all-extras, que atualiza o arquivo de bloqueio e instala as atualizações no venv ativo.
Certifique-se de que nenhum venv esteja ativo (ou o venv .venv esteja ativo) ao executar qualquer um dos comandos poetry acima.