mcp-or-webhook | MCP ou webhook: qual deles você realmente precisa
O MCP é requisição e resposta: um assistente chama uma ferramenta quando uma pessoa pede. O webhook tem o formato oposto, em que a Meta entrega um evento e o seu sistema decide o que fazer. Nada que reaja automaticamente pode ser construído só com MCP.
Caminhos de integração que um número conectado oferece: MCP e webhook.
Maneiras de uma mensagem recebida disparar um servidor MCP.
A ferramenta MCP que configura o outro caminho.
Por que o MCP não consegue responder a um cliente automaticamente?
Porque o protocolo não tem mecanismo para ser acordado.
Um servidor MCP expõe ferramentas que um cliente chama. A chamada nasce no assistente, que por sua vez está respondendo a uma pessoa. Não existe direção de entrada: nada no fato de um cliente mandar uma mensagem de WhatsApp consegue alcançar um assistente e fazer com que ele aja. Isso vale para todo servidor MCP em todo produto, e não é uma limitação do nosso.
Então a pergunta que todo comprador acaba fazendo, se uma IA consegue responder aos clientes de madrugada, tem resposta de webhook, e não de MCP. A Meta entrega a mensagem para um sistema que você mantém, e esse sistema decide o que fazer, o que muito bem pode incluir chamar um modelo.
Para que cada caminho é genuinamente bom?
O MCP é para o trabalho que uma pessoa está fazendo. Qual dos meus números está com problema, manda para este cliente a confirmação dele, cria um template para avisos de pedido, aponta o número deste cliente para o meu servidor. Cada uma dessas coisas começa com alguém pedindo, e cada uma é mais rápida por um assistente do que por um painel.
O webhook é para tudo que precisa acontecer sem ninguém presente. Primeira resposta fora do horário, encaminhamento para a pessoa certa, registro num CRM, disparo de um fluxo.
A propriedade útil é que o MCP consegue configurar o webhook. O get_connect_link produz o link que um cliente abre, e o set_webhook_destination aponta o número dele para o seu sistema, então um agente pode fazer o onboarding do caminho que ele mesmo não consegue servir.
Quais ferramentas falam o quê?
Assistentes falam MCP: Claude, ChatGPT, Cursor, Claude Code. Plataformas de automação em geral não falam, e a distinção não é a que as pessoas esperam.
Make e Zapier rodam servidores MCP próprios, expondo as ações deles para assistentes. Nenhum dos dois age como cliente MCP, então nenhum consegue chamar o nosso. Para eles, a integração é um webhook e uma chamada HTTP.
O n8n é a exceção. O MCP Client Tool dele conecta a um servidor remoto e suporta OAuth2, então um nó de agente dentro de um fluxo do n8n pode chamar nossas ferramentas direto. Mesmo ali o fluxo ainda começa com um webhook, porque essa é a única coisa que reage.
Erros comuns
- Comprar MCP esperando respostas automáticas. Ele age quando é chamado, e nada o chama às 3 da manhã.
- Achar que uma plataforma com servidor MCP consegue consumir um. Make e Zapier expõem, eles não consomem.
- Construir os dois caminhos para fazer o mesmo trabalho. Eles são para metades diferentes do mesmo sistema.
O conector inclui o set_webhook_destination, então o caminho do assistente consegue configurar o caminho da automação sem ninguém abrir um painel.
Perguntas frequentes
Um assistente consegue vigiar o meu WhatsApp?
Não. Nada consegue empurrar um evento para dentro de um servidor MCP. Vigiar é webhook, e o webhook pode então chamar um modelo.
Preciso dos dois?
A maioria dos sistemas reais usa os dois: MCP para o trabalho que as pessoas fazem, e o webhook para tudo que acontece sem elas.
O Zapier consegue usar o servidor MCP de vocês?
Não. O Zapier é um servidor MCP e não um cliente, então não tem como chamar o nosso.
E o n8n?
Consegue, pelo MCP Client Tool com OAuth2. Das três, é a plataforma de automação que consegue.
Continue lendo
Pronto para começar?
Configure o WhatsApp Coexistence em minutos, não em meses. O aplicativo continua funcionando no celular.
Começar teste grátisVerificado em