WebMCP: preparando seu site para a era dos agentes de IA

O problema com agentes na web

Imagine um futuro em que milhões de agentes de IA navegam na web e executam ações em nome de pessoas. Nesse cenário, surgem duas perguntas fundamentais: como o agente sabe o que pode fazer em uma página e como ele faz isso de forma confiável?

Sem um padrão, o dono de um site que quer atender agentes tem duas opções. Infelizmente, nenhuma delas é boa.

A primeira opção é construir um servidor MCP dedicado e torcer para que o agente do usuário o tenha configurado. Na prática, isso raramente funciona, porque nenhum agente vem pré-configurado com o MCP de cada site que pode visitar.

Se o conceito de MCP ainda é novo para você, vale ler antes o que é MCP. Em resumo, ele padroniza a forma como agentes descobrem e chamam ferramentas externas.

A segunda opção é depender das capacidades de browser use que agentes modernos, como o Manus, já trazem. Esses agentes abrem um navegador e executam tarefas, mas a abordagem é inerentemente não determinística.

Na prática, o agente extrai o HTML bruto da página, tenta limpá-lo e o entrega a um modelo de linguagem. Às vezes, ele também tira screenshots e anota elementos de UI para traduzir o layout visual em ações.

O problema central é que a maioria dos sites foi construída para humanos, e não para máquinas. Eles estão cheios de ruído: menus, rodapés, textos de marketing, divs aninhadas e classes dinâmicas que nada significam para um agente.

Todo esse ruído vai para o modelo, e o resultado previsível é um comportamento instável. Assim, agentes cometem erros, ignoram elementos ou não concluem tarefas.

Se agentes se tornarem consumidores relevantes de conteúdo e ações na web, um site que eles usam com confiabilidade terá vantagem competitiva. É exatamente essa lacuna que o WebMCP tenta preencher.

O que é o WebMCP

O WebMCP permite que desenvolvedores web declarem ferramentas no estilo MCP diretamente no HTML ou no JavaScript da página. Segundo o anúncio do Chrome, o objetivo é oferecer uma forma padrão de expor ferramentas estruturadas, para que agentes executem ações com mais velocidade, confiabilidade e precisão.

Quando um agente visita a página, ele não precisa interpretar o HTML nem adivinhar a estrutura. Em vez disso, ele lê as ferramentas declaradas e as chama, como faria com qualquer outra ferramenta MCP.

Essa é uma mudança sutil, mas profunda. Na prática, o próprio site passa a funcionar como provedor de ferramentas, carregadas por página no momento em que o agente chega àquela URL.

A proposta é incubada no W3C Web Machine Learning Community Group, com editores do Google e da Microsoft. O explainer oficial no GitHub descreve as APIs e os objetivos do projeto.

Entre os objetivos declarados estão fluxos colaborativos entre humanos e IA, com o usuário mantendo visibilidade e controle. Por outro lado, cenários de navegação headless e fluxos totalmente autônomos sem supervisão humana estão explicitamente fora do escopo.

Duas formas de declarar ferramentas no WebMCP

O WebMCP oferece duas abordagens para registrar ferramentas. A API declarativa cobre ações padrão definidas em formulários HTML, enquanto a API imperativa cobre interações dinâmicas que exigem JavaScript.

<!-- Formulário de contato exposto como ferramenta para agentes -->
<form
  toolname="send-contact-message"
  tooldescription="Sends a contact message to the site owner"
>
  <input
    type="text"
    name="name"
    toolparamdescription="Full name of the person sending the message"
  />
  <input
    type="email"
    name="email"
    toolparamdescription="Email address used to reply"
  />
  <textarea
    name="message"
    toolparamdescription="Content of the message"
  ></textarea>
  <button type="submit">Send</button>
</form>

const form = document.querySelector("form");

form.addEventListener("submit", (event) => {
  // Envios feitos por humanos seguem o fluxo normal
  if (!event.agentInvoked) {
    return;
  }

  event.preventDefault();

  if (!isValid(form)) {
    event.respondWith(Promise.resolve({ error: "Validation failed" }));
    return;
  }

  // Devolve ao agente o resultado do envio
  event.respondWith(sendContactMessage(new FormData(form)));
});

// webmcp.ts
export function registerSearchFlightsTool(signal: AbortSignal) {
  return document.modelContext.registerTool(
    {
      name: "search-flights",
      description: "Searches available flights based on the given criteria",
      inputSchema: {
        type: "object",
        properties: {
          origin: { type: "string", description: "Origin airport code" },
          destination: { type: "string", description: "Destination airport code" },
          date: { type: "string", description: "Departure date in YYYY-MM-DD format" },
        },
        required: ["origin", "destination", "date"],
      },
      async execute({ origin, destination, date }) {
        const flights = await fetchFlights(origin, destination, date);
        return { content: [{ type: "text", text: JSON.stringify(flights) }] };
      },
    },
    { signal } // Abortar o sinal remove a ferramenta
  );
}

// SearchPage.tsx
import { useEffect } from "react";
import { registerSearchFlightsTool } from "./webmcp";

export function SearchPage() {
  useEffect(() => {
    const controller = new AbortController();
    registerSearchFlightsTool(controller.signal);

    // Ao desmontar, a ferramenta deixa de existir para o agente
    return () => controller.abort();
  }, []);

  return <FlightSearchForm />;
}

// wwwroot/js/webmcp.js
let controller;

export function registerSearchFlightsTool(dotNetRef) {
  controller = new AbortController();

  document.modelContext.registerTool(
    {
      name: "search-flights",
      description: "Searches available flights based on the given criteria",
      inputSchema: {
        type: "object",
        properties: {
          origin: { type: "string", description: "Origin airport code" },
          destination: { type: "string", description: "Destination airport code" },
          date: { type: "string", description: "Departure date in YYYY-MM-DD format" },
        },
        required: ["origin", "destination", "date"],
      },
      async execute({ origin, destination, date }) {
        // Chama de volta o método C# marcado com [JSInvokable]
        const flights = await dotNetRef.invokeMethodAsync("SearchFlights", origin, destination, date);
        return { content: [{ type: "text", text: JSON.stringify(flights) }] };
      },
    },
    { signal: controller.signal }
  );
}

export function unregisterSearchFlightsTool() {
  controller?.abort();
}

@page "/search"
@implements IAsyncDisposable
@inject IJSRuntime JS
@inject FlightService FlightService

<FlightSearchForm />

@code {
    private IJSObjectReference? _module;
    private DotNetObjectReference<SearchPage>? _dotNetRef;

    protected override async Task OnAfterRenderAsync(bool firstRender)
    {
        if (firstRender)
        {
            _module = await JS.InvokeAsync<IJSObjectReference>("import", "./js/webmcp.js");
            _dotNetRef = DotNetObjectReference.Create(this);

            // Registra a ferramenta quando o componente aparece na tela
            await _module.InvokeVoidAsync("registerSearchFlightsTool", _dotNetRef);
        }
    }

    [JSInvokable]
    public async Task<object> SearchFlights(string origin, string destination, string date)
    {
        // Sua lógica de busca aqui
        var results = await FlightService.SearchAsync(origin, destination, date);
        return results;
    }

    public async ValueTask DisposeAsync()
    {
        if (_module is not null)
        {
            await _module.InvokeVoidAsync("unregisterSearchFlightsTool");
            await _module.DisposeAsync();
        }

        _dotNetRef?.Dispose();
    }
}

Carregamento contextual de ferramentas

O carregamento contextual talvez seja a ideia conceitualmente mais interessante que o WebMCP introduz. Para entender por quê, vale olhar a evolução recente das ferramentas para agentes.

Quando a especificação MCP surgiu, ela deu aos agentes uma forma confiável de estender capacidades com schemas garantidos. Porém, todas as ferramentas precisavam ficar no contexto o tempo todo, mesmo quando irrelevantes.

Isso custa caro em tokens e se torna impraticável em casos de cauda longa. As boas práticas do próprio Chrome lembram que cada ferramenta adicional ocupa a janela de contexto e aumenta o tempo de resposta.

Mais recentemente, o padrão de skills ganhou tração como alternativa. Uma skill carrega apenas título e descrição por padrão, e as instruções completas entram no contexto só quando necessário.

Essa abordagem economiza tokens, mas sacrifica as garantias estritas de schema que tornam o MCP confiável. Se quiser aprofundar essa comparação, o artigo agents ou MCP: qual escolher ajuda a organizar as opções.

O WebMCP, de certa forma, une o melhor dos dois mundos. Ele mantém chamadas determinísticas e validadas por schema, enquanto carrega as ferramentas conforme a página em que o agente está.

Ou seja, a página funciona como seletor das ferramentas ativas. Carregar as ferramentas certas no momento certo, em vez de todas o tempo todo, parece a direção correta para agentes, muito além da web.

Como começar com o WebMCP hoje

O WebMCP ainda é experimental, então a configuração exige alguns passos manuais. No período da prévia antecipada, o caminho para testar localmente era o seguinte:

1. Use o Chrome 146 ou superior. Na época, essa versão estava disponível nos canais de pré-lançamento do navegador.
2. Habilite a flag de testes do WebMCP. Acesse chrome://flags/#enable-webmcp-testing e marque a opção como habilitada.
3. Instale a extensão Model Context Tool Inspector. Ela faz parte do repositório GoogleChromeLabs/webmcp-tools e lista as ferramentas registradas na página, com nome, descrição e schema.

A extensão também permite executar uma ferramenta manualmente, com um modelo de entrada gerado a partir do schema. Além disso, ela acompanha os eventos toolchange e atualiza a lista quando o registro muda.

Para usar em produção com usuários reais, o caminho passou a ser o origin trial do Chrome 149. Nesse caso, você registra o domínio no programa e recebe um token para habilitar o recurso no seu site.

Boas práticas para ferramentas WebMCP

A documentação do Chrome traz um guia de boas práticas que vale seguir desde o primeiro protótipo. Primeiro, cada ferramenta deve cuidar de uma única função, para não confundir o agente.

Os nomes também importam. O guia sugere diferenciar execução imediata de início de processo, como create-event em vez de start-event-creation-process.

No schema, prefira aceitar a entrada do usuário como ela vem, sem exigir que o modelo faça cálculos ou transformações. Também prefira linguagem natural a identificadores ambíguos, como shipping="Express" em vez de shipping_id=1.

Por fim, valide com rigor no código, mesmo mantendo o schema mais flexível. Erros descritivos ajudam o agente a se corrigir, e atualizar a interface depois da execução permite que ele confirme o sucesso da tarefa.

Por que o WebMCP importa para o futuro da web

A web foi projetada para humanos. Links, formulários e layouts foram otimizados para olhos e mãos.

À medida que os agentes ficam mais capazes, uma parcela crescente das interações tende a partir deles. Sites que os agentes conseguem usar corretamente devem atrair esse tráfego, enquanto os demais correm o risco de ficar para trás.

O WebMCP é uma tentativa inicial e bem pensada de criar um padrão para isso. Em vez de deixar os agentes adivinharem, ele pede que os desenvolvedores declarem suas intenções explicitamente.

Hoje, o contexto que define as ferramentas é a página. No futuro, poderia ser uma tarefa, um perfil de usuário ou o estado de um workflow.

A ideia de ferramentas com escopo definido, em vez de carregadas globalmente, pode influenciar o desenho de sistemas de agentes muito além do navegador. Por isso, quem desenvolve para a web tem um bom motivo para experimentar o WebMCP agora, enquanto ainda dá tempo de ajudar a moldá-lo.

Conclusão

O WebMCP propõe uma mudança de paradigma na forma como a web conversa com agentes de IA. Ao transformar o próprio site em uma fonte contextual de ferramentas, ele elimina o parsing frágil de HTML e a configuração prévia do lado do agente.

O resultado é uma web mais determinística. Nela, as ferramentas são declaradas com intenção, os schemas garantem contratos precisos e o contexto da página define o que está disponível.

Para quem desenvolve em .NET ou em qualquer outra plataforma, a mensagem é clara: a camada de apresentação pode ser projetada tanto para humanos quanto para agentes. Isso não exige reescrever tudo, basta começar a declarar intenções.

Formulários anotados, componentes que registram ferramentas e respostas estruturadas são investimentos pequenos hoje. Mesmo ainda experimental, o WebMCP aponta para uma web contextual e orientada a schema, e vale acompanhá-lo de perto.

FAQ

Qual a diferença entre o WebMCP e um servidor MCP convencional?

O servidor MCP tradicional precisa estar configurado no agente antes do uso. Já as ferramentas do WebMCP vivem na própria página e ficam disponíveis quando o agente a visita, sem configuração prévia.

Preciso reescrever meu site para usar o WebMCP?

Não. Em formulários, alguns atributos HTML bastam para começar, e em aplicações dinâmicas você registra ferramentas por componente com a API imperativa.

O WebMCP funciona em todos os navegadores?

Não. Ele é uma proposta em incubação no W3C e, até aqui, está disponível de forma experimental no Chrome, por flag de testes ou origin trial.

Como o usuário mantém o controle quando um agente preenche um formulário?

As pseudoclasses :tool-form-active e :tool-submit-active permitem destacar a interação e exibir uma revisão antes do envio. Além disso, sem o atributo toolautosubmit, o formulário não é enviado automaticamente quando o agente invoca a ferramenta.

O que acontece se o agente não suportar WebMCP?

Nada quebra. Os atributos e o registro de ferramentas não mudam a página para humanos, e o agente sem suporte simplesmente recorre à estratégia de browser use que já utiliza.