WordPress MCP vs Headless CMS MCP：代理就绪堆栈

WordPress MCP 现在有了官方途径：Abilities API（在 WordPress 6.9 中推出）加上 MCP Adapter，它将能力转化为代理可以调用的工具。很好。Headless CMS 通过自己的第一方服务器更早达到了这一点，而基于 git 的网站通过强制每个代理编辑经过拉取请求才能进入生产环境，避免了许多相同的麻烦。这些堆栈中没有一个默认是安全的。真正的区别在于安全性的位置：在盒子里，还是在你围绕它做的工作中。这篇文章比较的是堆栈而不是插件与插件，然后为你提供一个记分卡和一个关于代理运行网站到 2027 年可能在哪里的谨慎看法。

MCP 改变了什么：你的网站获得了一个可以写入的代理

只读 MCP 是一个举止更得体的搜索框。代理获取文章、总结文章并发现空缺，如果它做错了，网站不会受到损害。没有任何东西会破裂。

写入权限是不同的。一旦服务器暴露了创建、更新、发布和删除工具，代理就成为了你网站的工作用户，拥有其令牌携带的每项权限。它可以在凌晨 3 点重写定价页面。它可以发布一份没人批准的草稿，也可以被它阅读过程中看到的文本推向任一错误。稍后会详细说明。

因此，CMS 的选择不再主要是关于编辑和模板。它变成了一个权限问题，四个子问题做了大部分艰苦的工作。

你能多精细地限制代理被允许做什么？
它能停留在草稿中，还是每次写入都会上线？
有审计日志吗，你能回滚吗？
人类能在公众看到之前看到结果吗？

这现在不是小众问题。英国 AISI 统计公开发布的 MCP 工具在一年内从约 5,000 个增加到 177,000 个，下载次数从 80,000 个增加到 1400 万次。这是很多需要信任或拒绝信任的服务器。如果你想要一个做出该决定的例程，我在审查 Claude Code 技能、插件和 MCP 服务器中写过，而在生产环境中运行 MCP 的更广泛情况在 MCP 服务器生产堆栈文章中。

WordPress，官方途径：Abilities API 和 MCP Adapter

Abilities API 在 WordPress 6.9 中推出。它为核心、主题和插件提供了一种标准方式来声明它们能做什么，附带输入模式和权限回调。MCP Adapter 位于那一层之上。它被描述为 WordPress 的官方 MCP 集成包，位于 WordPress GitHub 组织下，属于 AI Building Blocks for WordPress 倡议。它的工作很狭隘但很重要：将能力作为 MCP 工具、资源和提示来暴露。

README 文档的内容：

HTTP 和 STDIO 传输，加上一个 McpTransportInterface 用于自定义协议。客户端通过 WP-CLI 通过 STDIO 连接，或者将 HTTP 客户端指向 /wp-json/mcp/mcp-adapter-default-server。
一个它称之为粒度权限的特性：每个服务器的传输认证和每个能力的权限检查。
能力默认是私有的。将 meta.public（或 meta.mcp.public）设置为 true 会暴露一个能力。
默认服务器提供三个元工具：mcp-adapter/discover-abilities、mcp-adapter/get-ability-info 和 mcp-adapter/execute-ability。
通过 McpErrorHandlerInterface 和 McpObservabilityHandlerInterface 实现可插拔的错误处理和可观测性。

默认私有是正确的直觉。没有被标记为公开的能力无法被代理访问，无论提示有多聪明。现在看看该列表中缺少的内容：没有仅草稿代理角色，没有内置审批步骤，没有审计日志。可观测性钩子是构建这些的地方。它们不是一个完整的审计跟踪。

草稿控制存在于能力内部。必须有人来编写它们。第三方插件 MS WordPress Abilities 相当好地展示了这项工作的形态。它注册了 29 个能力（26 个自定义，加上三个选择进入 MCP 可见性的核心能力），并提供了两步分阶段更新，preview-post-update 然后 apply-post-update，而 patch-post-content 不需要分阶段。设计合理。但这仍然是作者的选择，而不是 WordPress 的选择。根据同一个 README，核心和官方 AI 插件仅开箱即用地提供了少数几个能力。

它也仍在演变。2026 年 3 月 18 日提出的一个问题指出，适配器 README 仍在讨论在合并到核心后需要 Abilities API（问题 150）。在 2026 年 6 月 24 日，一位贡献者在那里评论说，新的核心和站点能力应该在 AI 插件和 Abilities API 中，而不是在适配器上，并且许多适配器文档仍在教授注册任意能力和设置 mcp.public 的旧模型。然后，在 2026 年 2 月 5 日，一位 WordPress AI 维护者表示他不知道有任何实现 Abilities API 或 MCP 支持的插件目录（讨论 204）。管道是官方的。安全有用能力的目录仍然很少。

WordPress，插件路线：选择众多，安全记录薄弱

另一条 WordPress 路线是一个提供自己的 MCP 服务器的插件。出现在供应商比较页面上的名称包括 Easy MCP AI、WPVibe、Novamira、Royal MCP、miniOrange Secure MCP Server 和 AI Engine。我在这里将它们视为一个类别。没有排名。我也不会把它们的功能声明作为事实重复。一个警告很重要：流行的比较页面由列出自己的插件供应商运营，所以将其视为附带表格的营销内容。

这个类别提供的是速度。安装插件，将令牌粘贴到你的 AI 客户端，你就可以获得文章、媒体以及通常用户和设置的工具。它的代价是信任。你正在向第三方作者提供一个端点，它可以充当 WordPress 用户，在一个后面有完整管理区域的 PHP 站点上操作。

我在这里引用的唯一公开安全记录属于一个插件，AI Engine：

CVE-2025-11749。在版本 3.1.3 及更早版本中，启用了"无认证 URL"选项后，MCP 持有者令牌通过站点的公开 REST 路由泄露。未经身份验证的攻击者可以向 MCP 端点进行身份验证并创建管理员账户。在 3.1.4 中修复，并于 2025 年 11 月 5 日发布到 NVD（SentinelOne 的文章，将泄露定位在 /mcp/v1/ 端点，并表示尚未确认有已验证的公开漏洞代码）。
CVE-2026-8719。发布于 2026 年 5 月 17 日，评级为高（CVSS 8.8）。在版本 3.4.9 中，MCP OAuth 持有者令牌路径未检查管理员权限，因此持有有效令牌的订阅者级别用户可以访问管理员级别的 MCP 工具并成为管理员（GitHub 安全公告）。
更长的列表。WPScan 列出了许多，包括多站点上的 MCP 用户工具账户接管（在 3.6.1 中修复）和通过 CSRF 创建管理员账户（在 3.6.6 中修复）。

公平对待这能证明什么。这是一个插件。流行的插件吸引审查，这部分是为什么这个插件有记录的原因，而其他地方的空记录不是安全的证据。尽管如此，这个模式很重要。两个头条漏洞都是 MCP 门处的授权失败，正是代理获得权力的地方。记住这一点。

无头 CMS MCP 服务器：Sanity、Strapi、Contentful 和 Payload

无头平台围绕数据模型构建了 MCP 服务器。而不是围绕 PHP 管理。这个差异在文档中显现出来。

Sanity

Sanity 在 https://mcp.sanity.io 上运行一个托管服务器，使用 Streamable HTTP，默认为 OAuth，令牌认证为可选。代理可以运行 GROQ 查询，管理发布并修补文档，同时了解你的模式。设置是 npx sanity@latest mcp configure。较旧的本地 @sanity/mcp-server 包已弃用。这是当前的路线。

文档描述了草稿优先写入：create_documents 会创建草稿，除非你传递 releaseId，patch_documents 保存到草稿或发布版本，已发布内容永远不会直接修改。发布是一个单独的工具。对每个文档的修补作为单个事务应用。个人令牌共享你的角色并将你链接到修订历史中的更改，而在 Authorization 标头中设置的令牌在自己的角色和范围内运行。有两个注意事项。服务器还暴露了开发和项目管理（模式部署、数据集、CORS 源），所以要仔细界定令牌的范围。并且 create_release 不会安排任何内容，这必须在 Studio 或 HTTP Actions API 中进行。

Strapi

Strapi 的 MCP 服务器内置在其中，在您自己的实例内运行。它首次出现在 v5.47.0，在 v5.49.0 时正式上线（Strapi 博客，2026 年 9 月 3 日）。默认情况下它是关闭的：server.mcp.enabled 为 false。它使用管理 API 令牌进行身份验证，为每个内容类型公开查找、创建、更新、发布和取消发布工具。令牌永远无法超出其所有者的权限，停用所有者会撤销该令牌。它不创建内容类型或上传媒体；这些仍然通过 REST API 进行（Strapi）。

Contentful 和 Payload

Contentful 发布了一个官方开源 MCP 服务器（MIT 许可证，npm 包 @contentful/mcp-server），允许代理管理条目和资产、更新内容类型以及自动化标记和迁移等工作。它需要一个管理访问令牌和一个空间 ID（Contentful）。存在一个单独的社区服务器，指回官方服务器。Payload 通过官方插件而不是独立服务器添加 MCP。我对 Payload 的讨论就到这里为止。

如果您在更广泛的范围内权衡 Sanity 和 WordPress，请查阅 Sanity vs WordPress for enterprise，其中涵盖了非 MCP 方面。在决策的这一部分中，请从那里开始。

基于 Git 的 Jamstack：拉取请求是安全网

第三种模式根本没有 CMS 服务器。内容作为 Markdown、MDX 或类型化 JSON 存储在存储库中，网站使用 Astro 或 Next.js。编码代理编辑文件。它打开一个拉取请求，主机构建预览部署，人工在合并前审查差异。Vercel 和 Netlify 都支持基于 Git 的部署和预览部署，这是这种模式从主机所需的全部内容。

拉取请求循环并不罕见。Next.js 记录了如何支持 AI 编码代理，Microsoft Azure Static Web Apps 教程展示了标准接线：一个 GitHub Actions 工作流程，在拉取请求打开、同步、重新打开和关闭时触发，带有单独的工作来清除预览。这是普通的交付机制。这是其吸引力的一部分。

为什么它适合代理很简单。每次更改都是可审查的差异。在人合并之前，没有任何内容到达生产环境。回滚是一个 git 还原。公共网站是静态输出，因此没有管理员登录可供被盗的代理令牌到达。

不过成本是真实的。非技术编辑会遇到摩擦，因为 git 不是他们的工具。这里没有任何东西是具有安全记录的已记录 MCP 服务器；代理是具有存储库访问权限的编码代理，因此您的风险暴露是其 git 令牌的范围和其 shell 能接触到的任何东西。供应链卫生仍然适用。我在 2026 年的 Next.js、Astro 和 Nuxt 安全性中涵盖了这一点。

任何堆栈上的 MCP 风险，以及控制它们的措施

NSA 在 2026 年 6 月发布了关于 MCP 安全的网络安全信息表，Microsoft 撰写了 2026 年 MCP 安全的状态。抛开术语，四种风险不断出现。

继承权限。代理可以执行其 MCP 服务器凭据能做的任何事情。管理令牌意味着管理代理。
工具投毒。工具描述由模型读取，因此恶意或被破坏的服务器可以在其中隐藏指令。这就是为什么第三方服务器在安装前应该进行审查。
提示注入。代理读取的内容（评论、抓取的页面、粘贴到草稿中的支持工单）可能携带指令。代理可能会用自己的写访问权限执行这些指令。
权限过高的令牌。便利性促使人们交出一个广泛的令牌。不要这样做。

控制措施很平凡。它们能正常工作。给代理最小权限令牌，倾向于只读或仅草稿范围，在发布和删除前要求人工批准。保留你实际会阅读的审计日志。当任何人离职时轮换令牌。这些都不是特定于堆栈的，这正是重点。堆栈只是决定有多少工作已经为你完成。

代理就绪记分卡

这是一个地方的比较。评级来自文档化的功能和公开记录，上面已命名来源。没有人为了这个表格而通过测试套件运行这些堆栈。把它当作文档化的比较，而不是实验结果。

强表示文档默认涵盖它。部分表示有文档但不完整，或仅由简短记录支持。取决于设置表示堆栈不决定。你的配置决定。弱表示有文档化的问题。

堆栈	权限粒度	草稿与发布控制	审计跟踪和回滚	上线前预览	身份验证模型	公开安全记录
WordPress + 官方 MCP 适配器	强	取决于设置	部分	取决于设置	部分	部分
WordPress MCP 插件（作为一个整体）	取决于设置	取决于设置	取决于设置	取决于设置	取决于设置	弱（仅一个插件有文档记录）
Sanity	强	强	强	部分	强	部分
Strapi	强	强	取决于设置	取决于设置	强	部分
Contentful	部分	取决于设置	取决于设置	取决于设置	部分	部分
Payload	取决于设置	取决于设置	取决于设置	取决于设置	取决于设置	部分
基于 Git 的 Jamstack	强	强	强	强	取决于设置	部分

简要说明各个评级的原因。

WordPress + 适配器。权限很强，因为每个功能都有自己的检查，功能在标记为公开之前是私有的。草稿控制取决于你安装的功能，如分阶段更新示例所示。审计是部分的：可观察性接口存在，但本地审计日志不存在。身份验证是部分的，每服务器传输身份验证在高层级有文档记录。记录是部分的，因为该包很新，其文档明显处于迁移中。

WordPress 插件。在整个类别中没有统一性，所以大多数单元取决于插件。记录在文档化的地方是弱的：上面的 AI Engine 条目，仅限这些。这种区别很重要。

Sanity。角色范围令牌、默认草稿写入、发布和修订历史获得强评级。预览是部分的，因为发布是一个分阶段概念，但 MCP 服务器无法计划或发布版本。记录在时间长度意义上是部分的。不差。

Strapi。按内容类型的工具和所有者绑定令牌在权限和身份验证上很强。发布和取消发布是独立的工具，服务器保持关闭，直到你将其打开。审计和预览取决于你如何运行实例。自托管也意味着修补是你的工作。

Contentful。官方服务器需要管理令牌和空间 ID，这读起来像是广泛的访问权限，所以我对权限和身份验证的评级是部分。草稿处理、审计和预览取决于你如何配置空间和角色。重要的工作就在这种配置中。

Payload。存在一个官方插件。除此之外，我没有主要文档可用于评估，因此每一项都显示为"取决于设置"。这是我无法验证的空白。这不是判决。

基于 Git 的 Jamstack。四列中表现强劲，因为该模式本身就提供了这些：分支级存储库权限、作为发布门控的拉取请求、git 历史记录和恢复、预览部署。身份验证取决于编码代理及其 git 令牌。记录不完整，因为没有 CMS 管理界面可攻击。代理工具仍然存在与其他所有工具相同的 MCP 风险。

如何根据情况选择，今天

你有一个现有的 WordPress 资产

保持原样并严格执行。使用官方适配器，仅将需要的能力标记为公开，编写或选择在应用前暂存更改的能力。具有管理员功能令牌的广泛第三方插件是整个比较中风险最高的设置。如果你想首先从前端放松 WordPress 的限制，headless WordPress 开发是一条中间路线。

你正在开始新项目

如果代理将帮助运行它，请从 headless 或基于 Git 的方案开始。Sanity 或 Strapi 开箱即提供草稿和作用域令牌。Sanity 或 Strapi 在存储库中的 Astro 或 Next.js 为你提供差异和预览。这是新工作的强大默认值。

你的内容团队很大，或者不是技术人员

在可视界面中工作的编辑团队不会喜欢拉取请求。具有适当编辑工作室的 headless 更适合他们，前提是代理仅限于草稿。WordPress 的编辑器在这里仍然真正很好。这对它有利。

你有合规需求

询问审计日志位于何处以及谁拥有它。Git 历史记录是一个强有力的答案。Sanity 的修订历史记录是另一个答案。对于 WordPress，你需要自己构建日志记录。自托管选项（Strapi、WordPress）将数据保留在你的基础设施中，但将修补工作留给你，而托管服务器则将这一负担转移给供应商。

到 2027 年：为什么 Jamstack 可能是 AI 运行网站的更好选择

本部分是观点，不是发现，我对其持宽松态度。

Jamstack 为什么可能领先。内容是结构化和类型化的。每个代理更改都可以是人类审查的差异。预览部署显示上线前的结果。回滚是 git 恢复。公共网站没有管理界面供被盗的代理令牌访问。代理擅长编辑文件，不善于被信任，这个设置正是为这种组合而构建的。

WordPress 为什么可能不会失利。它拥有最大的安装基数和人才库。Abilities API 现已进入核心，其旁边有一个官方适配器。插件供应商迭代迅速。快速迭代解决了很多问题，即使它创建了上面的 CVE。

WordPress 需要什么。MCP 在核心中，能力默认映射到功能。仅限草稿的代理角色。原生审计日志。更好的 MCP 插件安全记录。这是一个简短的列表，其中没有什么是不可能的。

如果这个观点让你正在考虑迁移，离开 WordPress 指南是从哪里开始的。

实际情况：对于代理将帮助运行的新网站，从 Jamstack 或 headless 开始。对于现有的 WordPress 资产，使用具有最小特权能力的官方适配器，而不是广泛的第三方插件。在这里要保守。

WordPress MCP vs Headless CMS MCP：哪个更适合 AI 代理？