Como os agentes de IA usam MCP para publicar sites sem intervenção humana

Agentes de IA usam MCP para publicar sites sem intervenção humana quando o trabalho manual repetitivo sai do caminho: abrir painel, escolher arquivo, iniciar upload, esperar deploy e copiar URL. Isso não significa publicar sem autorização, sem revisão ou sem responsabilidade.

O fluxo bom é mais preciso: você define as regras, o agente edita os arquivos do Site, usa ferramentas MCP autorizadas, acompanha o deploy e devolve evidência. A intervenção humana deixa de ser a operação mecânica e passa a ser a decisão sobre o que pode ir ao ar.

No Site no Ar, esse caminho funciona em qualquer cliente conectado ao MCP remoto. O agente edita o repositório do Site, publica e retorna a URL. Para configurar a conexão, veja Configuração. Para entender file tools, Sessions e Versions, veja Publicação.

O que “sem intervenção humana” realmente quer dizer

No contexto de publicação por agente, “sem intervenção humana” não deveria significar autonomia sem controle.

Significa que, depois de autorizada a tarefa, o agente não precisa que uma pessoa:

• compacte a pasta manualmente;
• abra o dashboard;
• envie o arquivo;
• espere o deploy;
• copie a URL final;
• volte ao chat para registrar o resultado.

A pessoa ainda decide se a página pode ser publicada, qual slug usar, que pasta enviar e quais verificações importam. O agente opera a parte repetitiva.

Essa distinção evita uma promessa ruim. Publicar um site é uma ação real. O MCP ajuda porque torna essa ação chamável, auditável e dependente de permissões do cliente.

Como o MCP entra no fluxo

MCP cria uma camada padronizada entre o host de IA e um servidor externo. No caso de publicação de sites:

A especificação do MCP reforça princípios de consentimento e controle do usuário. Para deploy, isso se traduz em uma regra simples: o agente deve saber o que está autorizado a publicar antes de chamar a ferramenta.

O fluxo em sete etapas

Um agente bem instruído publica assim:

1. entende o objetivo do site;
2. revisa ou gera os arquivos;
3. roda build quando necessário;
4. chama get_context e inspeciona public/;
5. confirma index.html e assets;
6. publica pelo MCP;
7. verifica e relata a URL final.

Se qualquer etapa falhar, ele deve parar com uma próxima ação clara. Exemplo: login expirado, index.html ausente, slug ocupado, limite de plano ou erro de build.

Esse é o mesmo raciocínio usado no fluxo de Codex + MCP e em guias de agente como Gemini CLI + Site no Ar.

Por que os arquivos do Site importam

O agente não publica uma intenção abstrata. Ele publica arquivos.

Antes do MCP, peça uma checagem objetiva:

Antes de publicar, confirme:
- qual pasta será enviada;
- se existe index.html na raiz;
- se os assets referenciados estão dentro da pasta;
- se há build pendente;
- se a URL final deve manter o mesmo slug.

Esse passo reduz os erros mais comuns de deploy por IA: publicar src, esquecer imagens, mandar um build antigo ou trocar o slug sem avisar.

No Site no Ar, o caminho canônico mantém os arquivos no workspace git do Site. O agente usa read, write, edit e bash (para ls, rg e rm); depois chama deploy para transformar a Session em uma Version.

Prompt para publicar com menos intervenção manual

Depois de configurar o MCP, use um pedido completo:

Use o MCP do Site no Ar para publicar este site.

1. Chame `get_context` e revise os arquivos existentes.
2. Rode o build padrão se for necessário.
3. Confirme que index.html existe na raiz da saída.
4. Publique com o slug: demo-produto.
5. Se o slug estiver ocupado, pare e sugira alternativas.
6. Acompanhe o deploy até sucesso ou erro final.
7. Verifique a URL final.

Na resposta, informe arquivos alterados, slug usado, URL,
status do deploy e o que foi verificado.

Se você precisa de aprovação antes do deploy, ajuste:

Prepare o plano de publicação e pare antes do deploy.
Depois que eu aprovar, use o MCP do Site no Ar para publicar.

Esse modo ainda reduz trabalho manual. O agente prepara tudo e espera a decisão humana no ponto certo.

Quando não publicar direto

Não peça publicação direta quando:

• o site ainda tem placeholder;
• a página depende de segredo ou variável ausente;
• o build tem erro ou warning crítico;
• a pasta final não foi identificada;
• o domínio próprio ainda precisa de decisão de DNS;
• o conteúdo precisa de revisão jurídica, comercial ou de marca.

Nesses casos, o agente deve mostrar o plano e pedir confirmação. Publicar rápido não compensa colocar uma URL quebrada ou incorreta no ar.

Para domínio próprio, trate como etapa separada. Primeiro publique no endereço padrão do Site no Ar; depois siga o guia de Domínios próprios para configurar DNS e Custom Hostname.

Como verificar depois do deploy

A resposta final deve trazer evidência, não só entusiasmo.

Peça para o agente confirmar:

Se o ambiente do agente não permitir abrir navegador, ele deve dizer isso. Ainda assim, pode relatar status do deploy, URL gerada, arquivos alterados e limitações da checagem.

O ganho real

O ganho real de agentes de IA usando MCP para publicar sites não é remover humanos da decisão. É remover o trabalho operacional que não precisa mais ser humano.

Você continua definindo escopo, qualidade e autorização. O agente cuida de preparar saída, chamar ferramenta, acompanhar status e registrar URL. O Site no Ar cuida da camada de publicação.

Quando esse contrato está claro, o fluxo deixa de terminar em “faça deploy” e passa a terminar em uma entrega verificável. Para repetir com segurança, salve seu prompt padrão, conecte o MCP pela documentação de configuração e revise cada resposta final como um pequeno relatório de publicação.