Na semana passada apareceu em todo lugar o mesmo assunto: Web MCP. Eu cheguei nele por um vídeo do Lucas Montano, que implementou no produto dele e mostrou funcionando. O conteúdo é bom e a demonstração é honesta.
A reação natural de quem tem site é a mesma que eu tive: preciso implementar isso. Antes de escrever uma linha, fui medir. E o resultado me fez decidir o contrário.
O que é Web MCP, sem hype
Hoje, quando um agente de IA precisa usar um site, ele age como uma pessoa muito paciente e um pouco cega: lê o HTML, tenta descobrir onde fica o botão, tira uma captura da tela, decide onde clicar, clica, tira outra captura. Repete.
Isso quebra por motivos bobos. O botão foi renderizado por JavaScript depois que o agente já tinha lido a página, então ele não acha o botão que está bem ali. E cada volta desse ciclo custa token, ou seja, custa dinheiro.
Web MCP inverte o arranjo. O site publica um contrato dizendo quais ações existem, quais campos cada uma aceita e o que cada uma devolve. O agente lê o contrato e chama a ação. Some a adivinhação, some a captura de tela, some o loop.
O argumento técnico é sólido. Não é isso que está em discussão aqui.
Fui medir o meu site antes de implementar
Três números, todos do meu próprio código:
- 53 arquivos já expõem dado estruturado em JSON-LD. A camada legível por máquina não é novidade aqui, ela já existe e já é usada.
- Das ferramentas que tenho publicadas, só duas têm motor no servidor: o Audit-X e o VisSite. Todo o resto roda dentro do navegador do visitante, por decisão de privacidade. E o que roda no navegador da pessoa não tem como ser chamado por um agente.
- Essas duas já responderiam a um agente hoje. Os endpoints recebem JSON e devolvem JSON, que é exatamente a forma de uma ferramenta de agente.
Esse terceiro item merece um parágrafo, porque foi um acidente feliz.
O portão que eu escrevi sem saber que servia pra isso
Meses atrás fechei uma brecha nos dois endpoints. Qualquer site de terceiro conseguia fazer os visitantes dele dispararem auditorias no meu servidor, porque um POST sem cabeçalho de tipo é uma requisição simples: o navegador manda sem pedir licença antes, e o servidor executa mesmo que a resposta seja jogada fora.
A correção foi exigir Content-Type: application/json, o que obriga o navegador a pedir licença antes, mais uma checagem de origem. E eu escrevi na época, no comentário do arquivo, uma frase que só fez sentido agora:
a proteção é contra navegador de vítima, não contra ferramenta de linha de comando, que não tem sessão de ninguém para emprestar.
Ou seja: um agente rodando no servidor dele, chamando o meu endpoint com JSON, passa. Eu não precisava construir nada. A porta já estava aberta pro tipo certo de cliente e fechada pro tipo errado.
Implementar Web MCP aqui seria um invólucro fino, não uma reescrita. Custo baixo. E mesmo assim eu não implementei.
O motivo: multiplicador não cria demanda
Web MCP é um multiplicador. Ele melhora a interação de um agente que já chega até você. Ele não faz agente nenhum descobrir que o seu site existe.
Ninguém manda um agente num site que não conhece. O agente vai onde a pessoa mandou, e a pessoa manda para onde ela já sabe ir. Então a pergunta que decide não é "quanto custa implementar", é "quanto tráfego de agente eu tenho para multiplicar".
No meu caso, e provavelmente no seu, a resposta honesta é: não sei, e o número mais provável é zero. Web MCP hoje seria uma porta muito bem feita num prédio cujo endereço ninguém sabe.
As quatro perguntas antes de você implementar
Este é o teste que eu usei. Ele funciona pro seu site também, e as quatro têm resposta objetiva.
1. Chega agente no seu site hoje?
Isso não se responde por opinião, se responde pelo log do servidor. Uma linha:
grep -icE 'GPTBot|ClaudeBot|PerplexityBot|OAI-SearchBot' access.logSe der zero, você acabou de economizar uma semana de trabalho. Um detalhe importante: se você mede visita por script de analytics, ele não vai ver agente nenhum, porque agente não executa o JavaScript da sua página. O log cru do servidor é o único lugar onde essa resposta existe.
2. Sua funcionalidade roda no servidor ou no navegador?
Agente só consegue chamar o que está no servidor. Se a sua ferramenta é client-side, expor por Web MCP significa reescrever o motor inteiro do outro lado. Isso deixa de ser um invólucro e vira um projeto.
Faça a conta antes de se animar. A minha deu duas de todas.
3. O seu endpoint aceita quem não é navegador?
Aqui mora uma armadilha comum: muita proteção contra requisição forjada barra o agente junto, e barra em silêncio. Se a sua defesa exige cookie de sessão, token embutido na página ou cabeçalho que só navegador manda, o agente leva 403 e você nunca fica sabendo.
Vale conferir isso antes de escrever o contrato, porque é o tipo de coisa que faz a implementação parecer pronta e não funcionar.
4. Você tem o que multiplicar?
A pergunta que engloba as outras três. Se a resposta da primeira foi zero, as outras são exercício.
O que o próprio vídeo diz e quase ninguém comentou
Perto do fim, depois de mostrar a implementação funcionando, o Lucas diz uma coisa que contraria o título: que Web MCP não o deixa tão otimista quanto os conectores dentro do agente. E aí ele mostra o produto dele aparecendo como conector no Claude, com o agente abrindo o aplicativo sozinho.
São dois movimentos opostos, e vale separar bem:
- Web MCP: você espera o agente vir até o seu site.
- Conector: você vai até onde a pessoa já trabalha.
O segundo não depende de você já ter tráfego, e é por isso que ele é o mais interessante para quem ainda está construindo audiência. Achei sintomático que a parte mais forte do vídeo seja justamente a que não está no título.
O gatilho que eu escrevi no lugar da implementação
Não descartei a ideia, adiei com critério escrito. Implemento no dia em que qualquer um dos dois acontecer:
- Aparecer agente no log do servidor. É a mesma linha da pergunta 1, rodada de vez em quando.
- Um cliente perguntar se o site dele funciona com agente. Aí deixa de ser uma funcionalidade que eu adivinho e vira uma demanda que alguém pediu.
Decisão adiada com gatilho não é a mesma coisa que decisão engavetada. A diferença é que existe um evento definido que a reabre, em vez de ela depender de eu lembrar.
A leitura que vale mais que a implementação
Se agente comprando e resolvendo coisa pelo site virar mesmo o padrão, aparece uma pergunta nova na vida de quem tem negócio: o meu site é legível por agente?
Isso é um item de auditoria, não um item de moda. E é bem mais útil saber checar do que ter implementado cedo pelo motivo errado.
É a mesma lógica dos cabeçalhos de segurança, do certificado e da política de privacidade: a maioria dos sites vai descobrir que está fora do padrão quando alguém for medir. Prefiro estar do lado de quem sabe medir.
O Audit-X lê o que o seu site expõe publicamente e devolve um laudo em português. É gratuito, não pede cadastro e roda em segundos.
Tirar uma chapa do meu site →
Se o que você quer é a vistoria completa, incluindo o percurso que o visitante percorre até virar contato, é o VisSite que faz isso.
Este post faz parte do guia como trabalhar com um agente de IA, onde estão as outras peças: skills, memória, custo e segurança.