Um agente do navegador vê um botão e estima a sua posição. Isso pode funcionar. Mas uma aplicação web também pode comunicar o seu significado de forma mais explícita: esta ação procura marcações disponíveis, espera uma data e devolve uma lista. É precisamente esta passagem da posição do clique para uma ferramenta descrita que torna o WebMCP interessante.
De acordo com o estado documentado, o WebMCP é uma proposta experimental. O documento explicativo atual abrange o registo imperativo através de JavaScript e de document.modelContext. As ferramentas declarativas de formulários HTML estão a ser exploradas separadamente e não fazem atualmente parte desta especificação. A página de visão geral do Chrome datada de 18 de maio de 2026 não é, por isso, motivo para afirmar que existe uma nova funcionalidade universal do navegador em outubro.
Uma ferramenta começa com uma ação limitada
O nosso próprio exemplo chama-se «encontrar marcações disponíveis». A sua função termina na informação. Não cria uma reserva. A própria descrição já deve deixar isto claro, para que um agente não transforme um resultado de pesquisa numa marcação confirmada.
A entrada contém uma data e um serviço disponibilizado. O resultado indica a mesma referência juntamente com os horários disponíveis. Um valor isolado como «10:30» seria mais fraco: poderia pertencer a outro dia ou a outro serviço. Um resultado estruturado é particularmente útil quando os seus elementos podem ser interpretados de forma inequívoca.
{
"tool": "find_slots",
"input": {
"date": "2030-04-12",
"service": "intro"
},
"effect": "read_only"
}Este é o nosso esquema didático, não um registo WebMCP pronto a copiar. A data futura e o serviço são inventados. Mostra o contrato que uma implementação real teria de especificar. Para a sintaxe concreta da API, a referência é a documentação experimental atual.
Os erros também precisam de um significado compreensível
Uma data inválida, nenhuma marcação disponível e um serviço que não pode ser contactado por razões técnicas são três resultados diferentes. Se todos produzirem simplesmente uma lista vazia, o agente teria de adivinhar a causa. A resposta da ferramenta deve, por isso, transmitir um estado compreensível e a informação necessária para a decisão seguinte.
O mesmo se aplica a informação parcial. A pesquisa está completa ou ainda faltam dados? A resposta pertence ao pedido mais recente? A pessoa alterou entretanto a data? Estas perguntas existem independentemente de a interface ser abordada através de uma captura de ecrã ou de uma ferramenta.
Uma descrição não é uma permissão
Um esquema de entrada correto diz que forma um pedido deve ter. Não decide se quem faz a chamada pode ler esta informação. A aplicação continua a ter de fazer cumprir as suas próprias regras. Um nome de ferramenta bonito não é nem autenticação nem controlo de acesso.
A transição para a reserva também precisa de um significado próprio. «Procurar horários disponíveis» e «reserva-me este horário» têm consequências diferentes. Não devem fundir-se discretamente numa única função. Uma reserva real teria de ter em conta o item confirmado e a instrução pretendida.
Para um primeiro exercício de design inofensivo, bastam, portanto, dados de exemplo fixos. Descreve três estados de resposta e determina que ação seguinte seria razoável em cada caso. Assim podes testar quão compreensível é o contrato sem simular uma reserva real nem um ambiente de execução WebMCP existente.
O WebMCP não é automaticamente um servidor MCP remoto existente
A palavra MCP aparece em vários contextos técnicos. Uma ação descrita do lado do navegador não é, só por isso, o mesmo tipo de ligação que um servidor de ferramentas remoto acessível por HTTP. Para uma ligação concreta, o que conta é o cliente, o transporte, a autenticação e as ferramentas efetivamente oferecidas.
Por isso, um acesso MCP remoto existente não prova que um site suporte WebMCP. Da mesma forma, uma proposta experimental de navegador não garante que todos os agentes já a possam usar. Esta distinção é prática: evita que um nome semelhante conduza ao plano de integração errado.
A pergunta transferível continua clara. Consegue uma aplicação exprimir que ação, com que entradas, tem que resultado e que efeito? Quanto mais precisa for esta resposta, menos um agente tem de adivinhar a partir de uma posição no ecrã. Bons contratos de ferramentas tornam a margem de manobra mais fácil de compreender; as regras da aplicação continuam, ainda assim, a ser da sua própria responsabilidade.
Fontes e estado
Investigação e documentação à data de 25 de outubro de 2026. WebMCP · Documento explicativo do WebMCP.
