Primeiro confirme se o Gemini CLI ainda é o seu cliente

Publicar sites com Gemini CLI usando MCP é um fluxo direto quando o seu ambiente ainda executa o comando gemini e aceita servidores MCP remotos por HTTP. A ideia é simples: você conecta o Site no Ar como ferramenta MCP, autentica sua conta e pede ao agente para criar os arquivos no workspace do Site e publicá-los.

Há um detalhe importante para guias publicados agora: a documentação oficial de MCP do Gemini CLI passou a avisar que usuários gratuitos e Google One seriam migrados para Antigravity CLI em 18 de junho de 2026. Se a sua organização ainda usa Gemini CLI, siga o passo a passo abaixo. Se sua conta já foi migrada, use este artigo como referência do contrato MCP e confira o cliente atual antes de copiar os comandos.

Para a parte do Site no Ar, o contrato é o mesmo dos outros clientes: servidor MCP remoto, OAuth, arquivos em public/, deploy e URL final verificada.

O que você precisa antes de publicar

Antes de rodar o primeiro publish, deixe estes pontos decididos:

Item Decisão prática
Cliente gemini instalado e acessível no terminal
Workspace do Site arquivos estáticos mantidos pelas file tools do MCP
Página inicial public/index.html
Slug endereço desejado, como gemini-demo
Conta Site no Ar login pronto para autorizar o MCP
Critério de sucesso URL final abre, home carrega e assets aparecem corretamente

Se você ainda não conectou nenhum agente, comece pela página de configuração. Ela reúne o fluxo comum para Gemini CLI, Codex, Cursor, Claude Code, OpenCode, ChatGPT e Claude.

Adicione o Site no Ar ao Gemini CLI

No terminal, adicione o servidor MCP remoto:

Terminal window
gemini mcp add --transport http sitenoar https://mcp.sitenoar.dev

Depois, dentro da sessão do Gemini, autentique:

/mcp auth sitenoar

O fluxo abre a autorização da sua conta do Site no Ar. Conclua o login no navegador e volte para a sessão do Gemini.

Para conferir se o servidor ficou registrado, rode:

Terminal window
gemini mcp list

O guia curto de Gemini CLI mantém esses comandos em formato de consulta rápida.

Teste antes da primeira publicação

Não use a primeira tentativa para publicar algo importante. Peça uma checagem de conexão:

Use o MCP do Site no Ar e teste a conexão.
Não publique nada ainda.
Se a autenticação estiver pronta, diga quais ações de publicação estão disponíveis.
Se algo bloquear, explique a próxima ação.

Esse teste separa problema de login de problema de conteúdo. Se o Gemini não encontrar o servidor sitenoar, volte ao terminal, liste os MCPs e confirme se a sessão foi reiniciada depois da configuração.

Prepare os arquivos do Site

O Site no Ar publica arquivos estáticos mantidos no workspace git do próprio Site. Peça ao Gemini para chamar get_context, consultar os arquivos existentes e criar ou atualizar o conteúdo com write e edit.

A página inicial deve ficar em public/index.html. Outras páginas, CSS, JavaScript, imagens e fontes também ficam sob public/, preservando os caminhos usados no HTML. Inclua public/sitemap.xml com as URLs públicas antes do deploy.

Prompt para publicar pelo Gemini CLI

Com a conexão pronta, use o prompt central de configuração e depois faça um pedido fechado:

Publique este site pelo MCP do Site no Ar.


Slug desejado: gemini-demo
Use public/index.html como página inicial.


Primeiro chame get_context. Depois crie ou escolha o Site, escreva os arquivos
com as file tools, chame deploy, acompanhe o deploy
e me devolva a URL final com o status de verificação.


Se houver bloqueio de autenticação, limite, slug ocupado ou arquivo ausente,
pare e explique a próxima ação.

Esse prompt dá ao agente liberdade para executar o fluxo, mas fixa os limites que importam: Site, slug, página inicial e evidência de sucesso.

O que acontece no MCP

Durante a publicação, o Gemini CLI usa o Site no Ar como ferramenta operacional. O fluxo recomendado é:

  1. Chamar get_context e criar ou escolher o Site.
  2. Consultar os arquivos existentes com bash (ls) e read.
  3. Criar ou alterar os arquivos sob public/ com as file tools.
  4. Chamar deploy e acompanhar com deploy_status até o estado final.
  5. Abrir a URL final e conferir se a página carrega.

Como revisar a resposta final

Uma resposta boa do agente deve trazer mais do que “publicado”. Procure por:

Campo O que verificar
Arquivos publicados correspondem à versão que você aprovou
Slug é o slug solicitado ou uma alternativa aprovada
URL final abre no navegador
Status do deploy terminou com sucesso
Verificação visual home, estilos e imagens carregam
Próxima ação aparece somente se algo bloqueou

Se o Gemini publicar uma URL, abra e confira antes de compartilhar com cliente, time ou campanha. O Site no Ar reduz a parte operacional, mas a validação final ainda precisa ser explícita.

Erros comuns

Sintoma Próxima ação
MCP não aparece conferir gemini mcp list e reiniciar a sessão
OAuth não conclui refazer /mcp auth sitenoar
index.html ausente confirmar a pasta de build correta
Slug ocupado escolher outro slug ou aprovar sugestão da ferramenta
Página sem CSS verificar os caminhos e arquivos sob public/
URL não verificada pedir para o agente abrir a URL e relatar o resultado

Para comparar com outros clientes, veja também o guia de Cursor + MCP e o roteiro de ChatGPT + Site no Ar. O setup muda, mas depois da conexão todos usam as mesmas file tools e o mesmo deploy.

Próximo passo

Faça o primeiro teste com uma página pequena e um slug descartável. Depois que conexão, edição, deploy e verificação estiverem previsíveis, você pode repetir o mesmo fluxo para cada landing page, proposta ou protótipo que sair do Gemini CLI.