O problema não eram os plugins
Os plugins já faziam trabalho útil. O ponto fraco era o caminho à volta deles.
- Que plugin deve ser instalado primeiro?
- Que add-ons são opcionais?
- Que página tem a informação de release atual?
- O que o plugin central trata, e o que pertence a um add-on?
- Como saber se o ecossistema continua mantido?
Estas não são perguntas pequenas para quem está a experimentar MCP num site WordPress real. Se o caminho de configuração não é claro, a parte útil começa tarde demais.
O que mudámos
- Limpámos as páginas de plugins da Devenia para que o plugin central e os add-ons expliquem o mesmo ecossistema de forma consistente.
- Atualizámos contagens antigas, referências de release e links que faziam páginas antigas parecerem mais recentes do que a página principal do plugin.
- Reconstruímos a página MCP Expose Abilities em conteúdo Gutenberg fácil de manter.
- Tornámos o caminho de instalação mais claro: Abilities API e MCP Adapter primeiro, depois MCP Expose Abilities, e só então os add-ons de que o site realmente precisa.
- Tornámos o ecossistema mais fácil de percorrer, agrupando add-ons pelo trabalho WordPress que controlam.
Este tipo de limpeza não é cosmética. Muda a forma como o projeto é percebido: acessível, ou apenas uma pilha de ferramentas poderosas sem entrada óbvia.
A forma atual do ecossistema
A página atual do MCP Expose Abilities documenta 67 capacidades WordPress nativas no plugin central. A stack mantida mais ampla tem agora 18 add-ons lançados e mais de 450 capacidades documentadas.
Isto não significa que todos os sites devam instalar tudo. O ponto é o oposto. Um site GeneratePress não precisa de capacidades Elementor. Um site sem Brevo não precisa de capacidades Brevo. Uma superfície de instalação pequena é mais fácil de compreender e manter segura.
Trabalho WordPress central
Trabalho de editor e construtor
Trabalho operacional
Esta é a mensagem mais clara que queremos mostrar: começar pelo núcleo, adicionar apenas o que corresponde ao site e manter cada operação exposta nomeada e inspecionável.
Porque isto importa além dos detalhes técnicos
Boa automação não começa com a maior lista possível de funcionalidades. Começa com confiança: é possível perceber o que o assistente pode fazer, porque essa capacidade existe e se a permissão WordPress correta ainda se aplica?
É por isso que o modelo de add-ons importa. Ele permite que um site exponha um conjunto focado de capacidades em vez de tratar cada operação WordPress como uma porta gigante de tudo ou nada.
Para o proprietário ou programador de um site, isso significa menos adivinhação antes do primeiro teste útil. Para um fluxo com agentes, significa ferramentas mais claras, permissões mais limpas e menos desvios acidentais.
Um primeiro caminho melhor
Se está a experimentar o ecossistema agora, o caminho prático é:
1
2
3
4
5
Assim, o assistente recebe acesso WordPress útil sem tornar a configuração mais difícil do que o trabalho que deveria poupar.
O que vem a seguir
Continuaremos a apertar as partes em torno dos plugins: onboarding mais claro, melhores notas de release, links de página mais fortes e menos desvio entre GitHub, WordPress e as páginas da Devenia.
O trabalho não é apenas documentação. É desenho de produto para uma stack de automação. Ferramentas poderosas tornam-se mais úteis quando as pessoas sabem por onde começar e o que é seguro executar.
Comece por MCP Expose Abilities se quiser a visão geral atual.