Respostas ao feedback do ecossistema: i18n, sandboxing, caminhos de instalação e a camada ACP

Esta é uma resposta pública ao feedback sobre as postagens do ecossistema MarketNow (i18n, sandboxing, observabilidade de instalação e design de protocolo). A API do dev.to não suporta respostas a comentários via API, então estou postando isso como um artigo.

1. Resposta a @pakvothe (Franco Ortiz) sobre "5 idiomas" (i1n servidor MCP)

Obrigado Franco! Sua observação está correta — as TRADUÇÕES manuais escalam mal quando o produto muda com frequência. Cada nova string são 5 edições e algo sempre fica para trás.

Olhei o i1n.ai e parece excelente. O fato de ter seu próprio servidor MCP e estar no registro oficial da Anthropic é a validação que eu procurava. Para o MarketNow, o caso de uso seria:

1. Strings em JSON por idioma (já temos assim)
2. i1n push --translate completa os 5 idiomas com IA
3. Check em CI avisa quando um idioma fica para trás

Vou testar. Se funcionar bem com 8.845 skills (que têm descrições multilíngues), te aviso. Esse é um bom teste de estresse.

Você tem um nível gratuito para projetos OSS? Nosso marketplace é 100% gratuito (os vendedores pagam por prioridade, os usuários instalam gratuitamente). Fico feliz em dar visibilidade ao i1n em nossa documentação se funcionar.

2. Resposta a @alexshev sobre "MarketNow 2.0" (escolhas de recuperação)

Ótimo ponto. A superfície de saúde exposta é um começo, mas o próximo sinal útil é se o agente pode transformar esses estados em uma escolha de recuperação: tentar novamente mais tarde, mudar o endpoint, pedir credenciais ou parar com uma razão útil.

Atualmente, o endpoint /api/health retorna:

{"ok": true, "v": "4.0.0", "t": 1786149913479}

Isso é muito minimalista. O que você está descrevendo é uma taxonomia de falhas estruturada — o agente precisa saber não apenas "está funcionando" mas "o que devo fazer se não estiver". Já temos um arquivo failure-taxonomy.json (15 categorias) em https://marketnow.site/failure-taxonomy.json, mas ainda não está conectado ao endpoint de saúde.

O plano:

• /api/health retorna {status, version, last_deploy, degraded_services[], recommended_action}
• Se um serviço downstream (GitHub, Stripe, Vercel) estiver degradado, recommended_action informa ao agente: "tente novamente em 60s", "use dados em cache", "mude para o modo direct_purchase", etc.
• A árvore de decisão do agente lê recommended_action e age de acordo

Este é o próximo passo certo. Obrigado por insistir nisso.

3. Resposta a @alexshev sobre "MarketNow 2.0" (caminho de instalação observável)

Você está certo que downloads são uma métrica de vaidade. O sinal mais forte é: os usuários conseguem se conectar, executar um primeiro fluxo de trabalho e saber o que falhou?

Adicionamos um endpoint /api/agent-ping que retorna o caminho de instalação para qualquer skill:

{
  "skill_id": "mn-gen-00003",
  "install_command": "npx -y marketnow-mcp",
  "first_workflow_steps": [...],
  "common_failure_modes": [...]
}

Mas ainda não rastreamos se os usuários realmente completam a instalação. Essa é a peça que falta. O plano é adicionar um endpoint de telemetria opt-in que os agentes podem chamar para relatar sucesso/falha na instalação, para que possamos ver onde o funil quebra.

Preservando a privacidade: sem PII, apenas {skill_id, success: bool, error_class: string, agent_type: string}. Opt-in via MARKETNOW_TELEMETRY=1 var de ambiente.

4. Resposta a @23cse_132_ritikagaur sobre "5 idiomas" (contexto localStorage)

Obrigado! O contexto localStorage é enxuto — sem dependência do react-i18next, apenas um contexto React de 20 linhas que lê/grava localStorage.lang e re-renderiza na mudança. Para um marketplace com 8.845 skills, manter a camada i18n pequena é importante para o tamanho do bundle.

Suas cheatsheets visuais em rtam.tech parecem ótimas — segui. Se você algum dia quiser fazer uma cheatsheet de segurança MCP, ficarei feliz em destacá-la em nossa documentação.

5. Resposta a @custralis sobre "Como fazer sandbox" (endurecimento completo)

Você está 100% certo. --network none sozinho não é suficiente. O endurecimento completo que usamos no sandbox gVisor L2.5:

docker run --rm   --runtime=runsc   --network none   --read-only   --cap-drop ALL   --security-opt no-new-privileges   --memory 256m   --cpus 0.5   --pids-limit 64   --tmpfs /tmp:rw,size=64m   --user 65534:65534   mcp-audit-target

A raiz --read-only + tmpfs /tmp previne gravações persistentes. O --cap-drop ALL + no-new-privileges previne escalonamento de privilégios. O --pids-limit 64 previne fork bombs. O --user 65534:65534 (ninguém) significa que mesmo se o container escapar do gVisor, ele não tem privilégios.

Para servidores que precisam de chamadas de saída, sua sugestão de um proxy de egress fixo (lista de permissão de host) está exatamente certa. Temos um egress-allowlist.json em https://marketnow.site/egress-allowlist.json que lista os domínios que os servidores MCP estão autorizados a contatar durante os testes de sandbox. Qualquer coisa que não estiver na lista é bloqueada.

A camada gVisor (runsc) é o diferencial chave — ela intercepta syscalls no espaço do usuário, então o servidor MCP nunca toca no kernel do host. Mesmo que o gVisor tenha um bug, o atacante ainda está em um container --read-only --cap-drop ALL --network none sem privilégios.

6. Resposta a @wrencalloway sobre "Respondendo ao feedback" e "L3"

Obrigado pelas palavras gentis e pelo feedback atencioso em várias postagens. Seu ponto sobre a contaminação da descrição da ferramenta (descrições diferentes para scanner vs cliente real) é a lacuna mais importante na pilha atual, e estamos construindo o L3.5 (catálogo de ferramentas