A lacuna de distribuição que prejudica bons servidores MCP

A maioria dos servidores MCP nunca é indexada em nenhum lugar que importe. O Registro Oficial do MCP, Smithery, Glama, PulseMCP — cada um tem seu próprio caminho de submissão, e submeter a todos eles uma vez é uma tarde que você não planejou passar. Permanecer visível após isso é um trabalho recorrente que ninguém se inscreve.

Eu construí o marketing-pipeline para lidar com o trabalho recorrente. Um comando integra um projeto:

marketing onboard --name my-tool --repo owner/repo --kind mcp-server

Isso busca o README, envia para Claude e escreve declarações de problemas, afirmações factuais e ângulos de rotação para projects.yml. A partir dessa configuração, o pipeline sabe que deve submeter ao Registro do MCP (do qual Glama e PulseMCP puxam automaticamente), Smithery e Tópicos do GitHub — e elaborar posts para Bluesky, Dev.to, Hashnode e Mastodon.

O cron diário é executado via GitHub Actions às 14:00 UTC nos dias de semana, rotacionando por cada projeto registrado × combinação de ângulo × canal, sempre escolhendo o ângulo menos recentemente usado para que nada se repita em um curto espaço de tempo.

O controle de qualidade é imposto por um portão de rejeição rigoroso em pipeline/antislop.py antes que qualquer coisa seja postada: 'animado', 'mudança de jogo', 'potencializado por IA', hashtags, emoji e pontos de exclamação são bloqueados no momento da publicação, não apenas durante a elaboração. Limites de comprimento por canal também são impostos — 300 caracteres para Bluesky, 280 para X, 150–400 palavras para Dev.to e Hashnode.

Uma restrição que vale a pena saber: awesome-claude-code não pode ser automatizado. As regras deles exigem que um humano submeta através do formulário de problemas do GitHub, então o pipeline gera a carga útil e para por aí.

Você precisa de uma chave de API da Anthropic e credenciais para pelo menos Bluesky, Dev.to e Hashnode para executá-lo. Mastodon e Slack são opcionais.

github.com/robertnowell/marketing-pipeline