MCP 插件生态更容易使用

MCP 让 WordPress 自动化更有用，但这个生态已经大到需要给新用户一个更清楚的起点。

一个插件很容易解释。可是核心插件、适配器、一组 add-on、GitHub 发布、WordPress 页面，以及必须按顺序完成的设置步骤放在一起，就很容易变成一团拼图。我们正在消除的正是这种阻力。

目标很简单：让人一眼看懂先装什么、每个 add-on 做什么，以及怎样开放有用的 WordPress 能力，而不是把一个模糊、失控的后台表面交给 AI 助手。

问题不在插件本身

插件本身已经在做有用的工作。薄弱点是围绕它们的使用路径。

对想在真实 WordPress 站点上尝试 MCP 的人来说，这些都不是小问题。如果设置路径不清楚，真正有用的部分就开始得太晚。

我们清理了 Devenia 的插件页面，让核心插件和 add-on 用一致的方式解释同一个生态。
我们更新了过期的数量、发布说明和链接，避免旧页面听起来比主插件页面还新。
我们把 MCP Expose Abilities 页面重建为可维护的 Gutenberg 内容。
我们把安装路径讲得更清楚：先 Abilities API 和 MCP Adapter，再 MCP Expose Abilities，然后只安装站点真正需要的 add-on。
我们按 add-on 所控制的 WordPress 工作类型重新分组，让生态更容易扫读。

这种整理不是外观修饰。它会改变项目给人的感觉：是容易进入的系统，还是一堆强大但没有入口的工具。

当前 MCP Expose Abilities 页面记录了核心插件中的 67 个 WordPress 原生能力。整个维护中的栈现在包含 18 个已发布 add-on，以及超过 450 个已记录能力。

这并不表示每个站点都应该全部安装。重点正好相反。GeneratePress 站点不需要 Elementor 能力。没有 Brevo 的站点不需要 Brevo 能力。更小的安装面更容易理解，也更容易保持安全。

WordPress 核心工作：文章、页面、媒体、菜单、用户、评论、分类法、插件、选项、小工具、调试，以及与缓存相关的操作。
编辑器和构建器工作：Gutenberg、GeneratePress、GenerateBlocks、Elementor、模板、区块样式和布局数据。
运营工作：Rank Math、Wordfence、Cloudflare、Cache Enabler、Broken Link Checker、Brevo、WPML、Toolset、Formidable、Advanced Ads、文件系统、数据库、插件检查和 workspace 邮件流程。

这就是我们希望别人看到的更清楚的信息：从核心开始，只添加与站点匹配的部分，并让每个开放操作都有名称、可检查。

好的自动化不是从最长的功能列表开始。它从信任开始：你能否理解助手被允许做什么、这个能力为什么存在，以及正确的 WordPress 权限是否仍然适用？

这就是 add-on 模型重要的原因。它让站点开放一组聚焦的能力，而不是把所有 WordPress 操作都当成一扇全开或全关的大门。

对站点所有者或开发者来说，这意味着第一次有用测试之前少一些猜测。对 agent 工作流来说，这意味着工具更清楚、权限更干净、意外绕路更少。

如果你现在要尝试这个生态，实用路径是：

这样，助手可以获得有用的 WordPress 访问能力，而不会让设置过程比它要节省的工作还复杂。

我们会继续收紧插件周围的部分：更清楚的 onboarding、更好的发布说明、更强的页面链接，以及减少 GitHub、WordPress 和 Devenia 页面之间的漂移。

这不只是文档工作。它是为自动化栈做产品设计。强大的工具只有在人们知道从哪里开始、哪些操作安全时，才会更有用。

如果你想看当前概览，可以从 MCP Expose Abilities 开始。