MCP é a sigla para Model Context Protocol, um padrão aberto que permite conectar aplicações de IA a sistemas externos. Em vez de cada agente precisar de uma integração exclusiva para cada serviço, o MCP cria uma forma comum de expor ferramentas, dados e fluxos para clientes compatíveis.

No desenvolvimento web, isso muda uma parte específica do trabalho: a IA deixa de ser apenas uma geradora de texto ou código e passa a operar ferramentas reais com permissões claras. Ela pode consultar contexto, chamar ações, acompanhar status e devolver evidência do que fez.

Essa diferença importa quando o trabalho não termina no arquivo. Um site gerado por IA ainda precisa virar uma URL pública, com index.html, assets, slug, domínio e verificação. É nesse ponto que o MCP começa a parecer menos uma novidade técnica e mais uma peça de infraestrutura.

O que MCP resolve

Sem MCP, cada integração entre um agente e um serviço tende a virar um caminho próprio:

  • um plugin específico para um cliente;
  • uma API chamada manualmente por script;
  • um token colado em configuração local;
  • um passo final que o humano precisa executar fora da conversa.

Com MCP, a relação fica mais padronizada. Um servidor MCP expõe capacidades. Um cliente MCP, dentro de um host como um editor, terminal ou app de IA, descobre essas capacidades e permite que o agente as use.

A documentação oficial do MCP descreve o protocolo como um padrão para conectar aplicações de IA a sistemas externos. Na prática, isso significa que a IA pode trabalhar com fontes de dados, ferramentas executáveis e prompts reutilizáveis sem cada produto inventar um contrato diferente do zero.

Para quem cria sites com IA, a consequência é simples: o agente pode sair do papel de “autor do HTML” e entrar no papel de “operador do fluxo”. Ele cria, revisa, empacota, publica e confirma o resultado.

Os participantes do MCP

O vocabulário básico ajuda a entender o fluxo:

Nome Papel no fluxo
Host Aplicação onde a IA roda, como um editor, terminal ou chat com suporte a MCP
Client Componente que mantém a conexão entre o host e um servidor MCP
Server Programa que expõe ferramentas, recursos e prompts para o cliente

Um host pode se conectar a vários servidores. Um servidor pode ser local, rodando na sua máquina, ou remoto, acessado por HTTP. A documentação de arquitetura do MCP separa ainda duas camadas: a camada de dados, baseada em JSON-RPC, e a camada de transporte, responsável pelo canal de comunicação e autenticação.

Essa separação é o que permite o mesmo conceito funcionar em cenários diferentes. Um agente pode usar stdio para falar com um servidor local de arquivos, ou usar Streamable HTTP para falar com um servidor remoto de publicação.

Tools, resources e prompts

MCP organiza as capacidades em primitivas. As três mais importantes para quem está começando são:

Primitiva Para que serve
Tools Ações executáveis que o agente pode chamar
Resources Fontes de contexto que o agente pode ler
Prompts Modelos reutilizáveis para orientar uma tarefa

No desenvolvimento web, uma tool pode criar um Site, ler ou escrever arquivos, iniciar um deploy ou checar analytics. Um resource pode explicar limites de plano, regras de domínio ou contrato de publicação. Um prompt pode guiar o agente no primeiro publish.

O ponto importante é que o agente não precisa adivinhar tudo. Ele descobre ferramentas disponíveis, lê descrições, usa schemas de entrada e recebe respostas estruturadas. Isso não elimina erro, mas reduz improviso.

Como isso muda o desenvolvimento web

Antes dos agentes, o fluxo típico era:

  1. escrever ou gerar código;
  2. rodar build;
  3. abrir uma plataforma de hospedagem;
  4. criar projeto;
  5. enviar arquivos;
  6. copiar a URL;
  7. voltar para a conversa ou tarefa original.

Com um servidor MCP de publicação, o fluxo pode ficar mais direto:

  1. definir objetivo, pasta e slug;
  2. pedir ao agente para criar ou ajustar o site;
  3. rodar build e validações;
  4. publicar pelo servidor MCP;
  5. acompanhar o deploy;
  6. devolver URL, slug e evidência.

O ganho não está em fingir que deploy virou magia. O ganho está em colocar a etapa final no mesmo contrato operacional do restante do trabalho.

Se o agente já sabe editar arquivos, rodar comandos e revisar o resultado, faz sentido que ele também consiga publicar a pasta correta quando existe uma ferramenta segura para isso.

Onde o Site no Ar entra

O Site no Ar é um destino de publicação para sites gerados por IA. Ele entra como servidor MCP remoto em https://mcp.sitenoar.dev. Depois de configurado e autenticado, o agente pode criar ou escolher um Site, editar arquivos, iniciar o deploy e acompanhar o status.

O contrato de publicação é baseado em arquivos:

  • index.html é a página inicial;
  • outros arquivos .html viram rotas;
  • CSS, JavaScript, imagens e fontes preservam seus caminhos;
  • páginas e assets ficam sob public/, preservando seus caminhos;
  • a URL final deve ser verificada antes de ser compartilhada.

Esse contrato é deliberadamente concreto. Ele evita que o agente “publique” uma ideia abstrata. O que vai ao ar é a Version criada a partir dos arquivos do Site, e o usuário consegue auditar a alteração.

Para conectar um cliente compatível, comece pela configuração do MCP. Para entender o fluxo depois que o servidor já está conectado, leia também Codex + MCP: o fluxo completo de criação e publicação de sites.

O que não muda

MCP não transforma qualquer projeto em deploy automático. Ainda existem decisões que precisam estar explícitas:

  • quais arquivos serão mantidos sob public/;
  • se public/index.html está presente;
  • qual slug deve ser usado;
  • se há domínio próprio;
  • se a conta tem assinatura e limites disponíveis;
  • se a página final abriu corretamente.

Também não substitui revisão de produto. Um agente pode publicar uma landing ruim com a mesma eficiência com que publica uma landing boa. O protocolo melhora a ponte entre IA e ferramenta, não garante estratégia, copy, acessibilidade ou conversão.

A melhor prática é tratar MCP como uma camada de execução verificável. O agente pode fazer mais, mas deve mostrar o que fez.

Exemplo de pedido bem formado

Um pedido fraco seria:

Crie uma landing e coloque no ar.

Um pedido melhor:

Crie uma landing page estática para validar uma consultoria de automação.
Use HTML, CSS e JavaScript simples.
O arquivo principal precisa ser index.html.
Depois publique pelo MCP do Site no Ar.
Slug desejado: consultoria-automacao-demo.
Antes de publicar, confirme a pasta ou arquivo que será enviado.
Depois me devolva a URL final e diga se a página abriu corretamente.

Esse prompt dá ao agente o contrato mínimo: formato, arquivo, destino, slug e verificação.

Por que isso está mudando agora

Agentes já conseguem criar páginas inteiras, mas o valor real aparece quando o fluxo fica repetível. MCP ajuda porque cria uma camada comum entre cliente de IA e serviço externo. Para o desenvolvedor, isso reduz integrações artesanais. Para o usuário, isso transforma “gere o site” em “gere, publique e me mostre onde ficou”.

O próximo passo natural é operacionalizar. Escolha um cliente compatível, conecte o servidor MCP, publique um site pequeno e veja a resposta final do agente. Ela deve conter URL, slug, status do deploy e qualquer bloqueio encontrado.

Se a resposta não trouxer evidência, peça a verificação. Publicação com agente só é útil quando termina em uma URL que alguém pode abrir.