Configurar o Site no Ar começa pela conexão MCP, não pelo formato dos arquivos. O setup muda conforme o cliente. Depois do login, todos usam as mesmas tools para editar o Site e publicar.

O endpoint MCP

https://mcp.sitenoar.dev

O servidor usa Streamable HTTP e autenticação pelo login do Site no Ar no navegador. Não cole tokens ou segredos no chat.

Use o prompt central

Cole esta instrução no cliente atual:

Me ajude a conectar o Site no Ar aqui. O guia oficial, com o passo a passo por cliente, está em https://sitenoar.dev/agent-setup-prompt.md

O arquivo identifica o cliente e aplica somente o setup necessário. Ele cobre Claude Code, Codex, Cursor, Gemini CLI, ChatGPT, Claude, Cowork, OpenCode e clientes compatíveis com mcpServers.

Não há um prompt separado para chats. ChatGPT e Claude conectados ao MCP usam o mesmo fluxo de publicação dos clientes de terminal.

Configuração resumida por cliente

Cliente Setup
Codex rode codex mcp add sitenoar --url https://mcp.sitenoar.dev e depois codex mcp login sitenoar
Claude Code claude mcp add --transport http sitenoar https://mcp.sitenoar.dev
Gemini CLI adicione o servidor HTTP e rode /mcp auth sitenoar
Cursor adicione sitenoar ao mcp.json com a URL acima
ChatGPT crie um app em Apps & Connectors com a URL acima
Claude adicione o conector em Settings > Connectors

Os detalhes ficam na página de Configuração e nos guias de cada integração.

Teste a conexão

Salvar a configuração não basta. Peça:

Use o MCP do Site no Ar. Verifique se a ferramenta pública get_account está disponível e chame-a diretamente.

A conexão está pronta quando get_account funciona. Se as tools não aparecerem, reinicie o cliente e confirme se sitenoar está ativo. Um 401 pede nova autorização. Um 402 indica que a conta não tem publicação disponível.

Entenda o modelo de publicação

Cada Site tem um repositório. O agente trabalha em uma Session e usa:

  1. create_site ou list_sites para definir o Site;
  2. get_context antes de editar;
  3. read e bash (ls, rg) para inspecionar;
  4. write, edit e bash (rm) para alterar;
  5. deploy para publicar uma Version;
  6. deploy_status para acompanhar o resultado.

O conteúdo público fica em public/. A home é public/index.html, e public/sitemap.xml deve listar as URLs públicas. Arquivos fora de public/ ficam versionados, mas não vão ao ar.

Faça um primeiro publish pequeno

Crie uma landing page de teste e publique no Site no Ar.
Use o slug campanha-demo.
Chame get_context antes de editar.
Crie public/index.html e public/sitemap.xml pelas file tools.
Rode deploy, acompanhe deploy_status e me informe a URL final somente no sucesso.

Se a página já existe, informe o ID ou o slug e peça para atualizar o mesmo Site. Não crie outro endereço para cada correção.

Revise antes de publicar

Quando a mudança exige aprovação, peça ao agente para parar antes de deploy e resumir:

  • Site e slug escolhidos;
  • arquivos criados, alterados ou removidos;
  • páginas listadas no sitemap;
  • links e CTA principais;
  • verificações executadas.

Depois da aprovação, o agente publica e acompanha o status terminal. Uma resposta final útil inclui URL, slug, status e qualquer erro ou limitação encontrada.

Para o contrato completo, leia Publicação. Para entender por que o MCP conecta agentes e ferramentas externas, veja O que é MCP e como ele está mudando o desenvolvimento web.