Este artigo explica o que é WebMCP no contexto WordPress, como ele difere do MCP (Model Context Protocol) e como deixar um formulário pronto para agentes no browser, com anotações declarativas no HTML. Serve a devs e implementadores que já cuidam de performance e acessibilidade e querem antecipar a navegação agêntica sem tratar isso como fator mágico de SEO.
Se você já mede PageSpeed e acessibilidade, o Chrome passou a falar de outra superfície: agentes no browser precisam descobrir o que a página oferece. O WebMCP é o caminho proposto para o site declarar ações (tools), em vez de o agente adivinhar pelo DOM.
A base é um lab limpo que eu validei no Chrome (flag + Tool Inspector + Execute Tool + Lighthouse Agentic), com o mesmo caso de orçamento em form nativo, bloco Gutenberg, Fluent Forms, Contact Form 7, WPForms, Forminator, Ninja Forms e SureForms. O código está público em silvaitamar/wp-webmcp-forms (MIT) e no WordPress Playground (zero-install). Alinhado ao pilar IA e WordPress: a combinação estratégica de 2026.
Em agosto de 2026 o WebMCP ainda não vem ligado no Chrome estável: está em origin trial (Chrome 149–156), com disponibilização prevista no Chrome 157. No lab, a flag local basta. Em produção no trial, precisa de token por origem.
O visitante e o agente
O humano lê rótulos, preenche e envia. O agente precisa de contrato: nome da tool, descrição, schema dos campos. Sem isso, a atuação vira scraping frágil (cara e inconsistente).
O Lighthouse já inclui auditorias de navegação agêntica. Em forms, o que importa para cobertura declarativa é o markup: atributos no <form> e nos campos. Isso é diferente de “ter um plugin que registra tools em JavaScript” e diferente de “gerar um llms.txt”.
O que é WebMCP (e o que não é)
WebMCP é uma proposta de padrão web: a página registra tools que um agente no browser pode descobrir e chamar, com contexto visual da aba aberta. Há API imperativa (document.modelContext.registerTool) e API declarativa (anotações em formulários HTML). Prefira document.modelContext; o alias em navigator aparece como deprecado no console.
Não confunda com o MCP (Model Context Protocol): o protocolo aberto que expõe tools de um servidor a clientes como Cursor, Claude Desktop ou o MCP Adapter no WordPress. Aquilo serve o assistente de desenvolvimento ou um cliente remoto. WebMCP é na página, no browser do visitante. Os nomes se parecem; os problemas são outros. O par operacional (SSH + WP-CLI no servidor) está em Cursor no WordPress em produção.
Limites honestos: a aba precisa estar aberta (não roda em modo headless), a spec ainda muda, e Firefox/Safari ainda não estão disponíveis. Edge aparece experimental. Vale feature-detect e degradar sem quebrar o form humano.
Três camadas de prontidão
Trate agentes como mais um consumidor do site, na mesma linha de SEO e a11y:
- Base humana: contraste, teclado, labels, CLS estável. Se o form é ruim para pessoa, será pior para agente.
- Descoberta:
llms.txte equivalentes ajudam modelos a achar o que o site é. Não executam ações na página. - Ação: WebMCP: tools para preencher, filtrar, reservar. Comece por um form de conversão (orçamento, contato, lead).
Não trate WebMCP como fator de ranking do Google Search. Trate como engenharia de interface para um cliente novo.
llms.txt ainda falha na mesma URL (camada de descoberta ≠ ação).Declarativo no WordPress: o form é a tool
O caminho mais barato e alinhado ao audit de form-coverage é anotar o HTML que o visitante já vê:
<form
method="post"
action="…"
toolname="solicitar_orcamento"
tooldescription="Envia um pedido de orçamento. Use quando o visitante quiser orçamento de projeto web. Não envie sozinho: apenas preencha os campos."
>
<input name="nome" type="text" required
toolparamdescription="Nome completo de quem solicita o orçamento." />
<input name="email" type="email" required
toolparamdescription="E-mail para resposta." />
<!-- selects, textarea, nonce, submit humano -->
</form>Sem toolautosubmit no dia 1: o agente preenche; a pessoa (ou um passo explícito de confirmação) envia. Nonce, sanitização e antispam continuam iguais.
No lab, o mesmo caso (“solicitar orçamento”) funcionou assim:
| Superfície | Como anotar (ideia) | Observação prática |
|---|---|---|
| HTML / shortcode / bloco Gutenberg | Markup direto | Baseline mais limpa |
| Fluent Forms | fluentform/html_attributes + rendering_field_data_* | Melhor encaixe de hooks entre os builders testados |
| Contact Form 7 | wpcf7_form_additional_atts + elementos | Select: values muitas vezes = rótulos |
| WPForms | wpforms_frontend_form_atts + wpforms_field_properties | Em select, properties.inputs = choices; não inventar inputs.primary |
| Forminator | filtro de markup | SSR viável |
| Ninja Forms | pós-nfFormReady / templates | Backbone: attrs só depois do JS |
| SureForms (blocos) | shortcode/bloco + cuidado com UI | Tom Select / hidden: anotar o campo que a validação lê |
Gravity Forms não rodei no lab (licença), mas a API pública gform_form_tag sugere o mesmo padrão de injeção no <form>.
A lição editorial: não falta form builder. Falta produto maduro que só injete attrs declarativos no markup real. A maior parte do ecossistema WebMCP no wp.org ainda fala em REST, inventário de posts ou tools paralelas ao formulário.
solicitar_orcamento_fluent e o schema dos campos, ao lado do formulário Fluent Forms no lab.Lab open-source (GitHub + Playground)
Publiquei o código do lab em silvaitamar/wp-webmcp-forms (MIT): shortcode, bloco Gutenberg e adaptadores para Fluent, CF7, WPForms, Forminator, Ninja e SureForms, sempre anotando o HTML real, sem bridge REST e sem autosubmit.
Para testar sem instalar WordPress local:
- Chrome com
chrome://flags/#enable-webmcp-testing→ Enabled → reinicie - Abra o lab no WordPress Playground em aba top-level
- No hub
/lab-webmcp/, abra uma demo (ex.: Fluent) → Model Context Tool Inspector → Execute Tool com um JSON emfixtures/ - Confira os campos e envie o formulário como humano
Código e docs: github.com/silvaitamar/wp-webmcp-forms.
O que o mercado já oferece
Em agosto de 2026, o quadro aproximado (buckets wp.org):
- WebMCP Bridge (centenas de installs): líder em conteúdo + Woo + CF7 via tools/REST. Útil, mas não é o mesmo que form-coverage declarativo. Não clone isso.
- BeeClear e similares: discovery, token de origin trial, seletores. Mais “readiness” do que anotador de builder.
- Add-ons nicho (WPForms, Ninja, Gravity/CF7 “WebMCPFY”, etc.): installs baixíssimos; sinal de demanda, não de padrão consolidado.
- Plugins de
llms.txt/ GEO: camada 2, não WebMCP.
Se o plugin registra tools só em JS sem tocar o <form>, não afirme que passa webmcp-form-coverage sem medir.
Quando o imperativo ainda faz sentido
A API registerTool entra quando a ação não é um form HTML estável: wizard multi-step, filtros SPA, checkout com estado rico, ou integração com a Abilities API do core (ponte tipo webmcp-abilities no GitHub).
Para contato e orçamento clássicos, comece declarativo. Menos superfície, mais alinhado ao audit, e o visitante continua vendo o mesmo formulário.
Segurança (as mesmas regras do form)
WebMCP não inventa um canal secreto. A tool corre no contexto da página. Mantenha:
- Nonce / CAPTCHA / honeypot / rate limit como já faria
- Sem autosubmit no primeiro ciclo
- Descrições claras (“preencha; não envie sozinho”)
- Origin isolation e Permissions Policy
tools(docs Chrome) - Em produção no trial: token OT; depois da chegada ao Chrome estável, reavaliar a spec
Agente com quota Gemini esgotada na extensão não prova que o WebMCP falhou. No lab, Execute Tool com fixture JSON foi suficiente para validar schema e preenchimento.
Checklist desta semana
Fazer agora
- Rodar Lighthouse com categoria de navegação agêntica numa URL de conversão
- Escolher um form (contato ou orçamento) e listar campos com descrições úteis
- Anotar
toolname/tooldescription/toolparamdescription(tema, snippet ou filtro do builder) - Feature-detect: se não houver
document.modelContext, o form humano segue igual - Validar com Tool Inspector ou Execute Tool (não só prompt NL)
- Publicar ou revisar
llms.txt(descoberta), sem misturar com execução
Esperar / acompanhar
- Fim do origin trial e comportamento no Chrome 157
- Consumo real por Gemini in Chrome e outros agentes
- Maturação de anotadores declarativos por builder (Fluent primeiro é o caminho natural)
Por onde começar
WordPress já serve o visitante humano. WebMCP é o contrato para o assistente no browser usar a mesma interface, começando pelo formulário que já existe. O mercado de plugins ainda empurra inventário e REST; o audit que importa para forms olha o HTML.
Testei o caminho declarativo num lab limpo, com vários builders e um bloco Gutenberg. A API ainda é trial. O padrão de engenharia (attrs, feature-detect, sem autosubmit) já dá para adotar. O lab no Playground e o GitHub estão abertos para você repetir o teste.
Acompanhe o ritmo no IA+WP e na Lista VIP quando quiser os próximos artigos do cluster.
Perguntas frequentes
WebMCP é o mesmo que o MCP (Model Context Protocol)?
Não. O MCP é um protocolo aberto para tools entre servidor e cliente (IDE, desktop, adapters). WebMCP expõe tools da página para agentes no browser do visitante.
O WebMCP já está disponível no Chrome estável?
Não (agosto de 2026). Está em origin trial nos Chrome 149–156, com disponibilização prevista no Chrome 157. Em localhost use a flag #enable-webmcp-testing.
Preciso de token de origin trial no localhost?
Não. A flag local basta. Token é para origem registrada em produção durante o trial.
Qual form builder é o melhor ponto de partida no WordPress?
Fluent Forms teve o encaixe de hooks mais limpo no lab. Form nativo ou bloco Gutenberg é ainda mais direto se você controla o markup. CF7 e WPForms funcionam com adaptadores; Ninja exige passo pós-JS.
WebMCP melhora o SEO do site?
Não há evidência de fator de ranking no Google Search. Há auditoria de navegação agêntica no Lighthouse e engenharia de interface para agentes. Trate como prontidão técnica, não como “hack de posição”.
Qual a diferença entre llms.txt e WebMCP?
llms.txt ajuda na descoberta (o que o site é). WebMCP declara ações executáveis na página aberta. São camadas complementares, não substitutas.
Onde testo o lab sem instalar WordPress?
No WordPress Playground com o código em silvaitamar/wp-webmcp-forms. Use Chrome com a flag WebMCP e o Tool Inspector; prefira aba top-level.