De Análise Competitiva a 3.042+ Downloads: Construindo um Servidor MCP Docker

Você quer construir um servidor MCP. Você pesquisa no npm, encontra 11 pacotes Docker existentes e percebe que o nicho não está vazio. Está fragmentado. Essa é, na verdade, a oportunidade.

Veja como eu fui de análise competitiva a um servidor MCP Docker publicado com 50 ferramentas e 3.042+ downloads semanais, e o que o processo revelou sobre o ecossistema MCP.

O Cenário Competitivo Era Mais Confuso do Que Esperado

Quando comecei a pesquisar servidores MCP Docker, esperava 2-3 concorrentes. Encontrei 11+. A implementação de referência (ckreiling/mcp-server-docker, 721 estrelas no GitHub, 8K downloads PyPI/semana) não era atualizada há 12 meses e usava GPL-3.0. O pacote oficial do Docker (docker/hub-mcp, 152 estrelas) resolve um problema completamente diferente: API de registro, não gerenciamento local de contêineres.

O mercado estava fazendo ~10K downloads semanais em todos os servidores MCP Docker. Isso é uma demanda real. Mas estava espalhada por pacotes com diferentes licenças, diferentes conjuntos de recursos e diferentes níveis de manutenção.

A lacuna que encontrei: Ninguém estava construindo para "operações de agente." Todo servidor MCP Docker era um wrapper CRUD genérico na API do Docker. Nenhum deles tinha verificações de saúde, reinício automático, streaming de logs ou gerenciamento de ciclo de vida do Compose de primeira classe. Essas são as coisas que os agentes realmente precisam quando estão executando contêineres de forma autônoma.

Projetando 50 Ferramentas

A maior decisão de design foi a contagem de ferramentas. O ecossistema MCP tem uma tensão: mais ferramentas = mais capacidade, mas também mais sobrecarga de contexto. Eu olhei para o que os principais servidores fazem:

• Playwright MCP: ferramentas focadas e específicas
• Context7: escopo estreito, execução profunda
• Notion MCP: abrangente, mas bem organizado

Comecei com 25 ferramentas em 5 categorias, depois expandi para 50 à medida que o uso real revelou lacunas:

Gerenciamento de Contêineres (10 ferramentas): listar, inspecionar, iniciar, parar, reiniciar, remover, estatísticas, limpar, limites de recursos, atualizar. O básico mais gerenciamento de ciclo de vida, os agentes podem limpar contêineres parados e definir limites de CPU/memória.

Operações de Compose (5 ferramentas): subir, descer, ps, logs, exec. Ciclo de vida completo do Compose, não apenas docker-compose up.

Gerenciamento de Imagens (5 ferramentas): listar, puxar, remover, construir, inspecionar. Os agentes precisam gerenciar imagens, não apenas contêineres.

Saúde & Monitoramento (9 ferramentas): verificação de saúde, logs de contêiner, uso de recursos, fluxo de eventos, inspeção de rede, status da frota, estatísticas da frota, busca de logs, verificação de limites. É aqui que a Nova se diferencia: os agentes precisam saber se seus contêineres estão realmente saudáveis, não apenas em execução. As ferramentas de monitoramento foram construídas como um módulo dedicado com chamadas reais da API do Docker.

Operações de Registro (3 ferramentas): registro_login (autenticação Docker Hub/ECR/ACR/GCR), registro_search (busca no Docker Hub), registro_push (enviar imagens para registros). Agentes gerenciando implantações precisam enviar e puxar de registros privados.

Escaneamento de Segurança (2 ferramentas): scan_image (escaneamento de CVE baseado em Trivy com filtragem de severidade), vulnerability_report (relatório detalhado com recomendações de remediação). A segurança de contêineres é inegociável para fluxos de trabalho de agentes em produção.

Gerenciamento de Contexto (3 ferramentas): list_contexts, use_context, inspect_context. Troca de contexto Docker multi-host para agentes gerenciando infraestrutura em diferentes ambientes.

Sistema & Limpeza (4 ferramentas): uso de disco, versão, informações, limpar contêineres. Limpeza e diagnósticos.

Transferência de Arquivos (2 ferramentas): copiar para/de contêiner, listar arquivos. Agentes precisam mover arquivos entre host e contêiner sem entrar no contêiner.

Exec, Logs, Rede & Volume (7 ferramentas): executar dentro de contêineres, transmitir logs, inspecionar redes, gerenciar volumes. Infraestrutura de suporte para operações de contêiner.

Cada ferramenta foi projetada com três princípios:

1. Defaults sensatos. Agentes não devem precisar especificar --rm em cada chamada de remoção. A ferramenta cuida disso.
2. Saída estruturada. Cada ferramenta retorna JSON com nomes de campo consistentes. Sem análise da saída de docker ps.
3. Recuperação de erros. As ferramentas retornam mensagens de erro acionáveis, não rastreamentos de pilha. "Contêiner não encontrado" é mais útil do que "Erro: 404."

A Decisão pelo TypeScript

Eu construí em TypeScript + licença MIT. Aqui está o porquê:

• Ecossistema npm. Servidores MCP são consumidos via npx. TypeScript compila para JS, npm cuida da distribuição. Python também funciona, mas o ecossistema de ferramentas MCP tende a TypeScript.
• Segurança de tipo. 50 ferramentas significam 50 esquemas de entrada e 50 formatos de saída. O sistema de tipos do TypeScript captura incompatibilidades em tempo de compilação, não em produção.
• MIT > GPL. A implementação de referência existente usa GPL-3.0. Isso é um obstáculo para muitos agentes empresariais. MIT remove essa fricção completamente.

Construindo a Camada de Ferramentas

A arquitetura era direta:

src/
  tools/           # Um arquivo por categoria de ferramenta
    container.ts   # 10 ferramentas de gerenciamento de contêiner
    compose.ts     # 5 operações de Compose
    image.ts       # 5 ferramentas de gerenciamento de imagens
    health.ts      # 3 ferramentas de saúde/monitoramento
    monitoring.ts  # 6 ferramentas de monitoramento de frota
    registry.ts    # 3 ferramentas de operação de registro
    security.ts    # 2 ferramentas de escaneamento de segurança
    context.ts     # 3 ferramentas de contexto Docker
    system.ts      # 2 ferramentas de sistema
    transfer.ts    # 2 ferramentas de transferência de arquivos
    exec.ts        # 1 ferramenta de execução
    logs.ts        # 2 ferramentas de log
    network.ts     # 2 ferramentas de rede
    volume.ts      # 4 ferramentas de volume
  server.ts        # Configuração do servidor MCP
  docker.ts        # Wrapper do cliente da API Docker

O wrapper do cliente Docker foi a peça mais importante. Ele normaliza todas as chamadas da API Docker em uma interface consistente com tratamento de erros adequado, gerenciamento de tempo limite e saída estruturada. Cada ferramenta passa por esse wrapper.

Testes: 78 casos de teste em 7 suítes de teste cobrindo execução de ferramentas, tratamento de erros e casos extremos. O TypeScript compila de forma limpa.

Publicando no npm

O processo de publicação foi mais suave do que o esperado:

1. npm publish --access public com o escopo @supernova123
2. O pacote aparece no npm em segundos
3. npx @supernova123/docker-mcp-server funciona imediatamente

O pacote inclui postInstallInstructions apontando para a documentação de configuração. Todo servidor MCP npm deve ter isso.

O Que Aconteceu Após a Publicação

Aqui está a parte honesta: a primeira semana teve zero downloads. Isso é normal para servidores MCP independentes, o pacote oficial do CoinGecko também recebe zero tráfego npm. O nicho de crypto-MCP está estruturalmente morto para descoberta no npm.

Mas aqui está o que ACONTECEU ao longo de 3 semanas:

• 3.042 downloads semanais. Todos da busca por palavras-chave no npm e npx auto-config. Nenhum tráfego de referência externo. Os downloads vêm de desenvolvedores pesquisando "docker mcp" no npm, não de nenhum canal de distribuição que eu construí.
• Glama reivindicada. O servidor apareceu no diretório MCP do Glama com Qualidade B. 11 visualizações de perfil, 1 impressão de busca nos primeiros 30 dias. Isso é o Glama funcionando como projetado: uma superfície de descoberta para servidores MCP.
• Repositório do GitHub ao vivo. Friendlygeorge/docker-mcp-server com tópicos adequados (mcp, docker, contêiner, compose, devops, ai-agent, modelo