Cursor + MCP: como configurar o Site no Ar no seu workflow

O que muda quando o MCP entra no Cursor

Cursor já é um bom lugar para criar e revisar um site porque o agente está dentro do projeto. Ele lê arquivos, altera componentes, roda comandos e acompanha o estado do repositório. O problema aparece quando a última etapa vira uma troca de ferramenta: abrir painel de hospedagem, procurar a pasta certa, enviar arquivos e depois voltar para explicar o que foi publicado.

Configurar o Site no Ar via MCP resolve esse fim de fluxo. O Cursor continua cuidando do código, mas passa a ter uma ferramenta de publicação para criar ou escolher o Site, preparar o envio, acompanhar o deploy e devolver a URL final.

Isso não transforma publish em piloto automático. O workflow bom ainda declara pasta publicável, slug, arquivo inicial e critério de verificação. A diferença é que essas decisões ficam dentro da mesma conversa do editor.

Se você quer apenas o pedido final de publish, leia também Como publicar sites direto do Cursor sem sair do editor. Este guia foca na configuração e no jeito de encaixar o MCP na rotina.

Onde o MCP fica no workflow

Pense no MCP como a ponte entre o projeto local e a publicação. Ele não substitui build, revisão ou decisão de produto. Ele entra depois que o Cursor entende o projeto e antes de você compartilhar a URL.

Esse desenho evita uma confusão comum: o agente pode editar muita coisa no repositório, mas só deve publicar o que pertence à pasta de saída. Em projetos com framework, essa pasta costuma ser dist, build ou outra saída do comando de build. Em sites estáticos simples, pode ser a pasta onde estão index.html, CSS e assets.

Configure o Site no Ar no Cursor

O Site no Ar é um servidor MCP remoto. No Cursor, a configuração documentada usa mcp.json. Você pode registrar para todos os projetos em ~/.cursor/mcp.json ou manter a configuração só no repositório atual em .cursor/mcp.json:

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

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

A página de Cursor mantém esse bloco pronto. A documentação de configuração também lista os caminhos para outros agentes, caso o mesmo time use Claude Code, Codex, Gemini CLI ou ChatGPT.

Teste antes de publicar qualquer coisa

Faça uma checagem curta antes do primeiro deploy real. Dentro do Cursor, peça:

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."

Esse teste separa problema de conexão de problema de projeto. Se a autenticação falhar, você resolve login e MCP. Se a conexão funcionar, aí sim faz sentido pedir build, preparar arquivos e publicar.

Quando a resposta for positiva, reinicie o agente se o próprio Cursor precisar recarregar ferramentas. O ponto é começar o workflow de publicação com o MCP disponível, não descobrir no final que o servidor ainda não estava pronto.

Padronize o pedido de publicação

Depois que o MCP estiver configurado, use um prompt que deixe o Cursor decidir o que ele pode decidir e pare quando algo depender de você:

Publique este projeto pelo MCP do Site no Ar.

1. Revise o repositório e confirme qual pasta é publicável.
2. Rode o build padrão somente se for necessário.
3. Confirme que existe index.html na pasta final.
4. Publique pelo Site no Ar.
5. Slug desejado: minha-landing
6. Depois acompanhe o deploy e abra a URL final.

Na resposta, informe arquivos alterados, slug usado, URL final,
status do deploy e resultado da verificação.
Se houver bloqueio, pare e explique a próxima ação.

Esse formato força o agente a encerrar com evidência. A resposta útil não é “publiquei”; é uma lista curta dizendo o que foi enviado, onde ficou no ar e o que foi verificado.

O contrato de publicação é o mesmo usado pelo painel: index.html vira a home, outros arquivos .html viram rotas públicas e CSS, JavaScript, imagens e fontes continuam como assets no caminho enviado.

Coloque limites no workflow do Cursor

Cursor facilita iteração rápida, então vale declarar limites antes de publicar. Em um rascunho interno, talvez você aceite que o agente publique e verifique direto. Em uma entrega para cliente, talvez ele deva preparar o plano e esperar aprovação.

Use limites explícitos:

• se o agente pode escolher outro slug quando o primeiro estiver ocupado;
• se deve manter o mesmo Site ao republicar;
• se pode remover arquivos antigos que não aparecem na nova build;
• se domínio próprio fica para depois;
• se warnings de build bloqueiam o deploy;
• se a URL deve ser aberta e verificada antes da resposta final.

Para um fluxo com aprovação, peça:

Prepare o publish pelo MCP do Site no Ar e me mostre o plano.
Não envie os arquivos ainda.
Depois que eu aprovar, publique e verifique a URL final.

Essa instrução mantém velocidade sem esconder a decisão humana que ainda importa.

Quando configurar domínio próprio

No começo, publique pelo endereço do Site no Ar e valide a página. Depois, se o projeto precisar de marca própria, peça a configuração de domínio:

Configure www.minhaempresa.com para este Site e me diga quais registros DNS devo criar.

Domínio customizado envolve DNS e pode levar tempo para propagar. Por isso, trate como uma etapa separada do primeiro publish. O guia de domínios próprios explica o fluxo e os estados esperados.

Próximo passo

Depois que o Cursor estiver conectado, transforme publish em parte do ritual do projeto: criar, revisar, preparar saída, publicar, verificar e decidir se precisa republicar. O artigo Como criar e publicar uma landing page com Claude Code sem tocar em servidor serve como referência de escopo para landings, e o guia de publicação cobre o contrato de arquivos.

O ganho do Cursor + MCP + Site no Ar é reduzir a troca de contexto sem perder controle. O agente continua dentro do editor, mas a entrega termina com uma URL pública e verificável.