WebKit se opõe ao WebMCP. O que construir hoje

Se você tem acompanhado a luta pelos padrões da web agentic, viu as manchetes: o Chrome lançou um teste de origem do WebMCP no Chrome 149, e o rastreador de posições de padrões do WebKit chegou a um veredicto de uma palavra — oposição.

É tentador ler isso como "a Apple diz não, então espere." Essa é a interpretação errada. A oposição é principalmente um bom feedback de engenharia, e uma vez que você a internaliza, ela lhe diz exatamente como construir para agentes hoje — de uma maneira que é segura mesmo se a especificação estagnar.

O que o WebKit realmente se opôs

A posição do WebKit cita a lista habitual — design de API, duplicação de funcionalidades existentes da plataforma, i18n, portabilidade, privacidade, segurança, casos de uso pouco claros. Soa como um clichê, mas uma dessas críticas é a que realmente pesa, e aparece mais nitidamente no repositório do WebMCP: redundância com a árvore de acessibilidade.

O argumento é claro:

A árvore de acessibilidade já expõe um espaço de ação legível por máquina — rótulos, papéis, estados, entradas esperadas, erros de validação, relacionamentos. É derivada do DOM, então não pode desincronizar. Um registro de ferramentas JavaScript mantido separadamente pode e irá divergir da página ao longo do tempo.

Isso está correto. Se você escrever manualmente uma descrição paralela da sua interface para agentes, você criou uma segunda fonte de verdade, e segundas fontes de verdade apodrecem. Isso é um verdadeiro sinal de alerta, e "APIs apenas para agentes que não ajudam humanos" é algo legítimo para se desconfiar.

Por que a árvore de acessibilidade sozinha também não é suficiente

Aqui está a parte que a oposição subestima. A árvore de a11y é excelente em descrever estado — o que está na página, o que cada controle é, o que é necessário. É muito mais fraca em descrever ações, especialmente as compostas.

Considere "filtrar produtos abaixo de €50, em estoque, e então adicionar o resultado principal ao carrinho." Para um humano com um leitor de tela, isso é uma sequência de interações discretas de controle. Para um agente, inferir todo esse fluxo a partir de papéis e rótulos é frágil — ele tem que reverter a intenção do seu aplicativo a partir de primitivos. Uma ferramenta com um esquema de entrada tipado ({ maxPrice, inStock }) e um único manipulador colapsa essa adivinhação em uma chamada verificada.

Portanto, ambas as coisas são verdadeiras ao mesmo tempo:

1. Uma API de agente paralela, mantida manualmente, é uma responsabilidade.
2. A árvore de a11y é perdida para ações de múltiplos passos ações.

A resolução não é "escolher um lado." É como você implementa as ferramentas.

O design que sobrevive à crítica

A objeção de redundância só pesa se suas definições de ferramentas forem uma segunda implementação. Então, não as faça uma.

A postura correta, na ordem:

1. Construa para humanos primeiro. HTML semântico, elementos de formulário reais, uma árvore de acessibilidade limpa. Isso é inegociável e é o que todos — usuários, tecnologia assistiva, busca, e agentes — se beneficiam.
2. Exponha as ações, não um novo aplicativo. Onde você registra uma ferramenta de agente, faça seu manipulador chamar a mesma função exata que sua interface já chama. Seu botão "Adicionar ao carrinho" e sua ferramenta add_to_cart devem terminar em um único caminho de código.
3. Mantenha as ferramentas finas. Uma ferramenta é um ponto de entrada tipado para um comportamento existente, não um lugar para nova lógica de negócios. Se uma ferramenta faz algo que sua interface não pode, essa é a divergência que o WebKit alertou — conserte a interface em vez disso.

Faça isso e o problema das "duas fontes de verdade" evapora, porque ainda há apenas uma. O registro de ferramentas não é uma descrição paralela da página; é uma porta de entrada tipada para os manipuladores que a página já executa. Eles não podem desincronizar porque são o mesmo código.

Concretamente

A API imperativa é apenas um wrapper tipado sobre uma função que você já tem:

navigator.modelContext.registerTool({
  name: "add_to_cart",
  description: "Adicionar um produto ao carrinho pelo id e quantidade",
  inputSchema: {
    type: "object",
    properties: {
      productId: { type: "string" },
      quantity: { type: "number", default: 1 },
    },
    required: ["productId"],
  },
  // mesmo manipulador que seu botão "Adicionar ao carrinho" chama — sem segunda implementação
  async execute({ productId, quantity = 1 }) {
    await cart.add(productId, quantity);
    return { content: [{ type: "text", text: `Adicionado ${quantity} x ${productId}` }] };
  },
});

E detecte recursos, porque a maioria dos navegadores ainda não os terá:

if ("modelContext" in navigator) {
  // registrar ferramentas
}

Isso