Voltar as noticias
Plugins MCP Não Utilizados Estão Consumindo Seu Contexto: Um Pipeline Semanal de Desativação Automática
MCP ProtocolAltaEN

Plugins MCP Não Utilizados Estão Consumindo Seu Contexto: Um Pipeline Semanal de Desativação Automática

Dev.to - MCP·16 de julho de 2026

Esta é uma continuação da minha série "Ambiente de Código Claude". Após o post anterior sobre automação de backups do git-config, desta vez estou abordando um problema que aparece de forma sorrateira: plugins MCP que você ativou uma vez e esqueceu continuam consumindo seu contexto, e eu vou explicar o pipeline de três etapas que os desativa automaticamente em uma programação semanal.

Quando você ativa um plugin, seu esquema de ferramenta é injetado na inicialização, mesmo que nunca seja chamado uma vez. À medida que esses plugins "deixe ligado" se acumulam, o orçamento de tokens que Claude realmente tem para trabalhar diminui silenciosamente. Neste artigo, conecto detecção, desativação automática e arquivamento de cache em um único fluxo com código real.

O problema: gerenciamento de plugins que adiciona, mas nunca subtrai

A motivação para instalar um novo plugin é clara. "Quero usar esta ferramenta" é um impulso ativo. Não há motivação equivalente para remover um. Você nunca tem um momento em que percebe "hum, não usei esse plugin ultimamente".

No início de cada sessão, Claude Code injeta os esquemas de ferramenta de todos os plugins marcados como true em enabledPlugins no settings.json no contexto. Quanto mais plugins estão "ativados, mas não foram invocados uma vez em 30 dias", mais o topo do seu contexto fica preenchido com esquemas de zero contribuição em cada execução.

Após alguns meses testando coisas e deixando-as ativadas, a contagem de plugins dormentes (ativados, mas não utilizados) pode ultrapassar 30.

Arquitetura: um pipeline de três etapas

plugin-usage.sh       → visualizar plugins dormentes (execução manual / relatório semanal)
plugin-auto-disable.sh → desativar automaticamente qualquer um não utilizado por 30 dias, semanalmente
cleanup-plugin-cache.sh → arquivar caches desativados em .disabled-cache/

A cauda de plugin-auto-disable.sh apply chama cleanup-plugin-cache.sh apply, então há um único ponto de entrada para o launchd iniciar.

Etapa 1 — Visualizar plugins dormentes com plugin-usage.sh

~/.claude/scripts/plugin-usage.sh agrega, a partir do JSONL da sessão dos últimos N dias (14 por padrão), apenas os plugins que foram realmente invocados como um tool_use.

# trecho do plugin-usage.sh
LOG_DIR="$HOME/.claude/projects/-Users-matsubara"
DAYS="${1:-14}"

find "$LOG_DIR" -maxdepth 1 -name "*.jsonl" -mtime -"$DAYS" -print0 2>/dev/null | xargs -0 cat 2>/dev/null \
  | jq -R -r 'fromjson? | select(.type=="assistant") | .message.content[]? | select(.type=="tool_use")
      | if .name=="Skill" then ((.input.skill // "") | select(contains(":")) | split(":")[0])
        else (.name | select(startswith("mcp__plugin_")) | sub("^mcp__plugin_";"") | split("_")[0]) end' 2>/dev/null \
  | sort | uniq -c | sort -rn > "$TMP"

Ele relata a diferença entre o número de plugins ativados e o número de invocações distintas como Dormentes.

TOTAL_ENABLED=$(jq -r '[.enabledPlugins // {} | to_entries[] | select(.value)] | length' "$SETTINGS")
# Dormentes = TOTAL_ENABLED - USED_COUNT

Por que agregar com jq em vez de grep

A implementação antiga usava grep para correspondência de substring. Isso contava incorretamente as linhas "lista completa de ferramentas adiadas" no JSONL (uma lista muito longa de nomes de ferramentas disponíveis) como "invocações", o que fazia com que coisas como terraform aparecessem perto do topo, mesmo que nunca fossem chamadas, e poderia até fazer a contagem de Dormentes ficar negativa. Passar tudo por select(.type=="tool_use") corrige isso para que apenas chamadas que foram realmente invocadas sejam contadas.

Saída de exemplo:

## Resumo
- Plugins ativados: **62**
- Plugins distintos referenciados nos logs: **29**
- Dormentes (ativados, mas nunca invocados): **33**

## Plugins Dormentes (ativados, sem invocação recente)
_Candidatos para desativação para reduzir o custo de contexto_
...

## Recomendação
- 33 plugins ativados, mas não utilizados nos últimos 14 dias
- Carga dormente pesada — desativar esses poderia liberar um orçamento de contexto significativo
- Para desativar um plugin: edite `enabledPlugins` em ~/.claude/settings.json

Uma vez que os Dormentes excedem 30, ele imprime "Carga dormente pesada". Esse limite é codificado no script.

Etapa 2 — plugin-auto-disable.sh desativa automaticamente, semanalmente

~/.claude/scripts/plugin-auto-disable.sh é o núcleo. Ele padrão para dry (sem alterações); passe apply e ele realmente desativa plugins.

# trecho do plugin-auto-disable.sh
MODE="${1:-dry}"
DAYS="${DAYS:-30}"             # janela de observação (padrão 30 dias)
MIN_CACHE_MB="${MIN_CACHE_MB:-5}"    # pular caches menores que 5MB
WEEKLY_MAX="${WEEKLY_MAX:-5}"        # no máximo 5 por execução
Contexto Triplo Up

Empresas brasileiras que utilizam ambientes de IA devem gerenciar seus plugins de forma eficiente para evitar desperdícios de recursos. A implementação de um pipeline de desativação automática pode otimizar o uso do contexto, melhorando a performance das aplicações. Isso é crucial para manter a competitividade em um mercado cada vez mais dependente de IA.

Noticias relacionadas

Gostou do conteudo?

Receba toda semana as principais novidades sobre WebMCP.