Codex + MCP não é um botão mágico de deploy. É um fluxo em que o agente entende o projeto local, usa ferramentas autorizadas e segue um contrato de publicação até entregar uma URL verificável.

O MCP entra como ponte entre Codex e serviços externos. No Site no Ar, essa ponte permite criar ou escolher um Site, ler e alterar seu repositório, iniciar o deploy e acompanhar o resultado. O ganho está em tirar o último passo manual da conversa sem perder rastreabilidade.

Se você quer o caminho rápido, comece pelo guia Como usar o Codex para gerar e publicar sites automaticamente. Este artigo detalha o fluxo completo para times que querem repetir o processo com menos improviso.

Visão geral do fluxo

Um ciclo confiável tem sete etapas:

Etapa Dono Evidência esperada
Definir escopo usuário objetivo, slug e páginas esperadas
Abrir contexto Codex get_context do Site correto
Criar ou editar site Codex arquivos alterados pelas file tools
Conferir conteúdo Codex public/ e sitemap coerentes
Publicar via MCP Codex + Site no Ar deploy concluído
Verificar URL Codex página abre e assets carregam
Entregar resumo Codex URL, slug, pasta e observações

Essa tabela parece burocrática, mas evita a maioria dos problemas de publicação com agentes: pasta errada, arquivo principal ausente, slug trocado sem aviso e deploy dado como concluído sem abrir a URL final.

1. Defina o contrato no prompt

Antes de pedir para o Codex criar qualquer coisa, escreva o contrato de saída:

Objetivo: criar uma página de campanha para captar leads de uma consultoria B2B.
Formato final: site estático no diretório public/ do Site.
Arquivo principal: public/index.html.
Slug desejado: campanha-b2b-demo.
Publicação: usar o MCP do Site no Ar.
Verificação: retornar a URL final e confirmar se a home abriu.

Se o Site já existe, diga isso explicitamente:

Use o Site existente campanha-b2b-demo.
Chame get_context e leia os arquivos atuais antes de editar.
Não crie outro Site e não altere o slug.

O Codex é bom em percorrer repositórios, mas deploy precisa de destino explícito. Quanto mais claro for o Site, menor o risco de publicar no endereço errado.

2. Conecte o MCP do Site no Ar

No Codex, o caminho de CLI para um servidor MCP HTTP remoto usa --url:

Terminal window
codex mcp add sitenoar --url https://mcp.sitenoar.dev
codex mcp login sitenoar

O segundo comando abre o Site no Ar no navegador. Conclua a autorização e então confira a configuração:

Terminal window
codex mcp list
codex mcp get sitenoar --json

Se o login expirar, rode codex mcp login sitenoar novamente.

A documentação de Codex mantém o setup específico do cliente. A página de configuração mostra o prompt central usado também em Claude Code, Cursor, Gemini CLI, OpenCode, ChatGPT e Claude.

3. Crie o site com critérios de publicação

Ao criar o site, peça para o Codex considerar o ambiente final:

  • caminhos relativos para CSS, JS e imagens;
  • index.html como home;
  • assets dentro de public/;
  • conteúdo sem placeholder;
  • layout responsivo;
  • ausência de dependência externa crítica se a página for estática;
  • instrução para rodar build e validação antes do deploy.

Um prompt útil:

Crie uma landing page estática para um lançamento de produto.
Use arquivos simples e deixe tudo publicável como site estático.
Depois rode a validação disponível no projeto.
Se houver build, gere a pasta final antes de publicar.

Se o Codex alterou um projeto existente, peça uma revisão curta antes de publicar:

Antes do deploy, revise o diff e me diga quais arquivos vão impactar a página publicada.
Depois rode a build e publique somente a saída final.

Esse passo separa criação de publicação. O agente pode fazer os dois na mesma conversa, mas deve mostrar que a primeira parte ficou pronta antes de enviar a segunda.

4. Prepare o conteúdo público

O contrato de publicação mantém o conteúdo servido em public/:

  • public/index.html é a home;
  • outros HTMLs criam páginas;
  • assets preservam seus caminhos dentro de public/;
  • public/sitemap.xml lista as URLs públicas;
  • arquivos fora de public/ não são servidos.

O Codex usa read e bash (ls, rg) para inspecionar. Depois altera com write e edit, e remove arquivos com rm no bash.

Peça essa confirmação:

Antes do deploy, liste:
- Site e slug usados;
- arquivos criados, alterados ou removidos;
- páginas presentes em public/sitemap.xml;
- principais assets referenciados.

Não precisa despejar o conteúdo inteiro. Precisa de evidência suficiente para saber que o Site certo será publicado.

5. Publique via MCP

Quando o pacote estiver pronto, o pedido pode ser direto:

Use o MCP do Site no Ar para criar ou atualizar o Site.
Slug: campanha-b2b-demo.
Chame get_context, edite os arquivos pelas file tools e mantenha public/sitemap.xml.
Se o slug estiver ocupado, use uma sugestão disponível e registre a mudança.
Depois acompanhe o deploy até sucesso ou erro final.

Por baixo, o fluxo esperado é:

  1. criar ou escolher o Site;
  2. chamar get_context;
  3. editar o repositório pelas file tools;
  4. iniciar o deploy;
  5. acompanhar o status;
  6. devolver a URL final.

Se o MCP informar falta de assinatura, limite de plano, login expirado ou domínio pendente, isso deve aparecer na resposta final. Um bloqueio claro é melhor do que uma tentativa silenciosa.

6. Verifique a URL publicada

Deploy concluído não é o mesmo que página correta. Peça uma verificação simples:

Verifique a URL final.
Confirme:
- a home abre;
- CSS e imagens carregam;
- links principais funcionam;
- não há erro óbvio no console ou na página.

Quando o ambiente não permitir abrir navegador, o Codex ainda deve entregar o que conseguiu checar: status do deploy, URL, slug e arquivos alterados. A limitação precisa ficar explícita.

7. Padronize a entrega final

Uma resposta final boa para Codex + MCP tem esta forma:

Publicado.
URL: https://campanha-b2b-demo.sitenoar.app
Slug: campanha-b2b-demo
Version: atualizar CTA da campanha
Arquivos: public/index.html, public/sitemap.xml
Verificação: home abriu, CSS carregou, imagens principais carregaram
Observações: nenhum bloqueio encontrado

Esse padrão facilita colar a URL em um issue, PR, Slack ou entrega para cliente. Também ajuda quando você precisa republicar: o próximo agente sabe qual Site e quais arquivos foram alterados.

Onde o MCP muda o trabalho

Sem MCP, o agente normalmente para nos arquivos ou em instruções para você publicar. Com MCP, a publicação entra no mesmo ciclo de trabalho do Codex: editar, validar, publicar e verificar.

Isso não elimina revisão. O que muda é a etapa final: em vez de abrir um painel de hosting e repetir manualmente o upload, você pede para o agente executar o contrato de publicação e trazer evidência.

Para continuar, configure o servidor em Codex, leia o contrato de publicação e teste com uma página pequena. Depois transforme o prompt em rotina: escopo, contexto, edição, deploy e verificação. Se você trabalha com outros clientes, os guias de Cursor + MCP e ChatGPT + Site no Ar mostram o setup específico sem mudar o fluxo de publicação.