MCP para hospedagem é a ideia de transformar deploy em uma ferramenta que agentes de IA conseguem usar com autorização, contexto e resposta verificável. Em vez de o agente parar no fim dizendo “suba estes arquivos”, ele pode seguir um contrato: preparar o pacote, chamar a ferramenta de publicação, acompanhar o status e devolver a URL final.

Esse é o futuro mais provável do deploy com agentes de IA: não um botão mágico escondido, mas uma camada de hospedagem desenhada para ser operada por software. O agente continua precisando de regras claras. A diferença é que a etapa de hospedagem deixa de ser um painel separado e passa a fazer parte da conversa.

No Site no Ar, esse padrão aparece no MCP remoto de publicação. O agente cria ou escolhe um Site, edita os arquivos sob public/, chama deploy e valida a URL. Para configurar o caminho completo, comece pela documentação de Configuração e pelo contrato de Publicação.

Por que hospedagem precisa mudar para agentes

Ferramentas de IA já aceleram briefing, copy, HTML, CSS, componentes e ajustes visuais. O gargalo aparece depois: a entrega precisa virar um endereço público.

No modelo tradicional, a hospedagem espera uma pessoa:

  • abrir um painel;
  • descobrir a pasta de build;
  • arrastar um arquivo ou configurar um repositório;
  • copiar a URL;
  • voltar para o chat ou issue com o resultado.

Para um agente, isso é uma quebra de fluxo. Ele tem contexto do projeto, sabe quais arquivos acabou de gerar e consegue validar a saída local, mas não necessariamente tem uma ferramenta segura para publicar.

MCP resolve essa fronteira criando uma forma padronizada de expor ferramentas externas. A especificação oficial define MCP como um protocolo para conectar aplicações de LLM a dados e ferramentas. Quando a ferramenta externa é hospedagem, o deploy vira uma ação chamável pelo agente.

Como fica a hospedagem com MCP

Uma camada de hospedagem preparada para MCP precisa expor ações que façam sentido para o ciclo de publicação:

Ação Por que importa para o agente
criar ou localizar Site evita publicar no destino errado
editar arquivos cria ou altera o conteúdo estático no workspace do Site
publicar Version transforma o estado salvo em uma versão no ar
acompanhar deploy evita responder antes de o status final existir
devolver URL fecha o ciclo com uma evidência compartilhável
configurar domínio separa o primeiro publish da etapa de DNS e Custom Hostname

O usuário não precisa conhecer a API interna da hospedagem. Ele precisa dar um pedido claro:

Chame get_context, atualize os arquivos em public/ e publique com deploy.
Slug: campanha-produto
Use o MCP do Site no Ar.
Depois me entregue a URL final e diga o que foi verificado.

O agente traduz esse pedido para ferramentas. A hospedagem executa o que cabe a ela. A resposta final volta para o usuário em linguagem de entrega: arquivos alterados, slug, URL, status e observações.

O que muda no deploy

O deploy deixa de ser uma etapa solta e vira parte de um fluxo maior:

  1. o agente entende o objetivo;
  2. cria ou ajusta o site;
  3. identifica se precisa de build;
  4. confirma os arquivos sob public/;
  5. verifica index.html e assets;
  6. publica pelo MCP;
  7. abre ou checa a URL final;
  8. resume a entrega.

Esse encadeamento é mais importante do que a palavra “automático”. Um deploy automático ruim publica a pasta errada mais rápido. Um deploy por agente bem desenhado publica a pasta certa com mais evidência.

O guia Codex + MCP: o fluxo completo de criação e publicação de sites mostra esse caminho em detalhes. O artigo Cursor Agent + Site no Ar mostra a versão dentro de um editor.

Onde o humano continua decidindo

MCP para hospedagem não remove responsabilidade. Ele move decisões para o prompt e para a resposta final.

Antes de publicar, o humano ainda deve definir:

  • o objetivo da página;
  • se a URL pode ser pública agora;
  • o slug desejado;
  • se o agente pode escolher outro slug;
  • se a publicação atualiza um Site existente;
  • se domínio próprio fica para depois;
  • quais verificações bloqueiam a entrega.

Isso é especialmente importante quando o site é de cliente, campanha paga, página de vendas ou material regulado. A ferramenta pode publicar, mas o critério de publicação ainda é produto, marca e operação.

O contrato de arquivos continua existindo

Mesmo com MCP, hospedagem de site estático precisa de pacote correto.

No Site no Ar:

  • index.html é a página inicial;
  • outros arquivos .html viram rotas;
  • CSS, JavaScript, imagens e fontes seguem os caminhos enviados;
  • um site simples pode ser um único index.html;
  • múltiplas páginas e assets devem ficar sob public/.

Esse contrato evita que o agente tente “mandar o código pelo contexto”. O fluxo canônico é publicar arquivos reais, não colar bytes de bundle em uma conversa. A página de Publicação explica como o upload funciona.

O papel do Site no Ar nesse futuro

O Site no Ar foca na última etapa do ciclo de agentes: transformar arquivos prontos em URL pública.

Em qualquer cliente conectado, o MCP remoto permite que o agente:

  1. use https://mcp.sitenoar.dev como endpoint;
  2. autentique a conta pelo cliente;
  3. publique a saída do projeto;
  4. acompanhe o status;
  5. entregue a URL final.

O fluxo não muda em ChatGPT, Claude ou outros chats conectados ao MCP. Depois do setup específico do cliente, todos editam o Site pelas file tools e publicam com deploy.

Como pedir um deploy orientado por agente

Use um prompt que una criação, hospedagem e verificação:

Prepare este projeto para hospedagem pelo Site no Ar.


1. Descubra a pasta publicável.
2. Rode build apenas se for necessário.
3. Confirme que index.html existe na raiz.
4. Publique pelo MCP com o slug: campanha-demo.
5. Acompanhe o deploy até estado final.
6. Verifique a URL publicada.


Na resposta, informe pasta, slug, URL, status e qualquer limitação.
Se faltar aprovação ou decisão, pare antes de publicar.

Esse pedido deixa claro que hospedagem é uma etapa com pré-condições. O agente não deve pular a revisão do pacote só porque tem uma ferramenta de deploy disponível.

Para onde isso aponta

O futuro do deploy com agentes de IA não é cada ferramenta de IA ter seu painel de hospedagem embutido. É mais provável que serviços especializados exponham servidores MCP, e que agentes diferentes possam operar essas ferramentas com um contrato comum.

Para quem cria sites, isso significa menos trabalho repetitivo no fim do fluxo. Para quem entrega sites, significa respostas finais mais úteis: não apenas “o código está pronto”, mas “o site está publicado neste endereço, com estes arquivos e esta verificação”.

Comece pequeno: conecte o MCP em Configuração, publique uma página estática simples e só depois padronize o fluxo para campanhas, clientes ou republicações frequentes. Hospedagem com agentes funciona melhor quando a automação é explícita, verificável e fácil de repetir.