发布前检查
MCP Abilities – Check Runner：检查完成，不一定代表通过
没有错误，检查也可能不通过。Check Runner 将 AI 助手连接到 WordPress 官方 Plugin Check，并把警告也视为不通过的原因。根据结果判断发布前还需要修复哪些问题。
一条警告，也会阻止通过
假设某个候选版本没有报告错误，却有两条警告。检查已经结束，但 Check Runner 仍会将结果标为未通过。错误数和警告数必须同时为零。
工具会运行官方执行器提供的全部检查，包括实验性检查。缩小检查列表或类别范围的请求会被忽略。有哪些检查可用，取决于已安装的 Plugin Check 版本。
在 Plugin Check 提供相应信息时，每条发现会包含文件、行、列、说明和诊断代码。利用这些信息定位问题、修改代码，再检查更新后的插件。
黄色警告同样意味着停止。只有错误数和警告数都为零，检查才会通过。
任务编号是回执，不是通过证明
如需后台执行，请指定 async: true。WordPress 安排检查时，Check Runner 会返回任务编号。默认调用采用同步执行方式。
用 plugin-check/job-status 查询同一个任务。Pending 表示尚未开始，running 表示尚未结束。状态为 complete 的任务，可能包含通过的结果、导致不通过的问题，也可能包含执行错误。
后台执行依赖 WordPress cron 和服务器允许的 PHP 资源。收到任务编号，并不保证任务一定能启动或完成。遇到停滞或中断的任务，应先查明原因，再请求新任务。
回执对应一个任务。读完它保存的最终结果，再判断插件是否通过检查。
从已安装的候选版本到可用的检查结果
1. 指定准确的插件
将候选版本安装到合适的 WordPress 测试站点，并启用官方 Plugin Check。向助手提供插件的 slug 或主文件标识，并根据检查目的选择新插件模式或更新模式。
2. 运行完整检查
请求完整检查，必要时选择后台执行。保存任务编号，并查询任务状态。成功安排任务，不代表检查已经通过。
3. 同时查看总数和具体发现
先确认执行是否结束，再看通过状态、错误数和警告数。如果列表被截断，显示的发现就不完整，即使总数仍覆盖整个检查结果。
4. 修复、复查并测试功能
修复报告的问题后，对修改后的插件重新运行完整检查。还要测试实际功能和集成。Plugin Check 没有发现问题，不等于插件功能正确，也不保证 WordPress.org 会接受该插件。
返回列表有数量上限
默认响应最多显示 100 条发现。通过 max_results 可将上限提高到 500 条。错误排在警告之前，因此错误过多时，警告详情可能不会出现在显示的响应中。
剩余发现无法通过分页获取。如果 truncated 为 true，请使用 Plugin Check 官方界面查看进一步的详情。不要把此响应称为完整的问题列表。
两个操作，需要不同权限
plugin-check/run 用于启动检查，需要 WordPress 的插件激活权限。plugin-check/job-status 用于读取已保存的任务，需要站点选项管理权限。
执行后台任务时，应使用同时具备这两项权限的账户。Check Runner 不会修复源文件、安装候选版本或发布新版本。当前版本也没有取消或删除任务的操作。
准备 WordPress 连接
Check Runner 声明的最低要求为 WordPress 6.9 和 PHP 8.0。WordPress 6.9 已包含 Abilities API。请使用仍在维护、且站点支持的 PHP 版本。
必须安装并启用官方 Plugin Check 插件。通过 WordPress MCP Adapter 连接已完成身份验证的 MCP 客户端，并确认能发现所需操作。
根据 MCP 配置，可能需要 MCP Expose Abilities 之类的能力开放层，才能让客户端发现运行检查的操作。开始检查前，先验证连接。