claude-plugins/wordpress/skills/mcp-abilities-elementor/SKILL.md

name, description, layer

name	description	layer
mcp-abilities-elementor	Plugin WordPress de terceiros (Devenia, GPLv2) que expõe 89 abilities Elementor via a WordPress Abilities API nativa (core 6.9+) — CRUD de páginas/elementos/templates, gestão de kits, e uma camada de auditoria de qualidade de design sem equivalente no EMCP Tools. Instalado e testado ao vivo em emanuelalmeida.pt (19-08-2026). Usar quando "mcp-abilities-elementor", "wordpress abilities api elementor", "evaluate-design elementor", "audit generic layout", "delete-template elementor", "kit settings elementor mcp", "score-distinctiveness".	wiki

/mcp-abilities-elementor — Plugin de Abilities Elementor (Devenia)

Instalado e testado ao vivo em emanuelalmeida.pt (19-08-2026): download https://downloads.devenia.com/mcp-abilities-elementor.zip → wp plugin install ... --activate. Fonte: github.com/bjornfix/mcp-abilities-elementor (GPLv2, 24★). Requer WP 6.9+ (confirmado: site em 7.0.4), PHP 8.0+, Elementor activo; Elementor Pro opcional (Theme Builder/Custom Code/Form Submissions ficam indisponíveis sem Pro — confirmado: list-custom-code devolveu {"success":false,"message":"Elementor custom code post type is not available"} mesmo com Elementor Pro 4.0.0 activo, porque essa funcionalidade Pro específica não está disponível nesta versão/licença).

🔴 Arquitectura — NÃO está acessível por MCP nesta sessão, só por wp-cli/PHP

Este plugin regista abilities na WordPress Abilities API nativa (wp_register_ability(), ver skill genérica sobre a API). Ele não cria o próprio servidor MCP — o seu mcp-abilities-elementor.php (228KB) não tem uma única referência a mcp_adapter/McpServer/register_server.

Causa-raiz confirmada ao vivo (não é falta de instalação, é falta de opt-in): o WordPress MCP Adapter oficial (github.com/WordPress/mcp-adapter) cria automaticamente um "default server" que expõe qualquer ability com a meta-flag meta.public: true (ou meta.mcp.public: true) através de 3 tools dispatcher (discover-abilities/get-ability-info/execute-ability) — exactamente o padrão que o mcp-adapter-default-server (13 tools) já visível em wp mcp-adapter list neste site implementa (o EMCP Tools bundla esta mesma biblioteca internamente). Confirmei via wp eval "wp_get_ability('elementor/get-theme-context')->get_meta()": devolve {"annotations":{...},"show_in_rest":false} — sem public nem mcp.public. O mcp-abilities-elementor nunca marcou nenhuma das 89 abilities como pública para MCP, nem criou um servidor custom a listá-las explicitamente ($adapter->create_server(...) com a lista de ability names). Resultado: mesmo com o WordPress MCP Adapter oficial activo neste site, estas abilities continuariam invisíveis ao servidor por omissão — falta o meta.public/meta.mcp.public no registo, ou um servidor custom que as liste. Isto teria de ser corrigido pelo autor do plugin (Devenia) numa actualização, ou por nós via um mu-plugin que registe um servidor custom com as 89 abilities.

Caminho de teste usado, funcional e reproduzível: chamar a ability directamente via WP_Ability::execute() por wp eval-file, sem transporte MCP nenhum — o mesmo caminho de código que o execute-ability do MCP Adapter acabaria por invocar:

# harness reutilizável (criar uma vez em /tmp/ability-test.php no servidor):
cat > /tmp/ability-test.php << 'PHPEOF'
<?php
$name = $args[0] ?? '';
$input = isset($args[1]) ? json_decode($args[1], true) : [];
$ability = wp_get_ability($name);
if (!$ability) { echo json_encode(['error' => 'ability not found', 'name' => $name]); return; }
try {
    echo json_encode($ability->execute($input ?: []), JSON_PRETTY_PRINT | JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE);
} catch (\Throwable $e) {
    echo json_encode(['error' => 'exception', 'message' => $e->getMessage()]);
}
PHPEOF

# chamar uma ability:
wp eval-file /tmp/ability-test.php 'elementor/get-theme-context' '{}' --path=/caminho/do/site --allow-root --user=1

--user=1 é obrigatório — sem utilizador definido, current_user_can() dentro do permission_callback de cada ability falha silenciosamente/nega acesso, porque o wp-cli corre sem contexto de utilizador autenticado por omissão.

Catálogo (89 abilities, 7 categorias)

Ver references/catalogo.md para a tabela completa com descrição de cada uma. Resumo por categoria: Page/Post Data (43), Authoring Primitives (12), Template Management (11), Theme Builder (2), Custom Code/Pro (5), Form Submissions/Pro (3), Site Tools & Settings (11) — soma o namespace elementor/* completo confirmado ao vivo (wp eval 'count(array_filter(array_keys(wp_get_abilities()), fn($k)=>str_starts_with($k,"elementor/")))' → 89).

O que isto tem que o EMCP Tools não tem

• Camada de auditoria de qualidade de design — evaluate-design, audit-generic-layout-patterns, score-distinctiveness, audit-generic-component-repetition, audit-surface-overuse, audit-emphasis-drift, audit-section-rivalry, audit-composition-rhythm, audit-separator-discipline, audit-column-* (5 variantes), extract-design-tokens, apply-text-hierarchy, normalize-section-spacing-rhythm, normalize-responsive-values, sync-component-variant. Testado ao vivo em emanuelalmeida.pt post_id 9 ("Sobre mim"): evaluate-design devolveu score: 88, recommendations: ["Top-level section composition is repeating. Increase compositional contrast between adjacent sections."], com breakdown por categoria (generic_layout, distinctiveness, component_overuse, etc.) incluindo assinaturas de secção e penalizações concretas. Genuinamente útil — sem equivalente algum no EMCP.
• CRUD de templates completo, incluindo delete-template — testado ao vivo: criei um template de secção (create-template, id 18168), depois delete-template({id:18168, force:true}) apagou-o em definitivo com sucesso. Isto preenche exactamente o gap que documentei em emcp-page-building ("Não há tool de eliminação de template no conjunto comummente activo").
• Multi-kit — list-kits/get-kit-settings/set-active-kit. Testado: emanuelalmeida.pt tem 2 kits (Kit Padrão id 14 inactivo, Default Kit id 11 activo) — EMCP só expõe o kit activo via get-global-settings.
• get-official-widget-catalog/get-official-pattern-guidance — vai buscar o catálogo/orientação oficiais a elementor.com em tempo real, em vez de uma lista estática mantida à mão.
• Form Submissions CRUD (Pro) e Custom Code CRUD (Pro) completos — EMCP só tem fragmentos, maioritariamente desligados por omissão.

O que isto NÃO tem / é pior que o EMCP

• Não suporta elementos atómicos Elementor 4.0 — confirmado ao vivo: add-container/add-heading neste site (Elementor 4.2.2, atomic-capable) produzem elType: "container"/widgetType: "heading" legacy, nunca e-flexbox/e-heading. Para construção atómica v4, usar emcp-page-building (EMCP), não este plugin.
• Nenhuma gestão de conteúdo WordPress genérico — sem posts/pages/CPTs/media/menus/utilizadores/plugins fora do âmbito Elementor. Complementa, não substitui, emcp-content-ops.

🔴 Armadilhas e bugs confirmados ao vivo

1. Gate "template-first" em todas as abilities de "Authoring Primitives" — add-container/add-heading/etc. recusam-se a correr sem template_lookup_status explícito (ou uma chamada prévia a find-template-for-pattern). Testado: add-container sem esse campo devolveu {"success":false,"message":"Raw Elementor container authoring requires template lookup status. Call elementor/find-template-for-pattern first...","required_next_step":"elementor/find-template-for-pattern"}. Para edições pontuais legítimas (não um padrão reutilizável), passar "template_lookup_status":"not_a_reusable_pattern" — confirmado a destravar a chamada.
2. update-element espera o elemento COMPLETO em element_data (com id), não um merge parcial de settings. Diferente da convenção do EMCP (update-element/update-atomic-widget fazem merge parcial por omissão). Testado: {"element_id":"x","settings":{...}} falha ("element_data é obrigatório"); {"element_data":{"settings":{...}}} falha de novo ("Element data must include a string 'id'") — só funciona com o objecto completo {"element_data":{"id":"x","elType":"widget","widgetType":"...","settings":{...}}}. Confirmado também no changelog (v2.2.9): "guardrails... incomplete replacement payloads do not silently wipe populated Elementor containers/widgets unless force_replace=true" — o comportamento por omissão é substituição total, não merge.
3. delete-element recusa apagar sem force_delete:true mesmo num elemento aninhado (não literalmente top-level da página) — testado, mensagem "Refusing to delete a top-level Elementor element without force_delete=true". Passar sempre force_delete:true quando a intenção é mesmo apagar.
4. 🐛 Bug confirmado — add-heading (e provavelmente as outras "Authoring Primitives") grava os parâmetros de controlo da própria ability dentro do settings persistido do widget Elementor. Testado: depois de add-heading({..., "template_lookup_status":"not_a_reusable_pattern"}), get-element devolveu settings: {"parent_id":"980c94d","title":"...","template_lookup_status":"not_a_reusable_pattern","header_size":"h2"} — parent_id e template_lookup_status não são controlos Elementor válidos, ficaram poluindo os dados reais do widget. Reportável ao autor; entretanto, não confiar cegamente no settings devolvido por get-element/get-data para saber quais chaves são controlos genuínos.
5. 🐛 Bug confirmado — list-experiments emite PHP Warning: Array to string conversion em register-site-tools.php:632. Não é fatal (a chamada ainda devolve success:true com os dados), mas polui stderr/logs.
6. Aplicação de estilo global (documentada no changelog, não testada nesta sessão): desde a v2.3.6, escritas rejeitam cores/tipografia locais que não correspondam a um token global do Kit — cores hex locais são normalizadas para o token global correspondente quando possível, senão a escrita é rejeitada com "structured violations". apply-text-hierarchy desde então usa por omissão referências de tipografia global do kit em vez de overrides locais. Verificar isto ao vivo antes de confiar cegamente — não reproduzi este comportamento nesta sessão (só toquei em title, não em cor/tipografia).
7. elementor/update-data, elementor/clone-data, elementor/patch-data exigem confirmação explícita por ability antes de escrever dados brutos do documento Elementor (desde v2.3.11) — não testado nesta sessão, mas documentado no changelog; esperar um campo confirm-like obrigatório.

Estado no site (19-08-2026)

Instalado e activo em emanuelalmeida.pt (mcp-abilities-elementor v2.3.36). Todos os artefactos de teste foram removidos (página de rascunho #18166 apagada em definitivo via wp post delete --force; template de secção #18168 apagado via elementor/delete-template). Decisão em aberto: o plugin fica activo mas inacessível por MCP até se instalar o WordPress MCP Adapter oficial separado ou se estender a config do servidor MCP do EMCP Tools — nenhuma das duas foi feita nesta sessão. Só chamável via wp eval-file (padrão acima) até essa decisão ser tomada.

Skills relacionadas

• emcp-page-building — construção atómica Elementor 4.0 via EMCP (este plugin não suporta atómico).
• emcp-content-ops / emcp-site-audit — gestão de conteúdo WordPress genérico e segurança/performance (fora do âmbito deste plugin).