Sites prontos para agentes em 2026: o que realmente envolve a construção de um WebMCP

Resumo. O Google abriu o teste de origem do WebMCP a partir do Chrome 149, que alcançou a versão estável em 2 de junho de 2026, e revisou pela última vez a documentação em 7 de agosto de 2026. Até que um site o adote, um agente de navegador completa uma tarefa em seu checkout da única maneira que pode: lendo o DOM e simulando cliques. O Adobe Analytics, cobrindo mais de 1 trilhão de visitas a sites de varejo dos EUA, registrou um aumento de 393% no tráfego originado por IA ano após ano no primeiro trimestre de 2026, convertendo 42% melhor do que o tráfego não-AI em março de 2026, a partir de uma temporada de férias de 2025 que gerou um recorde de $257,8 bilhões em gastos online nos EUA, com o tráfego de IA subindo 693,4%. O Adobe também avaliou a média das páginas de produtos de varejo dos EUA em 66% de legibilidade para máquinas, contra 75% para as páginas iniciais. Dois fatos definem o escopo do trabalho: anotar um formulário HTML existente requer dois atributos, e uma descrição de ferramenta tem um orçamento recomendado de 500 caracteres. Este artigo expõe o que envolve uma construção pronta para agentes, em que ordem, e onde deixa de ser uma questão de engenharia.

O problema, declarado sem exageros

Um agente de IA atuando em nome de um usuário dentro de um navegador não tem uma visão privilegiada de sua aplicação. A documentação do Google chama a abordagem atual de atuação: "o ato de um agente simulando cliques manuais do mouse e entrada de texto, como se fosse o usuário humano interagindo com seu site." O agente lê sua página, forma uma teoria sobre qual controle faz o que e age com base nessa teoria.

Isso funciona até que não funcione. Um botão renomeado, um novo intersticial, uma variante em um teste A/B, um campo que aparece apenas após outro campo ser preenchido, e a teoria do agente quebra. Nada gera erro. A tarefa é completada silenciosamente de forma errada ou não é completada, e você não tem telemetria que diga isso.

O WebMCP muda o contrato. Sua página registra ferramentas nomeadas com um JSON Schema, e o agente chama checkout ou filter_results em vez de adivinhar. A própria formulação do Google sobre por que isso sobrevive a uma reformulação é a parte comercialmente importante: as ferramentas do WebMCP "conectam-se à lógica da aplicação, não ao design", portanto, enviar um novo front-end não quebra a compatibilidade do agente.

Para um negócio, essa é a diferença entre uma capacidade que você constrói uma vez e uma superfície que regrede a cada lançamento.

Isso é urgente ou é trabalho para 2027?

Resposta honesta: depende de onde vem seu tráfego, e a melhor medição disponível é a americana.

Os dados da Adobe são a série pública mais forte. O tráfego originado por IA para sites de varejo dos EUA cresceu 393% ano após ano de janeiro a março de 2026 e 269% ano após ano apenas em março de 2026. O quadro de conversão se inverteu em um ano: o tráfego de IA converteu 38% pior do que o tráfego não-AI em março de 2025, e 42% melhor até março de 2026. O engajamento foi 12% maior, o tempo no site 48% mais longo e as páginas por visita 13% maiores.

"Nesta temporada de férias de 2025, os consumidores abraçaram a IA generativa mais do que nunca como assistente de compras em suas decisões de compra", disse Vivek Pandya, analista chefe, Adobe Digital Insights, no resumo da temporada da Adobe em 7 de janeiro de 2026.

Não temos uma série equivalente específica da Índia, e não vamos inventar uma. O que é observável é que as sessões originadas por agentes são uma parte menor do tráfego indiano hoje do que os números dos EUA da Adobe implicam, e que a direção é a mesma. Isso produz uma recomendação específica em vez de um pânico: faça a parte barata agora, adie a parte cara até que suas próprias análises a justifiquem.

A primeira linha é o ponto. Dois atributos HTML em um formulário que você já envia o tornam uma ferramenta chamável, e o navegador deriva o JSON Schema de seus nomes de campo, atributos required e opções de <select>. Isso é uma parte genuinamente pequena do trabalho com um retorno genuinamente assimétrico.

O que a construção realmente envolve

Um inventário, antes de qualquer código. Liste as tarefas que um usuário completa em seu site, marque quais já existem como um formulário HTML e marque quais um agente plausivelmente tentaria em nome de um usuário. No comércio eletrônico, isso geralmente é pesquisa, filtragem, consulta de pedido, solicitação de suporte, início de devoluções e atualização de conta. O checkout está em sua própria categoria.

Uma auditoria de bloqueadores. O WebMCP funciona apenas em documentos isolados por origem. Se uma página habilitar document.domain, por exemplo, enviando o cabeçalho Origin-Agent-Cluster: ?0, as APIs são desativadas completamente. Pilhas de comércio eletrônico indianas mais antigas com scripting entre subdomínios de uma loja e um subdomínio de conta atingem isso imediatamente, e não é uma correção do WebMCP, é uma correção da arquitetura do front-end. Encontrá-lo na primeira semana é muito mais barato do que encontrá-lo na sexta semana.

A passagem declarativa. Adicione toolname e tooldescription aos formulários existentes, e então verifique cada esquema derivado. Um <select> com rótulos de opções vagos produz um enum vago, e a precisão do agente se degrada de acordo. É aqui que uma quantidade surpreendente do valor reside, e é um trabalho de conteúdo tanto quanto de engenharia.

A passagem imperativa. Escreva ferramentas JavaScript para fluxos sem formulário: navegação, mudanças de estado, consultas de dados. Cada ferramenta carrega um nome, uma descrição, um esquema de entrada e uma função execute, além de anotações. readOnlyHint informa a um agente que a ferramenta não muda o estado, para que ele possa reservar confirmações para aquelas que mudam. untrustedContentHint rotula um payload como não confiável, o que o Google recomenda para qualquer coisa que retorne dados gerados pelo usuário ou de fontes externas.

A cópia. O Google publica orçamentos de caracteres: 500 caracteres por descrição de ferramenta, 150 por descrição de parâmetro, 30 caracteres cada para nomes de ferramentas e parâmetros, e 1,5K caracteres por saída de ferramenta. Escrever uma descrição de ferramenta que seja inequívoca dentro de 500 caracteres é a tarefa que decide se um agente escolhe sua ferramenta ou recua para clicar por aí. As equipes consistentemente subestimam isso e consistentemente descobrem que é o gargalo.

A revisão de segurança. A orientação do Google é clara sobre o risco: porque modelos de linguagem tratam texto, instruções e dados do usuário como uma sequência de tokens, eles estão abertos a injeção de prompt indireta, e é impossível garantir segurança dentro de um modelo probabilístico. Os próprios caçadores de bugs do Google documentaram ataques de injeção de prompt repetíveis contra sistemas agentes. Qualquer ferramenta que retorne conteúdo que você não escreveu precisa da dica de não confiável e de uma análise cuidadosa do que um atacante poderia fazer com isso.

O checkout merece seu próprio parágrafo

A API declarativa tem dois modos de envio. Por padrão, o agente preenche o formulário e o usuário clica em Enviar, o que mantém um humano no loop.