1. 结论：Cloudflare 已经走到门口，但 ChatGPT 这边还看不到门把手
安装 Cloudflare Plugin，再打开 Developer mode，看起来下一步就该能从 ChatGPT 查看 DNS 或 Analytics。实际却只看到 Agents SDK、Workers、Web Performance 等 Skills，聊天里也无法真正调用 @Cloudflare App。快递确实到了，只不过盒子里不是连接线，而是说明书。
这并不代表 Cloudflare 不支持 MCP。Cloudflare 已经运行官方 Remote MCP，并支持通过 OAuth 连接账号。真正的瓶颈更可能在 ChatGPT 侧：当前计划、角色、工作区、模型或 UI 尚未暴露创建/调用实际 App 连接的入口。
2. 实际发生了什么：“安装 Plugin”不等于“连接外部账号”
2026 年的 Plugin 是一个更宽泛的包装。一个 Plugin 可以包含 Skills、Apps 和 App templates。真正把 ChatGPT 接到外部数据或操作上的，是 App。
这次 Cloudflare 页面里能看到 Skills，却看不到 Connect 或实际 App。因此会出现一种看似离谱但合理的状态：Cloudflare Plugin 已启用，但 ChatGPT 依然无法读取账号内的 DNS 或 Analytics。就像拿回一张写着“支持 Wi‑Fi”的产品手册，然后问为什么路由器还没自动配对。手册没坏，路由器也没坏，只是配对界面还没出现。
3. 一次说清 Plugin、Skill、App、MCP
可以把它们理解为：Plugin 是商店/包装，Skill 是说明书和专业知识，App 是真实接口，MCP 是 AI 与外部工具之间的通用连接标准。
- Plugin：用于在 ChatGPT/Codex 中发现并启用工作流能力的包装。
- Skill：教 AI 如何理解和使用某个服务的指南、最佳实践和领域知识。
- App：真正连接外部数据和操作的集成。
- MCP：标准化连接 AI 客户端与外部工具的协议。
四者可能挂在同一个 Cloudflare 名称下，于是特别容易混淆。“懂 Cloudflare 的 Skill”和“连接我的 Cloudflare 账号的 App/MCP”不是一回事。
4. 2026 年 7 月 9 日的 Plugin Directory 迁移让命名更绕
OpenAI 表示，自 2026 年 7 月 9 日起，应用发现入口从 App Directory 迁移到 Plugin Directory。Plugin 成为 ChatGPT 和 Codex 中寻找工作流能力的主要入口，但 App 本身并没有消失。App 仍是连接外部数据/操作的实体，Plugin 则可以打包 Apps、Skills 和模板。
OpenAI 还明确说明：发布一个自定义 MCP App，并不会自动发布一个独立 Plugin。反过来在实践中也很重要：安装 Plugin 并不保证里面一定有可连接账号的 App。Logo 是 Cloudflare，名字也是 Cloudflare，描述里还有 official MCP，打开之后却是 Skills。看起来像网口，实际上是网口说明书。
5. Cloudflare 侧已经准备得很充分：官方 MCP 覆盖 2,500 多个 API endpoint
Cloudflare 运营官方 Remote MCP servers。Cloudflare API MCP server 通过 search() 和 execute() 两个工具覆盖整个 Cloudflare API 的 2,500 多个 endpoint，包括 DNS、Workers、R2、Zero Trust 等。
2026 年 7 月 28 日，Cloudflare 更新 MCP servers 以支持 MCP 2026-07-28 规范，并建议新连接使用 /mcp 的 Streamable HTTP endpoint。OAuth 也是官方支持的连接方式。Cloudflare 基本已经把门打开并写上“AI 客户端请进”。剩下的问题是 ChatGPT 的电梯是否对当前账号停这一层。
6. OpenAI 当前官方文档看起来也有一点“两种声音”
Developer mode/MCP 文档前部主要在 Business 和 Enterprise/Edu 的语境下介绍 Apps、full MCP 和 developer mode；但同一文档 FAQ 又明确写着，Pro 用户可以在 developer mode 中连接具备 read/fetch 权限的 MCP，而 write/modify 的 full MCP 仍属于 Business 和 Enterprise/Edu。
所以文字上看，Pro 的读取型 MCP 是存在的；现实 UI 中却可能没有 Apps 或 Create。OpenAI 也说明，App 可用性取决于计划、地区、工作区、角色、模型和界面。因此既不能断定“你设置错了”，也不能断定“所有 Pro 账号现在都应该有”。文档和 UI 在同一列车上，但似乎坐在不同车厢。
7. “感觉快来了”是合理推测，但没有到站时间表
乐观的理由确实存在：FAQ 已明确 Pro read/fetch MCP；Plugin Directory 的迁移发生在 2026 年 7 月；Cloudflare 也在 7 月底升级了 MCP；有些环境已经能看到 Developer mode。零件已经相当齐全。
因此它更像是 UI 暴露/分阶段发布问题，而不是遥远的未来概念。但这不等于可以预测“下周就来”。Beta rollout 没有列车时刻表。站台电子屏已经装好了，时间还是 --:--。快点。
8. 真连上之后会怎样：网站运维从“巡礼后台”变成“问系统”
按照 Cloudflare API MCP 的覆盖范围，连接后可以用对话检查 DNS 记录、Workers 配置、错误是否上升、Zone 结构等。再结合 Analytics/Observability 类 MCP，流量和日志也能进入 AI 工作流。
更大的价值是把流程串起来：GitHub 变更 → 部署结果 → Cloudflare 错误 → 公网站点 HTTP 状态。人不必打开仓库、工厂、物流中心和门店四套后台，只需要问“今天哪里不对？”让 AI 去巡检。网站运维从十四个标签页的祭祀仪式变成给厂长打电话。
9. 读取和写入是两个世界：OAuth 和权限不能随便给
按 OpenAI 当前说明，Pro custom MCP 主要是 read/fetch，full write/modify 面向 Business/Enterprise/Edu。Cloudflare MCP 本身具备执行更改的能力，但最终能不能写，要看 ChatGPT 计划、App 配置、权限和确认流程。
不要把 API Token 直接贴进聊天。优先使用最小权限 OAuth；CI/CD 场景则把最小权限 Token 放进 Secrets。在说“全部交给 AI”之前，先决定 AI 可以读什么、可以改什么。现实公司也不会在新员工第一天给他“删除所有 DNS 记录”的权限。
10. 现在该做什么：不要寻找不存在的按钮，等它出现时 5 分钟接好
如果当前 UI 没有 Apps/Create，研究三小时“如何点击不存在的按钮”也不会让按钮长出来。Cloudflare 控制台也不能把 ChatGPT App 强行塞进一个没有对应入口的界面。保持 Developer mode 开启，等待 App/custom MCP 入口出现，是最直接的做法。
如果运维不能等，可以先通过 GitHub/Codex、CI 或其他 MCP 客户端连接 Cloudflare API/MCP。等 ChatGPT UI 开放后，再把已有流程迁进对话。工厂现在就能运转；缺的是老板办公室到厂长的直线电话。
结论很简单：Cloudflare 已支持 MCP，ChatGPT 也在推进 MCP，Cloudflare Plugin 甚至可能已经可见；但“有 Plugin”并不等于“当前 UI 已经把我的 Cloudflare 账号作为可调用 App 连上”。 说明书到了，接口标准也有了，只差墙上的插孔。快点。
