WebMCP: o que é e como funciona nos sites com agentes de IA

Durante muito tempo, construir um site significava pensar principalmente em pessoas.

A gente escolhia o menu, organizava os botões, desenhava os formulários e tentava deixar tudo intuitivo para que alguém conseguisse descobrir o que fazer sem precisar de um manual.

Isso continua sendo importante.

Só que surgiu um novo usuário para o qual a interface visual não é suficiente: o agente de inteligência artificial.

É nesse cenário que começa a aparecer o WebMCP, uma proposta de padrão para permitir que sites disponibilizem funções estruturadas diretamente para agentes de IA. Em vez de o agente precisar interpretar a interface, localizar um botão e simular uma sequência de cliques, o próprio site pode declarar quais ações estão disponíveis e como elas devem ser executadas. O Chrome descreve o WebMCP justamente como uma forma de expor ferramentas estruturadas para agentes, aumentando a precisão e a confiabilidade dessas interações.

Para quem trabalha com sites, isso merece atenção.

Ainda é cedo para dizer que o WebMCP vai se tornar um padrão dominante. A tecnologia está em fase experimental e continua evoluindo. Mas a direção que ela aponta é bastante interessante: a web começa a precisar ser compreensível não apenas para seres humanos, mas também para agentes que executam tarefas em nosso nome.

O que é WebMCP

WebMCP significa Web Model Context Protocol.

Apesar do nome parecido, ele não deve ser confundido com o MCP tradicional.

O WebMCP é uma proposta voltada para o navegador. Ele permite que uma página exponha determinadas funcionalidades como ferramentas que um agente de IA consegue descobrir e utilizar de maneira estruturada.

Imagine um site de uma agência que possui um formulário para agendar uma reunião.

Hoje, um agente poderia precisar interpretar a página, descobrir onde está o formulário, identificar os campos, preencher cada informação e clicar no botão correto.

Com WebMCP, o site pode declarar algo como:

“Tenho uma ferramenta chamada agendarReuniao. Ela precisa de data, horário, nome e e-mail.”

O agente recebe essa informação de maneira estruturada e pode chamar a função diretamente.

A documentação atual do Chrome mostra justamente esse modelo. Uma ferramenta WebMCP possui nome, descrição e um esquema que define os parâmetros esperados. O navegador disponibiliza essas ferramentas ao agente, que pode então executar a ação com argumentos estruturados.

A diferença parece pequena quando colocada dessa forma.

Na prática, ela pode ser bastante significativa.

O problema que o WebMCP tenta resolver

Hoje, agentes que navegam pela web podem precisar fazer algo parecido com o que uma pessoa faria.

Olhar a página.

Entender o que está acontecendo.

Localizar um campo.

Clicar.

Esperar.

Verificar o resultado.

Tentar novamente se alguma coisa der errado.

Esse processo é chamado de actuation na documentação do Chrome. O agente simula ações humanas, como cliques e entrada de texto, para realizar tarefas na interface. O problema é que cada etapa acrescenta uma possibilidade de interpretação incorreta.

Para uma tarefa simples, talvez isso não seja um grande problema.

Agora imagine um agente tentando reservar uma passagem aérea, fazer uma compra, preencher um cadastro ou concluir um processo dentro de um sistema empresarial.

Quanto mais etapas existirem, maior fica a superfície para erros.

O WebMCP tenta mudar a lógica.

Em vez de o agente descobrir sozinho que determinado botão aparentemente significa “finalizar compra”, o site pode declarar explicitamente que existe uma ferramenta para realizar aquela ação.

É uma mudança de interface para contrato.

O site passa a dizer ao agente, de maneira estruturada, quais operações estão disponíveis.

WebMCP e MCP não são a mesma coisa

Essa distinção merece atenção porque os nomes podem gerar bastante confusão.

O MCP tradicional é voltado para conectar modelos de IA a sistemas externos, dados, ferramentas e fluxos de trabalho. Ele normalmente funciona como uma camada de integração que permite ao agente acessar recursos de um sistema.

O WebMCP tem outra finalidade.

Ele foi pensado para a interação entre um agente de navegador e um site que está aberto naquele momento.

A própria documentação do Chrome coloca a diferença de maneira bastante clara: MCP atende a integrações mais amplas e persistentes, enquanto WebMCP prepara um site ativo para interação com agentes dentro do navegador.

Uma aplicação pode, inclusive, utilizar os dois.

O MCP pode cuidar da lógica de negócio, acesso a dados e operações de backend.

O WebMCP pode ajudar um agente a interagir com a interface web quando o usuário está dentro daquele site.

Isso é particularmente interessante porque evita tratar MCP e WebMCP como tecnologias concorrentes. Elas resolvem problemas diferentes.

O que muda para quem desenvolve sites

Aqui começa a parte que considero mais interessante.

Durante anos, desenvolvedores trabalharam com uma ideia bastante simples: a interface precisa ser compreensível para o usuário.

Isso continua valendo.

Mas agora existe uma segunda pergunta:

um agente de IA consegue entender o que este site permite fazer?

Essa pergunta pode mudar algumas decisões de arquitetura.

Um e-commerce, por exemplo, pode ter funções como:

• pesquisar produtos
• filtrar resultados
• consultar disponibilidade
• adicionar produtos ao carrinho
• alterar quantidade
• iniciar checkout
• acompanhar pedido

Hoje essas ações são apresentadas principalmente através da interface.

Com WebMCP, elas podem também ser descritas como ferramentas estruturadas que um agente consegue descobrir e utilizar.

O próprio Chrome apresenta exemplos como pesquisa, compra, preenchimento de formulários e navegação como possíveis aplicações.

Isso abre espaço para um conceito que considero mais interessante do que simplesmente “site preparado para IA”.

Um site preparado para agentes.

O site começa a explicar suas próprias capacidades

Essa talvez seja a mudança conceitual mais importante.

Quando uma pessoa entra em uma página, ela interpreta elementos visuais.

Um botão escrito “Comprar agora” faz sentido porque aprendemos a associar aquela expressão a uma ação.

Um agente pode fazer essa interpretação também, mas isso envolve inferência.

Com WebMCP, o site pode declarar explicitamente a função que está disponível.

O Chrome descreve esse processo como uma descoberta estruturada de ferramentas. O agente recebe informações sobre as ferramentas, seus parâmetros e sua finalidade, em vez de depender apenas da interpretação dos elementos da interface.

Isso também cria uma consequência interessante para quem trabalha com UX.

O design visual continua sendo importante para pessoas.

Mas parte da “documentação operacional” do site passa a existir em uma camada que também pode ser compreendida por agentes.

É uma espécie de segunda interface.

Uma interface visual para humanos.

Uma interface semântica e operacional para agentes.

Isso significa que os sites vão desaparecer?

Eu não vejo dessa maneira.

A tendência que me parece mais provável é outra.

Os sites continuarão existindo, mas começarão a oferecer diferentes maneiras de interação.

Uma pessoa pode navegar visualmente.

Um agente pode utilizar ferramentas estruturadas.

E os dois podem trabalhar sobre a mesma aplicação.

Isso aparece inclusive na proposta atual do WebMCP. As ferramentas são executadas dentro da própria página e podem utilizar o contexto existente daquela sessão. A documentação do Chrome destaca que isso permite ao agente trabalhar com o estado atual do site, em vez de operar completamente separado da interface.

Para uma loja virtual, por exemplo, isso pode significar que o agente não precisa apenas “visitar” a loja.

Ele pode interagir com ela de maneira mais previsível.

E aqui aparece uma questão importante para marketing digital

Se eu estivesse desenvolvendo um site hoje, começaria a incluir uma nova pergunta no planejamento:

O que quero que um agente consiga fazer dentro deste site?

Isso muda bastante a conversa.

Até pouco tempo, uma estratégia digital poderia se preocupar principalmente com:

SEO.

Conversão.

Experiência do usuário.

Performance.

Acessibilidade.

Agora começa a surgir uma camada adicional:

agentic readiness.

Ou seja, o quanto aquela experiência está preparada para que um agente execute tarefas em nome do usuário.

Imagine uma landing page de uma empresa de serviços.

Hoje ela pode ter:

• informações sobre a empresa
• descrição dos serviços
• depoimentos
• formulário de contato
• botão para agendar uma reunião

Em uma experiência mais preparada para agentes, algumas dessas ações poderiam ser expostas de maneira estruturada.

Um agente poderia, por exemplo, descobrir que existe uma função para consultar horários disponíveis e outra para solicitar um orçamento.

Isso não significa que a página precise abandonar o formulário tradicional.

Significa que ela pode oferecer uma camada adicional de interação.

WebMCP também muda a maneira de pensar formulários

Formulários são um bom exemplo porque são uma das interfaces mais antigas da web.

Um formulário existe para coletar dados estruturados.

Nome.

E-mail.

Telefone.

Data.

Endereço.

Quantidade.

Preferências.

O WebMCP pode transformar determinados formulários em ferramentas que agentes conseguem utilizar de maneira estruturada. O Chrome oferece tanto uma API declarativa, baseada em elementos HTML, quanto uma API imperativa baseada em JavaScript para definir ferramentas.

Isso é importante porque o HTML já possui uma característica que muitas aplicações modernas acabam esquecendo:

ele possui significado.

Um campo de e-mail é diferente de um campo de texto.

Um botão de envio é diferente de um elemento puramente visual.

Uma estrutura semântica bem construída pode ajudar tanto pessoas quanto máquinas.

E isso aproxima WebMCP de uma discussão que já existe há bastante tempo no desenvolvimento web: quanto mais clara for a semântica de uma página, menos interpretação arbitrária será necessária.

Ainda existe uma grande limitação

Eu teria cuidado com qualquer discurso dizendo que o WebMCP já representa uma transformação consolidada da web.

Não representa.

Ainda.

A documentação do Chrome classifica a tecnologia como proposta e experimental. O WebMCP está sendo desenvolvido ativamente, possui limitações e pode sofrer mudanças. Atualmente, ele depende de um contexto de navegador aberto para que as ferramentas estejam disponíveis.

Isso muda bastante a maneira como eu trataria o assunto.

Eu não sairia adicionando WebMCP a todos os sites amanhã.

Primeiro tentaria entender quais tarefas realmente fariam sentido.

Depois avaliaria segurança, arquitetura e experiência do usuário.

Só então pensaria na implementação.

A própria documentação do Chrome dedica uma seção específica à segurança porque ferramentas acessíveis a agentes introduzem novos riscos, incluindo problemas relacionados a prompt injection indireto e ao uso de conteúdo não confiável por agentes.

E esse ponto merece bastante atenção.

Dar mais capacidade de ação para uma IA também significa precisar controlar melhor aquilo que ela pode fazer.

O que eu acho que vale observar agora

Para quem trabalha com marketing digital, SEO, desenvolvimento de sites ou e-commerce, eu acompanharia cinco coisas.

1. Quais ações do site poderiam ser executadas por um agente

Comece pelas tarefas mais objetivas.

Pesquisar.

Agendar.

Comprar.

Consultar.

Preencher.

Solicitar.

2. Se o site possui uma estrutura semântica adequada

HTML bem estruturado continua sendo importante.

WebMCP não elimina boas práticas tradicionais de desenvolvimento.

3. Como os agentes vão pedir confirmação

Uma coisa é consultar um produto.

Outra é efetuar uma compra.

Outra ainda é cancelar um serviço.

O nível de risco da ação precisa fazer parte do desenho da experiência.

4. Como as plataformas vão implementar isso

Chrome, agentes de IA, navegadores e sistemas operacionais ainda estão construindo esse ecossistema.

Não existe uma arquitetura definitiva.

5. Se WebMCP realmente ganha adoção

Esse talvez seja o principal ponto.

Uma tecnologia pode ser tecnicamente interessante e ainda assim não se transformar em um padrão amplamente utilizado.

Por isso, eu acompanharia a evolução antes de tratar WebMCP como obrigação para qualquer projeto.

O impacto pode ser maior do que parece

Existe uma mudança mais profunda por trás do WebMCP.

A web foi construída para que pessoas encontrassem informações e interagissem com sistemas.

Agora estamos entrando em uma fase em que pessoas podem delegar parte dessas interações a agentes.

Isso muda a pergunta que fazemos ao construir uma experiência digital.

Antes eu perguntaria:

“Uma pessoa consegue entender como usar este site?”

Agora também preciso perguntar:

“Um agente consegue entender o que este site permite fazer?”

São perguntas diferentes.

E acredito que essa segunda pergunta vai aparecer cada vez mais em projetos de sites, lojas virtuais, sistemas SaaS e serviços digitais.

Ainda não sabemos até onde o WebMCP vai chegar. A especificação está em evolução e o suporte continua experimental.

Mas a direção é bastante clara.

A internet está deixando de ser apenas um conjunto de páginas que os agentes precisam interpretar.

Estamos começando a construir uma web em que os próprios sites podem declarar, de maneira estruturada, aquilo que sabem fazer.

Para quem trabalha com sites hoje, talvez valha começar a pensar nisso antes que vire requisito.

Fontes

Google Chrome Developers, documentação oficial sobre WebMCP.

Google Chrome Developers, comparação entre WebMCP e MCP.

Google Chrome Developers, segurança das ferramentas WebMCP.

Google Chrome Developers, práticas recomendadas para WebMCP.