MCP virou uma das peças centrais para quem está construindo com agentes de IA. Em 2026, o ponto já não é apenas entender a sigla. O que importa é saber onde o protocolo entra no fluxo de desenvolvimento, quais responsabilidades continuam com o produto e como evitar que uma integração poderosa vire uma automação sem controle.

O resumo curto: MCP é um padrão para conectar aplicações de IA a sistemas externos. Um agente pode ler contexto, chamar ferramentas, usar prompts reutilizáveis e devolver respostas com evidência. Para desenvolvedores web, isso muda o fim do trabalho: o agente deixa de parar no código e passa a operar etapas como build, upload, deploy e verificação.

Se você ainda está no primeiro contato, leia também O que é MCP e como ele está mudando o desenvolvimento web. Este guia assume que você já entendeu o conceito e quer saber como aplicar sem improviso.

O vocabulário que realmente importa

A documentação oficial do MCP descreve o protocolo como um padrão aberto para conectar aplicações de IA a sistemas externos. Na prática, três papéis aparecem em quase todo projeto:

Papel O que faz no fluxo
Host Aplicação onde a IA roda, como editor, terminal ou chat
Client Camada que mantém a conexão entre o host e um servidor MCP
Server Serviço que expõe ferramentas, recursos e prompts para aquele client

O servidor é onde você transforma uma capacidade real em contrato para agentes. Pode ser um servidor local que lê arquivos, ou um servidor remoto que publica um site, consulta analytics ou cria um recurso externo.

Para desenvolvedores, a pergunta boa não é “meu app tem MCP?”. A pergunta é: “qual parte do fluxo eu posso expor como ferramenta com entrada, saída, permissão e erro bem definidos?”.

Tools, resources e prompts

MCP organiza capacidades em primitivas. As três mais úteis para começar são:

Primitiva Use quando o agente precisa…
Tools executar uma ação, como publicar, consultar ou alterar
Resources ler contexto, documentação, estado ou limites
Prompts seguir um modelo reutilizável de tarefa

Um erro comum é tentar transformar tudo em tool. Nem tudo precisa ser uma ação. Regras de plano, documentação de publicação, formato de pacote e limites operacionais podem ser resources. Um roteiro de primeiro deploy pode ser prompt. A tool deve ficar para o que muda estado ou consulta um sistema de forma estruturada.

No Site no Ar, por exemplo, o agente não precisa adivinhar como publicar arquivos. A documentação de Publicação define o contrato: get_context, conteúdo em public/, edição pelas file tools, deploy e acompanhamento até o estado final.

O que mudou para desenvolvedores em 2026

O MCP saiu do laboratório porque os agentes passaram a trabalhar em fluxos completos. Um assistente que só escreve código ajuda. Um agente que escreve, roda validação, prepara pacote, publica e confirma a URL mexe no ciclo inteiro de entrega.

Isso cria quatro exigências técnicas:

  1. o servidor precisa expor ferramentas pequenas e previsíveis;
  2. o host precisa mostrar ao usuário quando uma ação sensível será chamada;
  3. o agente precisa lidar com erro sem inventar sucesso;
  4. a resposta final precisa trazer evidência, não só uma frase otimista.

A especificação do MCP reforça princípios de consentimento, controle do usuário, privacidade e cautela com tools. Esse ponto é essencial: uma tool de deploy, domínio ou compra de recurso externo não deve ser tratada como autocomplete.

Como pensar em segurança

Ao conectar um servidor MCP, você está entregando uma nova superfície operacional para um agente. O risco não vem apenas do modelo. Ele também vem de instruções maliciosas em arquivos, páginas, logs, issues, comentários ou documentação que o agente lê durante o trabalho.

Antes de liberar um fluxo, revise:

  • quais ferramentas podem alterar estado;
  • quais ferramentas precisam de confirmação humana;
  • quais dados o servidor retorna ao agente;
  • se a resposta da ferramenta contém segredos ou tokens;
  • se o agente consegue distinguir erro, pendência e sucesso;
  • se existe log suficiente para auditar a ação depois.

Para publicação de sites, a regra prática é simples: o agente pode preparar e executar, mas deve mostrar o que publicou. Pasta, slug, URL, status e verificação precisam aparecer na resposta final.

Como escolher um primeiro caso de uso

O melhor primeiro uso de MCP não é o fluxo mais ambicioso. É o menor fluxo que remove uma etapa repetitiva e tem resultado fácil de verificar.

Bons candidatos:

  • consultar documentação interna do projeto;
  • listar ambientes ou recursos disponíveis;
  • publicar uma página estática pequena;
  • verificar status de deploy;
  • buscar logs de uma implantação;
  • criar um domínio em modo assistido, com confirmação antes de alterar DNS.

Evite começar por operações destrutivas, compra de recursos, troca automática de domínio de produção ou deploy sem checklist. Essas ações podem existir, mas só depois que o time confia no padrão de permissão, resposta e auditoria.

O exemplo do Site no Ar

O Site no Ar é um exemplo focado: ele expõe publicação de sites para agentes. O endpoint remoto é https://mcp.sitenoar.dev, e a configuração está documentada em Configuração.

O fluxo esperado é concreto:

  1. o agente chama get_context e identifica o Site;
  2. confirma que existe public/index.html;
  3. cria ou escolhe um Site;
  4. edita os arquivos na Session;
  5. chama deploy;
  6. acompanha o deploy;
  7. retorna a URL final;
  8. informa qualquer bloqueio de assinatura, plano, slug ou arquivo.

Isso funciona bem porque a ferramenta tem fronteira clara. Ela não tenta decidir a estratégia da landing, nem promete conversão, nem substitui revisão visual. Ela transforma arquivos prontos em uma URL verificável.

Um prompt bom para testar MCP

Use um pedido pequeno para validar a conexão:

Use o MCP do Site no Ar para testar a publicação de uma página estática.


1. Crie um index.html simples em uma pasta temporária do projeto.
2. Publique com o slug mcp-teste-dev.
3. Acompanhe o deploy até o estado final.
4. Abra ou verifique a URL publicada.
5. Responda com slug, URL, status e qualquer limitação encontrada.


Se precisar de login, assinatura ou aprovação antes de publicar, pare e explique.

Esse prompt testa a parte importante: conexão, permissão, pacote, upload, deploy e verificação. Depois que isso passa, você pode aplicar o mesmo contrato a páginas reais.

Como avaliar uma integração MCP

Antes de usar um servidor MCP em trabalho recorrente, faça uma revisão objetiva:

Critério Pergunta de revisão
Escopo A ferramenta faz uma coisa clara ou mistura responsabilidades?
Entrada O schema impede pedidos ambíguos?
Saída A resposta permite verificar o resultado?
Erros Falhas voltam como estado útil ou texto genérico?
Permissão Ação sensível pede confirmação do usuário?
Auditoria Dá para rastrear o que foi chamado e quando?

Se uma integração falha nesses pontos, o agente pode até parecer produtivo, mas o fluxo fica frágil. MCP bom deixa o trabalho mais explícito, não mais opaco.

O que desenvolvedores devem evitar

Alguns atalhos parecem rápidos e cobram caro depois:

  • colocar bytes de .zip ou imagens no contexto do modelo;
  • depender de texto livre para representar estado de deploy;
  • expor uma tool genérica demais, como execute qualquer comando;
  • publicar sem confirmar pasta, slug e arquivo inicial;
  • deixar domínio próprio no mesmo passo do primeiro deploy;
  • tratar uma resposta sem URL verificável como publicação concluída.

O contrato precisa proteger o usuário e o produto. Um agente com acesso a ferramentas deve ser mais auditável que um humano fazendo tudo manualmente, não menos.

Próximo passo

Se você quer aplicar MCP em publicação web, comece com um site estático pequeno. Configure o servidor em Configuração, siga o contrato de Publicação e compare a resposta final com o checklist deste guia.

Depois disso, evolua para fluxos com mais contexto: Codex + MCP, Cursor + MCP ou Como configurar um servidor MCP para publicação automática de sites. O objetivo não é ter mais automação por si só. É ter automação que você consegue explicar, repetir e verificar.