A viragem agêntica: como os agentes de IA estão a mudar a escolha de plataforma, o design e a segurança no WordPress

#Como os agentes de IA escolhem uma plataforma CMS

A escolha de plataforma era uma decisão humana, tomada por donos de empresas, agências e CTOs. Andy Peatling, que passou 17 anos na Automattic e desenvolve agora o Miles, um agente de design com IA para WordPress, defende que esse caminho se está a fechar. Em Ideas for WordPress in an agentic world (14 de setembro de 2026), escreve que um agente escolhe uma plataforma a partir dos seus dados de treino ou de uma pesquisa na web, e consegue montar um site simples em cerca de 30 segundos. A conclusão é direta: “Se o WordPress não estiver a ser escolhido, o projeto não vai crescer.” (tradução própria)

Faz três propostas concretas:

• Dois percursos de agente assumidos. O WordPress deve definir e comprometer-se publicamente com dois percursos completos que um agente consiga executar do início ao fim, por exemplo um site construído inteiramente por um agente de programação, desde a criação até à publicação e ao alojamento. Aponta Abilities, MCP, Agent Skills, metadados de temas e metadados de plugins como a infraestrutura que esses percursos devem ligar, com permissões definidas, aprovações, pontos de reversão e registos de auditoria.
• Benchmarks públicos. Acompanhar o sucesso dos agentes nesses percursos, registar quando e porquê os agentes incluem ou excluem o WordPress na escolha de plataforma, e medir as capacidades nativas dos agentes com ferramentas como o WP-bench.
• Um único recurso para agentes no WordPress.org. Explicar onde o WordPress é a escolha certa e onde não é, assinalar claramente as APIs atuais e despromover as mais antigas, e estruturar a documentação para que os agentes a consigam absorver.

A mesma questão atravessou um episódio do WP Minute com Alex Panagis, Brian Coords, Andy Peatling e Mike McAlister, How do we get agents to use WordPress. As notas do episódio registam que os agentes a quem se pede que construam um site nem sempre recomendam o WordPress, que o WordPress precisa de opiniões mais firmes sobre a forma como os agentes o devem usar, e que a Abilities API pode tornar-se a base do WordPress agêntico.

#O que faz a beta do servidor MCP da Elementor no WordPress

A Elementor abriu a sua beta MCP a 15 de setembro de 2026. Expõe capacidades de construção de sites através de abilities do WordPress, para que um cliente MCP possa construir e editar páginas como estruturas nativas da Elementor, em vez de devolver HTML em bruto que alguém tem de colar num modelo. A Elementor indica como clientes o Claude Code, o Claude Desktop, o Codex e o Cursor, bem como qualquer outra ferramenta que fale MCP.

O anúncio enumera nove capacidades:

• construir páginas e layouts atómicos num só passo,
• editar ou redesenhar páginas e layouts atómicos existentes,
• criar, aplicar e reordenar classes e variáveis, definir estados de hover e ajustar breakpoints responsivos,
• criar e gerir partes do tema, como cabeçalhos, rodapés, arquivos e popups, com condições de apresentação,
• colocar, preencher ou criar componentes,
• ligar dados dinâmicos, como campos de artigos, campos personalizados e taxonomias,
• criar widgets personalizados e experiências de administração,
• atualizar conteúdo em massa, depurar erros e corrigir lacunas de SEO,
• aceder a todas as abilities registadas com a Abilities API do WordPress, incluindo as de plugins como WooCommerce, Yoast, WPForms, Jetpack e ACF.

As três últimas exigem o Angie, um plugin separado da Elementor. A beta tem limites claros. O acesso está restrito aos administradores do site, a ligação é feita site a site, e tudo o que o MCP gera é guardado como rascunho, não publicado. A configuração exige o canal de beta testers e o Atomic Editor. A Elementor gera uma palavra-passe de aplicação e insere-a num prompt de configuração para a ferramenta de IA, com uma opção de configuração manual. Os elementos Pro continuam a exigir um plano Pro, e o editor normal mantém-se igual para quem não se ligar.

#Como o Block Runner da Human Made valida blocos Gutenberg

O Block Runner é uma CLI e biblioteca JavaScript de código aberto da Human Made, licenciada sob GPL-2.0-or-later. O seu README descreve-o como uma ferramenta que “converte HTML suportado em blocos Gutenberg nativos e verifica o markup gerado com os pacotes Gutenberg usados pelo editor do WordPress” (tradução própria). O pacote foi publicado pela primeira vez no npm a 24 de junho de 2026; a versão 0.9.10 saiu a 4 de outubro de 2026.

O problema que resolve é conhecido de quem já colou markup gerado no editor: o markup que o editor não reconhece acaba num bloco HTML personalizado ou num bloco que pede recuperação. O Block Runner oferece quatro caminhos, documentados no README:

• convert transforma HTML em markup de blocos com regras incorporadas,
• assemble constrói o conteúdo da página a partir de uma árvore de blocos planeada por um agente,
• author gera o código-fonte de um bloco registado reutilizável, como um bloco de aviso, para um plugin,
• validate e fix verificam ou canonicalizam markup de blocos existente.

O pacote não faz chamadas a modelos de IA. Um agente externo pode interpretar um design e entregar ao Block Runner um plano estruturado, e código determinístico monta e valida depois o resultado. Uma skill incluída para agentes de programação instala-se com npx --no-install block-runner skill --install, que a escreve em .agents/skills/block-runner e .claude/skills/block-runner. A conversão básica precisa de Node.js (20.19+, 22.13+ ou 24+) e dispensa site WordPress, Docker ou agente.

O README é explícito quanto aos limites. Estruturas não suportadas podem ficar como HTML personalizado, com avisos, e --strict faz falhar a execução quando há blocos de recurso e media por resolver. Nas suas próprias palavras: “Um markup válido não prova fidelidade visual nem compatibilidade com todos os sites.” (tradução própria) O resultado tem sempre de ser verificado na instalação WordPress de destino. Para perceber como blocos, padrões e modelos se articulam, consulte o nosso guia de blocos Gutenberg e full site editing.

#Que falhas corrigiu o WordPress 7.1.1 e quem as reportou

O WordPress 7.1.1 foi lançado a 17 de setembro de 2026 como versão de manutenção e segurança: 17 correções de erros no core, 19 correções de erros no editor de blocos e 11 correções de segurança. O anúncio recomenda atualizar de imediato e indica que as correções de segurança estão a ser aplicadas, quando necessário, a todos os ramos que ainda recebem correções de segurança. A lista completa com os créditos, tal como foi publicada:

A Anthropic é creditada por dois dos onze problemas, e a pwn.ai partilha um crédito com Paulos Yibelo. Ambos os problemas da Anthropic exigem uma conta autenticada, um deles apenas ao nível de Contributor. Isto conta nas configurações com agentes: um agente ligado a um site age como um utilizador do WordPress, por isso o papel que lhe atribui decide quais destas classes de erros poderia atingir numa instalação sem atualização. O nosso guia de reforço da segurança do WordPress trata de papéis, atualizações e monitorização.

#Evento de WordPress e IA em Faro, outubro de 2026

A Comunidade Portuguesa de WordPress organiza o WordPress Day for AI Faro 2026 a 24 de outubro de 2026, no hotel AP Eva Senses, em Faro. Segundo o site do evento, decorre das 09:00 às 18:00, com 100 lugares, e as palestras são em português e inglês.

Há duas tracks. A de IA para Desenvolvimento abrange desenvolvimento assistido por IA, ferramentas de programação, APIs, automação, integrações com LLM, MCP e fluxos de trabalho de desenvolvimento em WordPress. A de IA para Negócios destina-se a donos de empresas, agências e profissionais e aborda produtividade, automação de fluxos de trabalho e experiência do cliente.

#O que é a Abilities API do WordPress e como se regista uma ability

A Abilities API é a camada sobre a qual a Elementor constrói. A sua parte do lado do servidor chegou com o WordPress 6.9. Uma ability é uma unidade de funcionalidade com nome, no formato namespace/ability-name, registada com wp_register_ability() dentro de um callback no hook wp_abilities_api_init. Cada ability pertence a exatamente uma categoria, registada com wp_register_ability_category() em wp_abilities_api_categories_init.

Os argumentos obrigatórios são label, description, category, output_schema, execute_callback e permission_callback. input_schema é opcional e só é necessário quando a ability recebe dados de entrada. Ambos os esquemas são JSON Schema, e uma entrada que falhe a validação nunca chega ao callback de permissões. O array meta transporta indicações de comportamento em annotations: readonly, destructive e idempotent.

add_action( 'wp_abilities_api_init', function () {
	wp_register_ability( 'my-plugin/get-site-title', array(
		'label'               => __( 'Get site title', 'my-plugin' ),
		'description'         => __( 'Returns the title of this site.', 'my-plugin' ),
		'category'            => 'site',
		'output_schema'       => array( 'type' => 'string' ),
		'execute_callback'    => fn() => get_bloginfo( 'name' ),
		'permission_callback' => fn() => current_user_can( 'read' ),
		'meta'                => array(
			'annotations'  => array( 'readonly' => true ),
			'show_in_rest' => true,
		),
	) );
} );

Há duas predefinições que convém conhecer. As abilities não são expostas via REST a menos que show_in_rest esteja definido como true, e os endpoints REST em /wp-json/wp-abilities/v1 exigem um utilizador autenticado e respeitam o callback de permissões de cada ability. O próprio core regista três abilities no 6.9: core/get-site-info, core/get-user-info e core/get-environment-info. O repositório autónomo no GitHub foi arquivado depois da integração no core. Para exemplos práticos de abilities em fluxos editoriais, veja fluxos de trabalho de IA no WordPress com a Abilities API.

#Como o MCP Adapter do WordPress expõe abilities a clientes MCP

O MCP Adapter é o pacote oficial do WordPress que transforma abilities em ferramentas, recursos e prompts MCP. A versão 0.7.0, lançada a 2 de outubro de 2026, torna-o um plugin canónico. Os plugins devem declarar Requires Plugins: mcp-adapter no cabeçalho em vez de incluírem uma cópia; as cópias incluídas continuam a funcionar, mas registam um aviso de descontinuação.

Atualização, 28 de outubro de 2026. A versão atual é a 0.7.1, lançada a 16 de outubro de 2026. Acrescenta um guia de configuração passo a passo para proprietários de sites: ligar um cliente de IA, criar uma palavra-passe de aplicação, testar a ligação e resolver problemas comuns. Quando um cliente pede uma ability que não existe, o adaptador sugere abilities disponíveis semelhantes ou encaminha o cliente para a descoberta.

As abilities são privadas por predefinição. Uma ability só chega ao MCP quando meta.public (ou meta.mcp.public) é true. O servidor predefinido, em /wp-json/mcp/mcp-adapter-default-server, expõe três meta-ferramentas em vez de uma ferramenta por ability: mcp-adapter-discover-abilities, mcp-adapter-get-ability-info e mcp-adapter-execute-ability. O agente lista o que está disponível, obtém o esquema de que precisa e depois executa. Assim, a resposta de tools/list fica em três esquemas, por muitos plugins que registem abilities. Um servidor personalizado criado no hook mcp_adapter_init faz o contrário e lista cada ability escolhida como ferramenta própria.

Há duas formas de ligar um cliente:

• STDIO através do WP-CLI: wp mcp-adapter serve --server=mcp-adapter-default-server --user=admin. A flag --user decide com que utilizador do WordPress correm as verificações de permissões; sem ela, a sessão não é autenticada.
• HTTP através do proxy @automattic/mcp-wordpress-remote, que se autentica com uma palavra-passe de aplicação.

A segurança funciona em duas camadas. Um callback de permissões do transporte protege o servidor inteiro e usa por predefinição is_user_logged_in(), e cada ability continua a executar o seu próprio permission_callback. O adaptador suporta as revisões do protocolo MCP 2025-11-25 e 2026-07-28; os clientes mais antigos são servidos através do esquema 2025-11-25.

#O que a especificação MCP exige das ferramentas e dos hosts

A especificação do Model Context Protocol define mensagens JSON-RPC 2.0 entre hosts (as aplicações de LLM), clientes (conectores dentro do host) e servidores (serviços que fornecem contexto e capacidades). Os servidores podem oferecer recursos, prompts e ferramentas. A revisão atual, 2026-07-28, define dois transportes padrão: stdio, para um subprocesso lançado pelo cliente, e Streamable HTTP, em que cada mensagem é um POST para um único endpoint.

O capítulo sobre ferramentas define as regras que importam quando um agente escreve no WordPress. Deve existir sempre uma pessoa no circuito capaz de recusar invocações de ferramentas. Os servidores têm de validar todas as entradas das ferramentas, implementar controlos de acesso, limitar a taxa de invocações e sanitizar as saídas. Os clientes devem pedir confirmação em operações sensíveis, mostrar as entradas das ferramentas antes da chamada, definir timeouts e registar a utilização das ferramentas. As anotações das ferramentas têm de ser tratadas como não fidedignas, a menos que venham de um servidor fidedigno.

As peças do WordPress encaixam nestas regras. A validação JSON Schema da Abilities API cobre a verificação das entradas, o permission_callback cobre o controlo de acesso, as anotações readonly e destructive indicam ao cliente que chamadas precisam de confirmação, e o comportamento só em rascunho da Elementor mantém uma pessoa entre o agente e a página publicada. O adaptador não inclui limitador de taxa (o seu guia de observabilidade apenas lista um código de erro ability_rate_limit que uma ability pode devolver), por isso a limitação de taxa fica a cargo da camada de alojamento ou da própria ability.

#Como funcionam os server cards MCP na descoberta

Os agentes também precisam de encontrar um servidor antes de se poderem ligar. A SEP-2127, que atingiu o estado Final como extensão, define os MCP Server Cards: documentos estáticos de metadados que descrevem a identidade de um servidor remoto, os endpoints de transporte e as versões do protocolo suportadas. Um card pode ficar em qualquer URI não reservado, sendo streamable-http-url/server-card reservado como localização recomendada. Para a descoberta ao nível do domínio, um AI Catalog publicado em /.well-known/ai-catalog.json pode apontar para os cards ou incorporá-los.

Os cards deixam de fora, de propósito, ferramentas, recursos e prompts. A SEP explica que aquilo que um servidor expõe pode variar consoante o utilizador, a sessão e a configuração, por isso os clientes têm de usar a chamada tools/list em tempo real. Os cards não podem conter credenciais nem dados específicos do utilizador, e são opcionais: os servidores sem card continuam a funcionar. No WordPress, o URL do endpoint do adaptador é a base natural para um card. O nosso guia do servidor MCP ao vivo da WPPoland mostra um servidor público só de leitura na prática.

#Como construir sites WordPress para agentes de IA e GEO

O wppoland.com corre em Astro 7 no Cloudflare Pages, com dados Schema.org gerados a partir do frontmatter em todas as páginas. A nossa regra de trabalho é que uma página deve ser tão fácil de ler para uma máquina como para uma pessoa. Para sites WordPress, o caminho documentado é curto: registe abilities com esquemas e anotações fiéis, publique através do MCP Adapter apenas as que quer tornar públicas, dê ao agente um utilizador do WordPress com o papel mais restrito que faça o trabalho, e mantenha as alterações de conteúdo como rascunhos até uma pessoa as aprovar. Os mesmos dados estruturados servem também a Generative Engine Optimization (GEO). Quando o Agent e o MCP write alojados no WordPress.com chegam versus um adaptador self-hosted, veja WordPress.com Agent e MCP write.

Se quiser ajuda com isso, conheça o nosso serviço de desenvolvimento de servidores MCP ou peça uma auditoria.