Automação web com Kitesurf WebMCP: guia prático e seguro

Resposta rápida

Para usar o Kitesurf WebMCP, conecte um agente compatível com MCP ao Cloudflare Browser Run por meio do Chrome DevTools MCP, direcione o endpoint WebSocket para browser=kitesurf e ative a categoria experimental de ferramentas WebMCP. Assim, o agente recebe dois comandos essenciais: list_webmcp_tools, para descobrir as ações de uma página, e execute_webmcp_tool, para executar uma delas.

Comece por uma ação somente de leitura ou reversível. O Cloudflare Radar é um bom alvo documentado, pois expõe ações como navigate-to e set-location. Inspecione o schema retornado pelo Kitesurf, informe apenas os argumentos aceitos por esse schema e depois compare o resultado estruturado com o estado visível da página. Uma chamada de ferramenta só passa no teste quando os dois coincidem.

Este passo a passo é um plano de teste documentado, não o relato de um teste ao vivo. Como não havia uma conta de teste da Cloudflare nem um token do Browser Run disponível nesta execução, você não encontrará abaixo nenhum resultado de sucesso inventado.

O que o Kitesurf WebMCP muda na automação web

MCP e WebMCP cumprem papéis diferentes. O MCP conecta o agente ao navegador remoto. Já o WebMCP permite que o próprio site publique ações nomeadas dentro desse navegador. Pense no MCP como a linha telefônica e no WebMCP como o menu do outro lado: a linha estabelece a conexão; o menu informa exatamente o que pode ser pedido e quais dados cada pedido exige.

Sem esse menu, o agente costuma ler a página, localizar um controle, clicar, esperar e ler novamente. Com o WebMCP, a página pode expor uma função como set-location, acompanhada de entradas tipadas. O agente ainda precisa escolher a ação correta e validar a saída, mas deixa de inferir cada interação a partir de pixels ou da estrutura da página.

Segundo a documentação do WebMCP da Cloudflare, o Kitesurf tem uma implementação própria e, por isso, dispensa uma sessão do Chrome Lab. As páginas podem registrar ferramentas programáticas por meio de document.modelContext; o Kitesurf também reconhece ferramentas declarativas de formulário marcadas com os atributos toolname e tooldescription.

Como conectar um cliente MCP ao Kitesurf

Você precisa do Node.js 20.19 ou mais recente, de um cliente compatível com MCP, de um ID de conta da Cloudflare e de um token de API com a permissão Browser Rendering - Edit. O guia de configuração de clientes MCP da Cloudflare abrange Claude Desktop, Claude Code, Cursor e OpenCode. Se esta for sua primeira conexão MCP, a seleção de servidores MCP ajuda a entender o papel do servidor local.

No lançamento do Kitesurf, a Cloudflare apresenta esta configuração para clientes locais:

{
  "mcp": {
    "kitesurf": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "chrome-devtools-mcp@latest",
        "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf",
        "--wsHeaders={\"Authorization\":\"Bearer <CLOUDFLARE_API_TOKEN>\"}",
        "--category-experimental-webmcp"
      ],
      "enabled": true
    }
  }
}

Adapte o formato ao padrão de configuração do seu cliente, mas preserve os argumentos do comando. Guarde o ID real da conta e o token em segredos fornecidos pelo ambiente, não em um arquivo de configuração versionado. Também não copie os parâmetros do Chrome Lab para essa URL. O Kitesurf usa browser=kitesurf, não exige lab=true e não aceita keep_alive.

A última flag é indispensável. É --category-experimental-webmcp que adiciona list_webmcp_tools e execute_webmcp_tool ao Chrome DevTools MCP. Sem ela, a conexão pode funcionar perfeitamente, mas os dois comandos do WebMCP não aparecerão.

Como executar uma tarefa validada no Cloudflare Radar

O menor teste realmente útil comprova quatro pontos: a descoberta funciona, o schema pode ser lido, a execução devolve dados e a página reflete o resultado.

1. Peça ao agente conectado que abra https://radar.cloudflare.com/. Mantenha a tarefa dentro de uma conta de teste e evite ações com consequências financeiras, destrutivas ou que afetem toda a conta.
2. Chame list_webmcp_tools. Salve o nome, a descrição e o schema de entrada de cada ferramenta retornada. O conjunto disponível pode mudar depois de uma navegação ou de outra ação; portanto, esse inventário pertence ao estado atual da página.
3. Se houver uma ação inofensiva como set-location, selecione-a e leia o schema retornado. Não tente deduzir os nomes dos argumentos a partir deste artigo. Trate o schema ao vivo como o contrato.
4. Chame execute_webmcp_tool com um valor de localização válido para o schema. Registre o nome exato da ferramenta, os argumentos, o resultado estruturado, o tempo decorrido e o estado visível da página.
5. Compare a resposta com o que o Radar exibe. Depois da mudança de estado, execute list_webmcp_tools novamente e registre as ações adicionadas ou removidas.

Um bom prompt para o agente vai direto ao ponto:

Trate essas evidências como um pequeno registro de teste, não como uma transcrição de chat. Guarde, no mínimo, estes campos:

Assim, uma demonstração vira um processo que a equipe de engenharia consegue repetir. Também fica mais fácil separar uma falha do WebMCP de uma falha de raciocínio do agente. Se a ferramenta nomeada não aparece, a interface falhou antes da execução. Se a chamada funciona, mas a página diverge, a implementação ou a validação falhou depois da execução.

Quando o Kitesurf precisa de uma alternativa

O Kitesurf WebMCP não é uma camada universal de controle do navegador. Seus limites atuais determinam quais tarefas de produção podem ser encaminhadas por ele com segurança.

• Ferramentas registradas dentro de um iframe ou popup não são expostas via CDP. Considere-as indisponíveis para o agente e use um fluxo de navegador convencional, uma etapa humana ou uma ferramenta de nível superior caso o site seja seu.
• As sessões do Kitesurf não aparecem em wrangler browser list e não têm visualização ao vivo. O agente não consegue concluir uma ferramenta que pausa à espera da confirmação de uma pessoa.
• Para uma ação condicionada à confirmação, o caminho manual documentado pela Cloudflare é o painel WebMCP dentro de Application, no playground do Kitesurf. Isso é uma transferência de controle, não uma automação autônoma.
• O Kitesurf não implementa a política de permissões tools do WebMCP nem a filtragem de ferramentas por origem. Descobrir uma ferramenta não significa estar autorizado a usá-la. Mantenha uma lista de permissões separada para domínios, ações e identidades de teste.
• A lista de ferramentas depende do estado. Refaça a listagem após navegar ou executar qualquer ação que altere a página, antes de presumir que a próxima ferramenta continua disponível.

O padrão honesto para produção é um roteador: WebMCP primeiro quando houver uma ação nomeada adequada, automação convencional do navegador quando não houver e transferência para uma pessoa quando a ação exigir consentimento. Não esconda essas ramificações atrás de um único prompt otimista.

A conta de negócio está na manutenção, não só no preço do navegador

O Kitesurf é gratuito durante o beta, sujeito aos limites da conta, mas a Cloudflare não estabeleceu que as tarifas gerais de excedente do Browser Run pago sejam aplicadas ao beta gratuito. O panorama atual de preços e franquias do Kitesurf é analisado separadamente, inclusive os motivos para não montar um modelo de custos permanente sobre uma oferta beta.

Já existe um orçamento real para infraestrutura de navegadores nesse mercado. A Browserbase oferece planos pagos de $20 e $99 por mês. A Browserless oferece planos de $25 e $140 por mês com cobrança anual. Esses produtos atendem a necessidades mais amplas de infraestrutura; portanto, não se trata de afirmar que um substitui o outro em condições idênticas. O ponto é que as equipes já pagam para operar agentes em navegadores.

O WebMCP altera outra linha do orçamento: manutenção de seletores, novas tentativas e revisão por operadores. Ele não elimina o navegador, o modelo, os controles de segurança, a validação de resultados nem a rota alternativa. Meça a mesma tarefa pelos dois caminhos e compare tempo decorrido, tentativas malsucedidas, intervenções humanas e correções de engenharia. Mantenha o Kitesurf apenas onde a redução comprovada de manutenção superar o trabalho de integração.

Sete casos de uso, do maior ao menor impacto

Todos os casos abaixo partem do princípio de que a página de destino realmente expõe uma ferramenta WebMCP apropriada. O Kitesurf não consegue criar uma ação que o site não oferece.

O primeiro caso de uso oferece o valor mais amplo porque, por muitos anos, a maioria das equipes ainda trabalhará com uma web híbrida. Um roteador que sabe quando não usar WebMCP é mais útil do que uma demonstração bem-sucedida em uma única página preparada.

Três produtos que vale a pena criar

1. Um roteador WebMCP com fallback desde o início

Crie uma camada de políticas para equipes de agentes que liste as ferramentas da página, associe a ação pedida pelo usuário a um schema permitido e encaminhe a tarefa para execute_webmcp_tool, para a automação convencional do navegador ou para uma fila humana. Essa é a oportunidade mais forte porque resolve a lacuna de adoção, em vez de esperar que todos os sites implementem WebMCP.

A demanda já aparece nas buscas relacionadas a esse trabalho: browser automation recebe cerca de 720 buscas mensais, enquanto a consulta comercial browser automation tools recebe aproximadamente 260 e tem CPC de $34.28 nos dados de palavras-chave desta execução. A menor versão comercializável precisa de um conector de cliente MCP, uma lista de permissões por domínio e ação, um comparador de schemas, um registro de execução e um adaptador de fallback.

O entrave é o alcance. A cobertura do WebMCP ainda é limitada, o conjunto de ferramentas pode variar conforme o estado da página e o Kitesurf não consegue expor via CDP ferramentas que estejam em iframes ou popups. O mecanismo de fallback faz parte do produto; não é um recurso opcional para depois.

2. Um monitor de regressões do WebMCP

Ofereça aos proprietários de sites uma verificação agendada que registre nomes e schemas das ferramentas expostas, execute uma ação reversível de fixture, compare o resultado com a página visível e emita um alerta quando houver diferença. Cerca de 590 buscas mensais têm como alvo website automation, com CPC de $33.88. A consulta relacionada no singular, browser automation tool, cresceu 24% na comparação anual nos dados de sugestões.

Um MVP pode monitorar uma lista curta de rotas próprias com credenciais de teste, guardar inventários de ferramentas antes e depois e gerar um registro compacto da falha com argumentos, resultado, tempo e estado da página. O desafio é o estado. Uma ferramenta ausente pode ser consequência da rota ou da sessão errada, não de uma versão com defeito. Por isso, o produto precisa de navegação reproduzível e fixtures bem definidas.

3. Um auditor de prontidão para WebMCP

Crie um serviço de diagnóstico para equipes web que mapeie quais jornadas do cliente expõem ferramentas de nível superior, quais ações estão dentro de iframes ou popups e quais dependem da aprovação de uma pessoa. O indicador de demanda é prático: playwright browser automation recebe cerca de 320 buscas mensais e cresceu 129% na comparação anual, enquanto website automation recebe aproximadamente 590.

A versão mínima recebe as rotas de um site próprio e uma identidade de teste, lista e classifica as ferramentas disponíveis e produz um relatório priorizado de implementação. A limitação real está na observabilidade. Como o Kitesurf não expõe via CDP ferramentas aninhadas em iframes ou popups, o auditor não consegue deduzir somente pelo Kitesurf quais seriam os contratos pretendidos. Ele precisa da participação do proprietário do site ou de um segundo método de inspeção para distinguir o que está oculto do que não existe.

Limites e a avaliação realista

Use o Kitesurf WebMCP hoje em tarefas delimitadas e reversíveis, nas quais uma ação estruturada seja claramente melhor do que uma sequência de cliques. Não o adote como único caminho para um fluxo crítico, uma experiência de pagamento aninhada ou uma tarefa que precise aguardar aprovação humana ao vivo.

O recurso tem valor, mas o lançamento está à frente do ecossistema. O modelo de ações nomeadas pode reduzir ambiguidades e facilitar o diagnóstico de falhas. Ele não prepara automaticamente todos os sites para agentes, nem transforma um payload retornado em prova de que a página fez a coisa certa. A fronteira decisiva do produto é a etapa de validação.

Se você quer essa conexão, um sistema de testes de validação e uma política de fallback implementados em um agente de produção, posso ajudar a construir o sistema de produção.