diff --git a/wordpress/skills/mcp-abilities-elementor/SKILL.md b/wordpress/skills/mcp-abilities-elementor/SKILL.md
index d36b241..5692c73 100644
--- a/wordpress/skills/mcp-abilities-elementor/SKILL.md
+++ b/wordpress/skills/mcp-abilities-elementor/SKILL.md
@@ -10,11 +10,11 @@ Instalado e testado ao vivo em `emanuelalmeida.pt` (19-08-2026): download `https
 
 ## 🔴 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 nem se liga ao adapter interno do EMCP Tools — o seu `mcp-abilities-elementor.php` (228KB) não tem uma única referência a `mcp_adapter`/`McpServer`/`register_server`. Confirmado ao vivo: depois de activo, `wp mcp-adapter list` continua a mostrar só os 3 servidores de sempre (`elementskit-mcp-server`, `mcp-adapter-default-server`, `emcp-tools-server`) — nenhum servidor novo apareceu, e as 89 abilities `elementor/*` **não** entraram em nenhum deles (o `mcp-adapter-default-server` é configurado explicitamente pelo EMCP Tools via o filtro `mcp_adapter_default_server_config`, não expõe automaticamente tudo o que está no registry core).
+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`.
 
-O README do plugin assume que existe uma instalação separada do **WordPress MCP Adapter oficial** (`github.com/WordPress/mcp-adapter`) como plugin próprio — que **não está instalado** neste site. Instalar esse segundo plugin não foi tentado nesta sessão (risco de colisão de classes com a cópia que o EMCP Tools já bundla internamente, por confirmar antes de tentar).
+**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 um cliente MCP acabaria por invocar:
+**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:
 
 ```bash
 # harness reutilizável (criar uma vez em /tmp/ability-test.php no servidor):