ealmeida/claude-plugins
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix(wordpress): mcp-abilities-elementor - causa-raiz exacta da nao-exposicao MCP

Browse Source 
Confirmado via WordPress/mcp-adapter README + wp eval ao vivo: o plugin
nao esta invisivel por falta do WP MCP Adapter instalado, mas por nunca
ter marcado nenhuma das 89 abilities com meta.public/meta.mcp.public
nem criado servidor MCP custom. get_meta() confirma ausencia da flag.
This commit is contained in:
Claude Code
2026-08-19 04:19:45 +01:00
parent 8bfdd34bb6
commit 000faca193
1 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
wordpress/skills/mcp-abilities-elementor/SKILL.md
+3 -3
View File
@@ -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 ## 🔴 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 ```bash
# harness reutilizável (criar uma vez em /tmp/ability-test.php no servidor): # harness reutilizável (criar uma vez em /tmp/ability-test.php no servidor):