Como publicar sites direto do Cursor sem sair do editor

Publicar sem trocar de contexto

Cursor é forte quando o agente já está dentro do código: ele lê arquivos, altera componentes, roda comandos e entende a estrutura do projeto. O problema aparece quando a última etapa exige sair do editor, abrir uma plataforma de hospedagem e transformar a pasta final em uma URL pública.

Com o MCP do Site no Ar configurado, esse fim de fluxo fica dentro da própria conversa. O Cursor pode preparar a build, publicar os arquivos e devolver o link final para você conferir.

Isso não elimina revisão. Publicar sites direto do Cursor sem sair do editor significa reduzir troca de ferramenta, não abandonar critérios de qualidade. O pedido ainda precisa dizer qual pasta vai para o ar, qual slug usar e como verificar a página publicada.

Configure o MCP no Cursor

O Cursor aceita servidores MCP remotos em mcp.json. Você pode configurar para todos os projetos em ~/.cursor/mcp.json ou apenas no projeto atual em .cursor/mcp.json:

{
  "mcpServers": {
    "sitenoar": {
      "url": "https://mcp.sitenoar.dev"
    }
  }
}

Depois, recarregue o Cursor ou abra as configurações de MCP. Quando o Cursor pedir autorização, entre no Site no Ar pelo fluxo do próprio editor.

O guia de Cursor mantém esse passo a passo. A página de configuração lista também os caminhos para Claude Code, Codex, Gemini CLI, ChatGPT, OpenCode e outros clientes.

Faça uma checagem antes do primeiro publish

Antes de publicar um projeto real, peça uma checagem simples:

Use o MCP do Site no Ar.
Faça uma checagem da conexão.
Se estiver tudo certo, responda:
"Conexão pronta. Reinicie seu agente para carregar o MCP do Site no Ar."

Se aparecer erro de autenticação, refaça o login no painel de MCP do Cursor. Se o servidor não carregar na conversa atual, reinicie o agente para garantir que a ferramenta esteja disponível.

Essa etapa é pequena, mas economiza tempo. É melhor descobrir um problema de conexão antes do agente rodar build, organizar arquivos e chegar ao momento de upload.

Prepare a pasta publicável

Quando o site estiver pronto, peça para o Cursor confirmar a saída antes de publicar:

Revise este projeto e identifique a pasta publicável.
Se precisar rodar build, use o comando padrão do projeto.
Confirme onde está o index.html final.
Confira se CSS, JS, imagens e fontes usados pela página
estão dentro da mesma pasta de publicação.
Não publique ainda.

Esse pedido separa preparação de publicação. O Cursor primeiro valida o que vai para o ar; depois você decide se a pasta está correta.

Em projetos estáticos simples, a pasta publicável pode ser a própria pasta dos arquivos. Em frameworks, normalmente será dist, build ou outro diretório gerado por build. O importante é não deixar o agente adivinhar.

Prompt pronto para publicar no Cursor

Com a pasta confirmada, use um pedido direto:

Publique este site pelo MCP do Site no Ar.

Pasta publicável: ./dist
Slug desejado: cursor-demo
Use index.html como página inicial.
Depois acompanhe o deploy e abra a URL final.

Na resposta, informe:
- arquivos alterados;
- slug usado;
- URL final;
- status do deploy;
- resultado da verificação.

Esse formato funciona para landing pages, portfolios, páginas de campanha, demos estáticas e protótipos navegáveis. Ele também reduz erro de escopo: o agente sabe de onde sair, para onde enviar e como encerrar a tarefa.

O que o Site no Ar espera receber

O contrato de publicação é o mesmo do painel:

• index.html é obrigatório para a home e vira /;
• outros arquivos .html viram rotas públicas;
• CSS, JavaScript, imagens e fontes ficam como assets;
• o deploy deve ser acompanhado até um estado final;
• a URL final precisa abrir fora do ambiente local.

Se a página publicada abrir sem estilos, o problema geralmente não está no MCP em si. Normalmente falta algum asset na pasta de publicação ou o HTML aponta para caminhos que existiam apenas no ambiente local.

Peça para o Cursor corrigir a pasta e republicar no mesmo Site quando a intenção for atualizar o link existente.

Como manter controle dentro do editor

Como o Cursor facilita mudanças rápidas, vale declarar limites no pedido:

• se o agente pode escolher outro slug caso o primeiro esteja ocupado;
• se deve pedir aprovação antes de publicar;
• se deve manter o mesmo Site em republicações;
• se pode remover arquivos antigos que não aparecem na nova build;
• se domínio próprio deve ficar para depois;
• se warnings não críticos bloqueiam o publish.

Para uma entrega de cliente, use uma etapa de aprovação:

Prepare o publish e mostre o plano.
Não envie os arquivos ainda.
Depois que eu aprovar, publique no Site no Ar.

Para um rascunho interno, você pode deixar o agente publicar e verificar em um único ciclo.

Quando esse fluxo é mais útil

Publicar direto do Cursor faz sentido quando a revisão e a edição já estão acontecendo no editor:

• ajustar uma landing page com o agente e compartilhar a URL em seguida;
• publicar uma página de campanha que muda várias vezes no mesmo dia;
• mostrar um protótipo navegável para alguém fora do repositório;
• entregar uma página estática para cliente sem abrir painel de hospedagem;
• comparar variações usando slugs separados.

Se o projeto precisa de banco de dados, autenticação, jobs, APIs próprias ou segredos de runtime, trate isso como arquitetura de aplicação. O Site no Ar é direto para HTML e assets; ele é especialmente útil quando o resultado publicável cabe nesse contrato.

O próximo passo no Cursor

Comece pela configuração do MCP em Cursor, faça a checagem de conexão e só então publique uma pasta pequena. Use um slug de teste, confirme que index.html virou a home e confira se os assets carregaram.

Depois que o primeiro fluxo estiver confiável, transforme o publish em parte natural da conversa: o Cursor altera os arquivos do Site, publica pelo MCP e devolve a URL final com verificação. Para entender o contrato de arquivos e Versions, leia também Publicação.