Quatro pacotes MCP, quatro maneiras como a cadeia de suprimentos mudou em duas semanas de monitoramento do npm

Por Michael K Onyekwere

Eu monitoro quase mil pacotes MCP publicados no npm em tempo real. O pipeline consulta o feed de mudanças do npm a cada dois minutos, escaneia cada nova versão publicada e registra o resultado em relação à linha de base anterior. Quando uma atualização real de pacote faz a pontuação cair abaixo do limite de confiança, um aviso público é gerado e o feed RSS é atualizado.

Este post reúne quatro exemplos práticos das últimas duas semanas. Os pacotes nomeados não são maliciosos. O objetivo é tornar visíveis os tipos de mudanças rotineiras que um consumidor nunca veria no momento da instalação, porque o caminho de instalação é npx -y <package> ou um npm install equivalente não fixado que sempre puxa a versão atual do registro.

1. prism-mcp-server: quatro capacidades adicionadas em um grande aumento de versão

Este é o evento de desvio mais forte do período.

Em 2026-04-27, o feed de monitoramento tinha prism-mcp-server na versão 11.6.0 com pontuação 85 / 100, risco BAIXO, sem descobertas além de uma nota de falta de proveniência.

Em 2026-04-28 às 11:44 UTC, o mesmo pacote foi republicado como versão 12.5.0. O monitoramento registrou a diferença sob dois segundos depois. A nova varredura produziu:

• Pontuação de 85 para 65, risco de BAIXO para ELEVADO
• Nova descoberta ALTA command_injection: execução de shell com entrada de literal de template
• Nova descoberta MÉDIA excessive_dependencies: 23 dependências em tempo de execução (era menor na v11)
• Superfície de capacidade ganhou quatro categorias que não existiam na versão principal anterior:
  • browser_automation
  • email_messaging
  • filesystem_read
  • shell_exec

Considere a posição do consumidor. Qualquer um com prism-mcp-server instalado via a forma típica de configuração de agente (npx -y prism-mcp-server em claude_desktop_config.json ou equivalente) teve seu agente silenciosamente herdando quatro novas categorias de capacidade no momento em que 12.5.0 chegou ao npm. Nenhum gatilho de revisão. Nenhum opt-in. Nenhuma diferença em relação ao que foi previamente autorizado.

Esta não é uma história sobre o editor do prism-mcp-server fazendo algo errado. Aumentos de versão principais são exatamente quando um mantenedor pode remodelar a área de superfície. O ponto é que o consumidor não tem um mecanismo em vigor para notar isso.

O aviso AGENTSCORE-2026-0017 cobre este caso. O feed RSS o capturou no mesmo minuto.

2. agent-planner-mcp: quatro versões em nove horas

Uma forma diferente do mesmo problema.

Em 2026-04-25, agent-planner-mcp foi publicado quatro vezes em um único dia:

• 13:44 UTC: v0.8.1
• 18:10 UTC: v0.9.0
• 19:14 UTC: v0.9.1
• 22:44 UTC: v1.0.0

A pontuação se manteve em 75 / MODERADO em todas as quatro publicações. Nenhuma mudança significativa nas descobertas. Mas cada lançamento alterou quais ferramentas o pacote expôs.

Se você revisou v0.8.1 pela manhã e estava satisfeito com o que tinha, ao final do dia houve três mudanças adicionais na superfície que você nunca viu, e o pacote havia cruzado um limite de versão principal (v1.0.0). Uma instalação npx -y em uma ferramenta que depende de agent-planner-mcp cairia na versão que estava atual no momento da instalação, sem nenhuma maneira de relacionar essa versão com a que foi revisada.

Este é o mesmo padrão observado anteriormente no período com @planu/cli, que em 2026-04-22 lançou v1.84.0 com quatro novas capacidades (database_access, filesystem_read, search_index, unknown) e uma descoberta ALTA command_injection, e então reverteu a mudança na v1.85.0 quarenta e seis minutos depois, removendo todas as quatro capacidades. Um consumidor executando npx -y @planu/cli durante aquela janela de quarenta e seis minutos teria obtido a superfície expandida; um que o executasse quarenta e sete minutos depois teria obtido a versão revertida. Nenhum dos dois sabia.

Duas instâncias em duas semanas descartam coincidência. Mantenedores iterando em tempo real é normal e saudável. Consumidores sem visão da iteração é a lacuna.

3. sverklo: um pacote silencioso, depois um lançamento de despejo de backlog que abre um novo ALTO

sverklo estava na v0.12.5 com pontuação 80 / MODERADO desde 2026-04-19, carregando uma descoberta ALTA command_injection por quase uma semana.

Em 2026-04-25 às 20:56 UTC, o pacote publicou v0.16.0. Quatro versões menores de uma só vez, o tipo de lançamento que sinaliza um mantenedor limpando um backlog. A diferença:

• Pontuação de 80 para 60 (MODERADO para ELEVADO)
• A descoberta ALTA command_injection ainda está presente
• Uma nova descoberta ALTA unsafe_eval apareceu

Agora, duas descobertas ALTA, onde antes havia uma, no mesmo pacote, após um único lançamento.

Isso inverte uma suposição comum. A atividade do mantenedor é geralmente tratada como um sinal positivo nas heurísticas de revisão do npm: mantido ativamente é melhor do que abandonado. No MCP especificamente, um longo backlog liberado como uma grande publicação de salto de versão expande a superfície contra a qual um consumidor estava revisando. Quanto maior a lacuna, maior a mudança na publicação de recuperação.

Se sua revisão de sverklo foi baseada na v0.12.5, sua revisão agora está desatualizada por duas descobertas ALTA.

4. nodebench-mcp: o caso em que o mantenedor reagiu, e o scanner melhorou

Uma forma diferente das três acima. Esta mostra como é o ciclo de feedback quando funciona.

O scanner sinalizou nodebench-mcp v3.2.0 com duas descobertas ALTA: command_injection e unsafe_eval. Eu registrei uma questão pública no repositório do mantenedor.

O mantenedor (HomenShum) revisou ambas as descobertas em relação ao código-fonte em 2026-04-26 e postou uma resposta detalhada. Eles:

• Confirmaram três locais reais de command_injection em referências específicas de arquivo:linha e refatoraram cada um para spawn baseado em argv com shell: false. Lançado como v3.2.1.
• Identificaram a descoberta unsafe_eval como um falso positivo com evidência específica: a regex correspondia a db.exec(\