WordPress 7.1 MCP Adapter 实战：AI 安全操作站点

WordPressMCPAbilities APIAI自动化WP-CLI

我维护着一个 600 多篇文章的内容站，每周重复最多的动作就是「翻出旧草稿、改 SEO 描述、补内链、重打标签」。我用了两周时间把官方 MCP Adapter 接到站点上，第一次可以让 Claude Code 和 Cursor 在对话里直接读写内容，再也不用为每个小需求写一次性 REST 脚本。这篇把我实际踩过的坑、能照抄的命令和权限收口的做法一次写清楚。

⏳ 太长不看版 (TL;DR)

结论（三句话）

WordPress 6.9 起内置 Abilities API，7.1 又补上了完整的执行生命周期过滤器；官方 MCP Adapter 把这些 ability 翻译成 MCP 工具，AI 客户端就能发现并调用它们。
安装只是一条 `wp plugin install`，真正难的是权限：默认服务器只暴露打了 `meta.mcp.public = true` 的 ability，务必用专用低权限用户配应用密码，先只读、后写入。
我在 WordPress 7.1.2 + MCP Adapter 0.6.1 上跑通了「列草稿 → 改描述 → 打标签」的只读增强流程，全程没有开放任何删除类 ability。

顺手的桌面装备（文末给出选择理由）

🖥 **4K USB-C 显示器**：Dell UltraSharp U2723QE 27" —— 一根 USB-C 同时供电、传屏、走网口，还带 KVM，适合一边看 AI 输出一边开终端，参考价 $429–529。

👉 在 Amazon 上查看 Dell U2723QE >>

💡 **显示器挂灯**：BenQ ScreenBar Halo 2 —— 三区背光加无线旋钮，夜间盯日志和 diff 更省眼，参考价 $179–199。

👉 在 Amazon 上查看 BenQ ScreenBar Halo 2 >>

透明声明：以上两个链接是 Amazon 联盟链接，你通过它们下单我会获得少量佣金，成交价格与你直接购买完全相同。作者与被推荐品牌无雇佣或代理关系。

为什么是 Abilities API，而不是再写一堆 REST 脚本

WordPress 6.9 引入了 Abilities API，把「站点能做什么」标准化成可发现、强类型、可执行的能力（ability）。每个 ability 注册时就带三样东西：唯一的 namespace/ability-name、类型化的输入输出 schema、以及一个 permission_callback。注册之后，同一个 ability 可以从 PHP、JavaScript 和 REST API 三个入口被调用。6.9 自带三个只读能力：core/get-site-info、core/get-user-info、core/get-environment-info。

这里要分清两条方向完全相反的链路：

WordPress 7.0（2026-05-20 发布）带来 WP AI Client 与 Connectors，解决的是**出口**：WordPress 去调用 Anthropic、Google、OpenAI 等模型。
MCP Adapter 解决的是**入口**：外部 AI 代理反过来调用 WordPress 的能力。

WordPress 7.1「Mary Lou」（2026-08-19 发布）把 Abilities API 从基础设施推到了工具箱，新增四个过滤器：wp_pre_execute_ability（短路整条执行流水线）、wp_ability_normalize_input（校验前改写输入）、wp_ability_permission_result（改写或覆盖权限判定）、wp_ability_execute_result（输出校验前改写结果），并引入 WP_Filter_Sentinel 用于区分「默认值未改动」与「用户显式传入」。这一层正是协议适配器、授权层和自动化系统需要挂载的地方。

还有一件事必须提醒：Automattic 早期的 Automattic/wordpress-mcp 仓库已于 2026 年 1 月 19 日归档，不再维护，最后一个版本停在 2025 年 7 月的 v0.2.5。2026 年再动手，直接上官方 WordPress/mcp-adapter。

前置条件与版本确认

组件	最低要求	我实际使用的版本与说明
WordPress	6.9（Abilities API 落地版本）	7.1.2（2026-09-22 安全版，修复未认证的页面模板路径穿越可致条件 RCE，编号 CVE-2026-87902 / GHSA-7hp8-65ch-5whp；上一个是 7.1.1，含 11 项安全修复）
PHP	7.4	8.2 以上更稳（MCP 依赖 ext-json）
MCP Adapter	v0.5.0 起	0.6.1（2026-08-13；0.6.0 于 08-12 修协议兼容、resource 元数据与会话可靠性）
WP-CLI	2.x	2.12.0（当前稳定版）
Node.js	18 以上	HTTP 传输需要，用于 `@automattic/mcp-wordpress-remote`
认证方式	应用密码	需要 HTTPS；专用低权限用户

三条确认命令，先跑一遍再往下：

wp core version
wp --info | head -3
php -m | grep -i json

MCP Adapter 有一个容易踩的坑：它**没有**上架 WordPress.org 插件目录（用 slug mcp-adapter 查询插件 API 会返回「Plugin not found」，即使插件自带的 readme 让你在后台搜索）。所以插件头部里写 Requires Plugins: mcp-adapter 这种依赖声明在 WordPress.org 上不会生效，只能自己保证加载顺序。

Step 1：用一条 WP-CLI 命令装好适配器

wp plugin install https://github.com/WordPress/mcp-adapter/releases/latest/download/mcp-adapter.zip --activate
wp plugin list --name=mcp-adapter

激活后会自动注册一个名为 mcp-adapter-default-server 的默认服务器，HTTP 端点是：

https://example.com/wp-json/mcp/mcp-adapter-default-server

同时暴露三个 meta 工具，给 AI 代理一条分层的访问路径：mcp-adapter-discover-abilities（列出有哪些 ability）、mcp-adapter-get-ability-info（读取某个 ability 的 schema）、mcp-adapter-execute-ability（执行）。

Step 2：把核心 ability 开放给默认服务器

核心那三个 ability 默认不会出现在默认服务器上，必须显式标记 meta.mcp.public = true。用过滤器统一处理，省得改核心文件。把下面这段存成 wp-content/plugins/tp-enable-core-abilities/tp-enable-core-abilities.php，并在**文件开头补上标准的 PHP 起始标签**（为避免代码块里的尖括号被页面误解析，这里只展示函数部分）：

add_filter( 'wp_register_ability_args', 'tp_enable_core_abilities_mcp', 10, 2 );

function tp_enable_core_abilities_mcp( array $args, string $ability_name ) {
    $core = array( 'core/get-site-info', 'core/get-user-info', 'core/get-environment-info' );
    if ( in_array( $ability_name, $core, true ) ) {
        $args['meta']['mcp']['public'] = true;
    }
    return $args;
}

然后激活并验证：

wp plugin activate tp-enable-core-abilities
curl -s -X POST -u 'mcp-bot:xxxx xxxx xxxx xxxx' \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"tools/list","id":1}' \
  https://example.com/wp-json/mcp/mcp-adapter-default-server

返回的列表里应该能看到那三个核心 ability 已经变成工具。如果你是自己写自定义服务器并通过 mcp_adapter_init 显式暴露，则不需要这个 public 标记。

Step 3：建一个专用只读用户与应用密码

不要用管理员账号连 AI 客户端。MCP 客户端在 WordPress 眼里就是「一个已登录用户」，它能把该用户能做的事全做一遍。

wp user create mcp-bot mcp-bot@example.com --role=author --user_pass="$(openssl rand -base64 24)"
wp user get mcp-bot --field=roles

接着到后台「用户 → 个人资料 → 应用程序密码」生成一个应用密码。两个细节：命名时写上客户端名（比如 claude-code-laptop），以后可以只吊销这一条；密码只显示一次，WordPress 只存哈希。先用 REST 校验一次：

curl -s -u 'mcp-bot:xxxx xxxx xxxx xxxx' https://example.com/wp-json/wp/v2/users/me | head -c 300

能返回当前用户信息，说明认证链路通了。返回 401 就直接跳到下面的踩坑录。

Step 4：把 Claude Code 和 Cursor 连上去

HTTP 传输最通用，也最省事。Claude Code 可以在项目目录建 .mcp.json（放主目录的 .claude.json 则全局可用）：

{
  "mcpServers": {
    "techpassive-wp": {
      "command": "npx",
      "args": ["-y", "@automattic/mcp-wordpress-remote@latest"],
      "env": {
        "WP_API_URL": "https://example.com/wp-json/mcp/mcp-adapter-default-server",
        "WP_API_USERNAME": "mcp-bot",
        "WP_API_PASSWORD": "xxxx xxxx xxxx xxxx"
      }
    }
  }
}

Cursor 的路径是 Settings → Tools and MCP → Add Custom MCP，写到 mcp.json，结构完全一样。VS Code 也是同一份结构，唯一区别是最外层键要用 servers 而不是 mcpServers。Claude Desktop 走 Settings → Developer → Edit config，改完必须**完全退出再启动**，因为它在启动时只读一次配置文件。

如果 WordPress 站点在本机，可以改用 STDIO 传输，连应用密码和公网端点都不需要：

{
  "mcpServers": {
    "techpassive-wp": {
      "command": "wp",
      "args": ["--path=/var/www/html", "mcp-adapter", "serve", "--server=mcp-adapter-default-server", "--user=mcp-bot"]
    }
  }
}

--user 决定了代理被允许做什么，这是 STDIO 模式下唯一的权限边界，别顺手写 admin。

权限收口：三类 ability 不要对外开放

**删除与回收站类**：任何能删文章、删媒体、清空回收站的 ability，不要暴露在公网端点上。
**用户与角色类**：能改角色、改密码、发应用密码的能力，等于把后台钥匙交出去。
**插件、主题与文件写入类**：能装插件、改主题文件的能力，风险等级等同于服务器 shell。

写 permission_callback 时用最小能力集（读用 read，改文章用 edit_posts，站点配置用 manage_options），不要图省事写 __return_true。生产环境用专用用户、走 HTTPS、优先只读，并把 MCP 相关的调用记进日志。破坏性操作一定要留人工确认这一步，别做成无人值守的自动飞行员。

回退：三秒回到原状

任何权限开放都要留退路，这次只需要两条命令：

wp plugin deactivate tp-enable-core-abilities   # 核心 ability 立即从默认服务器消失
wp plugin deactivate mcp-adapter                # 整个 MCP 入口关闭

再彻底一点，到后台「用户 → 个人资料 → 应用程序密码」把那条 claude-code-laptop 吊销，凭据立刻失效，不需要重启任何服务。这套设计的好处是：AI 侧感知不到「删掉了什么」，你只是关上了一扇门。

💣 踩坑录：5 个真实报错与修法

报错一：401 Unauthorized，但密码明明是对的

**现象**：curl -u 返回 401，MCP 客户端 tools/list 直接空结果。

**原因**：Apache 或 FastCGI 在请求到达 WordPress 之前就把 Authorization 请求头吃掉了，这是最常见的「认证失败但不是认证问题」。

**解决**：在站点根目录 .htaccess 里补上：

RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [E=HTTP_AUTHORIZATION:%1]

另外两个高频小坑：应用密码里的空格是正常的，别手贱删掉；用户名必须是生成这条密码的那个账号。

报错二：tools/list 只返回三个 meta 工具，核心 ability 一个都不见

现象：连接成功，但 AI 客户端报告「只有 3 个工具」。

**原因**：核心 ability 默认不通过默认服务器暴露；或者你升级了 0.6.x 之后，meta.public 与 meta.mcp.public 的语义有变化。

**解决**：用 Step 2 的过滤器把 meta.mcp.public 打开，然后确认客户端里查到的 ability 名字带正确前缀（core/）。自定义服务器模式下显式暴露即可，不需要这个标记。

报错三：个人资料页里根本没有「应用程序密码」这一栏

现象：照着教程找，但那块界面不存在。

原因：应用密码只在 WordPress 检测到 HTTPS 时才对 HTTP 请求暴露；本地纯 http 环境、或安全插件主动禁用了该功能，都会让这一栏消失。

解决：给站点配上受信任证书并全站走 HTTPS，不要绕过这个检查（凭据会随每次请求发送）。本地开发直接用 STDIO 传输，压根不需要应用密码。

报错四：客户端报 CERT_HAS_EXPIRED 或 fetch failed

现象：Claude Desktop 里服务器一直是灰的，日志报 TLS 证书错误。

**原因**：HTTP 传输用的 mcp-remote 会校验 TLS 证书，自签名或过期证书直接失败。

**解决**：换受信任证书（Let's Encrypt 即可）；本地站点用纯 http；绝对不要在生产环境使用 NODE_TLS_REJECT_UNAUTHORIZED=0 这类关闭校验的做法。

报错五：激活 0.6.0 的发布包直接白屏

现象：用 0.6.0 的 release ZIP 激活后站点报致命错误。

**原因**：0.6.0 的 ZIP 里 autoloader 类映射指向了压缩包并未包含的文件，任何在普通网页请求里检查 class_exists('WP_CLI') 的插件都可能命中未捕获的致命错误。从源码构建或用 Composer 安装的站点不受影响。

解决：直接换 0.6.1（2026-08-13 发布，只修复了发布包，没有 API、钩子或协议层面变化）。这也是我建议直接指定 0.6.1 而不是 0.6.0 的原因。

长文工作流的桌面配置（含联盟链接）

把 AI 拉进内容工作流之后，我发现自己盯屏幕的时间反而更长：左边放 diff 和日志，右边放编辑器，中间还要开着客户端。两件装备对我帮助最大，也正好是 TL;DR 里那两款。

Dell UltraSharp U2723QE（27 英寸 4K USB-C Hub 显示器）：一根 USB-C 就能给笔记本供电、传 4K 画面、同时走 RJ45 网口，还内置 KVM，可以在两台机器之间共用一套键鼠。看长文和 diff 时 4K 的纵向空间是实打实的效率。参考价 $429–529，价格波动较大，请以产品页为准。缺点是自带音箱基本可以忽略，USB-C 供电功率对高性能游戏本不够。

BenQ ScreenBar Halo 2（显示器挂灯）：三区背光加无线旋钮，晚上对着终端和 diff 时，把环境光补起来比调高屏幕亮度更护眼。参考价 $179–199。要注意的是自动调光模式下色温会被锁在 4000K，偏冷的读者会不太喜欢；老显示器上那个 5V/1A 的 USB 口也可能带不动，需要外接 5V/3A 供电。

再次说明，上面两个链接都是 Amazon 联盟链接，下单价格与你无关，但能支持我继续更新这个系列。