WebMCP tem 0% de adoção. Então eu gerei as ferramentas eu mesmo.

Há uma história limpa que todos contam sobre agentes de IA e a web.

Agentes chamarão ferramentas estruturadas. Sites exporão essas ferramentas. Tudo será digitado, confiável e entediante de uma boa maneira. O Google até lançou um padrão para isso — WebMCP, no Chrome, atrás de uma bandeira.

É uma ideia genuinamente boa. Há apenas um problema.

Quase ninguém a implementou. A adoção é efetivamente zero. E padrões da web não são adotados em trimestres — eles são adotados em anos, se forem adotados.

Então, enquanto isso, seu agente ainda está fazendo a coisa embaraçosa: tirando capturas de tela de páginas, raspando o DOM, clicando em coordenadas de pixel e orando silenciosamente para que o layout não tenha mudado desde a última terça-feira.

Eu cansei de esperar. Então fiz uma pergunta diferente:

E se você não precisasse da permissão do site?

Uma caixa de pesquisa — uma entrada rotulada ao lado de um botão de envio — já é uma ferramenta search(query). A especificação está bem ali, renderizada em HTML. Alguém só precisa lê-la e escrevê-la.

Essa é a ideia por trás de webmcp-gen.

pip install webmcp-gen
webmcp-gen https://news.ycombinator.com --groq

Ele controla um navegador real, lê a página da maneira que uma pessoa faria e emite definições de ferramentas WebMCP. Então — a parte que o torna útil em vez de um brinquedo — ele funciona como um servidor MCP, para que o Claude Desktop, Cline ou qualquer cliente MCP possa realmente chamar essas ferramentas no site ao vivo e obter resultados estruturados de volta.

O pipeline é composto por quatro etapas:

EXTRACT   navegador real -> DOM + Shadow DOM + iframes -> seletores CSS estáveis
ANALYZE   heurística ou LLM -> ferramentas WebMCP, cada parâmetro vinculado ao seu seletor
SERVE     servidor MCP (stdio / SSE / HTTP transmitível)
EXECUTE   preencher por seletor -> enviar -> ler resultados estruturados de volta

Deixe-me mostrar as duas partes que realmente exigiram reflexão.

Parte 1: a vinculação do seletor (por que não falha em páginas reais)

A maioria das ferramentas "deixe a IA usar o navegador" funciona mostrando ao modelo o DOM e permitindo que ele adivinhe o que clicar. Essa adivinhação é exatamente onde elas falham em uma página real e bagunçada — o modelo escolhe a entrada errada, ou o layout muda e as coordenadas se tornam inválidas.

webmcp-gen faz uma aposta diferente: resolver o alvo uma vez, de forma determinística, no momento da geração. Cada parâmetro que o analisador emite carrega um _selector — o seletor CSS exato que o preenche. A ferramenta que um agente vê é limpa:

{ "query": { "type": "string", "description": "Termo de pesquisa" } }

Mas a versão que o executor possui também carrega a vinculação:

{
  "query": {
    "type": "string",
    "description": "Termo de pesquisa",
    "_selector": "input[name=\"q\"]"
  },
  "_submit_selector": "form#search"
}

Quando o agente chama searchStories(query="rust"), não há adivinhação. O executor preenche input[name="q"] e envia form#search. O LLM foi usado uma vez, no início, para nomear as coisas e inferir a intenção — nunca no caminho quente para re-derivar o que é uma caixa de pesquisa.

Os seletores em si são gerados com uma cadeia de fallback, começando pelos mais estáveis:

function stableSelector(el) {
  if (el.id) return '#' + CSS.escape(el.id);
  if (el.getAttribute('data-testid'))
    return '[data-testid="\"el\"]"];