FFFire小火作为常年泡在 Cloudflare Workers 生态里的开发者，我这两年最大的感受就是：Cloudflare 正在把自己整个平台变成 AI 的"工具柜"。以前你想操作 Workers、KV、D1，得一个个去翻 API 文档、拼请求、管鉴权；现在靠着 Cloudflare MCP，你直接跟 AI 说人话，它就能帮你把活干了。MCP 就是 Model Context Protocol，一套让大模型安全调用外部工具和数据源的标准协议。这篇文章是我把 Cloudflare MCP 从安装、配置到真实业务场景里跑通的完整记录，包括踩过的坑和一些只有实际动手才会知道的细节，给想入坑 MCP 的朋友一份能直接照着抄的参考。
MCP 真正火起来也就是近一年的事。它把"AI 只能聊天"这个天花板捅破了——通过 MCP server，AI 能读数据库、操作浏览器、调用 API、管理云资源，而且只需要一套统一的协议。Cloudflare 官方一口气放出了好几个 MCP server，等于把整套开发者平台的能力都开放给了 AI 工具。今天我就围绕 Cloudflare MCP 这个东西，把它的生态、安装方法和实战场景一次说清楚。
1. 先搞清楚 MCP 和 Cloudflare MCP 是什么
1.1 MCP 协议解决了什么问题
要理解 Cloudflare MCP 的价值，得先理解 MCP 本身是干嘛的。打个比方：如果说大模型是电脑的 CPU，那 MCP 就是电脑的 USB 接口。没有 USB 之前，你想给电脑接个键盘、鼠标、打印机，每个设备都得搞一套专属的连接方案，厂商之间还不互通。有了 USB，所有设备统一接口，插上就能用。MCP 做的就是这件事——它把"AI 需要调用的各种工具和数据"标准化了。
具体到技术架构上，MCP 是客户端-服务器模式。AI 应用（比如 Claude Desktop、Cursor、Trae、Codex 这类工具）是 MCP 客户端，它们负责跟用户交互、理解意图；MCP server 是能力的提供方，暴露出一系列"工具"（tools）供 AI 调用。工具本质上就是一个个函数，有名字、有参数描述、有返回结果。AI 在对话过程中判断"用户想要的效果需要调用哪个工具"，然后主动去调用，再把结果整合成自然语言回复。
这个设计最大的好处是解耦。AI 应用不用关心每个服务商的具体 API 怎么调，服务商也不用为每个 AI 工具单独做适配。你只要写一个 MCP server，所有支持 MCP 协议的客户端都能用。这也是为什么现在"MCP 服务搭建"成了热词——大家都在抢着把自己的产品接入这个生态。
1.2 Cloudflare 在 MCP 生态里的位置
Cloudflare 接入 MCP 的逻辑非常清晰：它的核心资产是开发者平台——Workers（边缘计算）、KV（键值存储）、D1（关系型数据库）、R2（对象存储）、Pages（静态托管）等等。过去这些能力都靠 REST API 暴露，开发者要自己写脚本去管理。现在 Cloudflare 把官方 MCP server 做出来了，等于给 AI 配了一把能操作整个平台的钥匙。
举个例子，以前我想部署一个简单的 Worker，流程是这样的：本地写代码、登录 Dashboard、创建 Worker、粘贴代码、配置绑定、保存部署，至少五六步。现在我可以直接对 Cursor 或者 Claude 说"帮我在 Workers 上部署一个计数器，用 KV 存储访问次数，路由绑到 /count 这个路径"，AI 会自动调用 Workers MCP server 里对应的工具，完成脚本创建、KV 命名空间创建、绑定配置、部署发布一整套操作。
这就是 Cloudflare MCP 的核心价值：把"云资源运维"从手动操作变成了自然语言对话。当然，这不意味着你完全不用懂原理——恰恰相反，懂原理才能用好它，这也是我写这篇文章的初衷。
1.3 适合哪些人用
如果你符合下面任何一条，Cloudflare MCP 都值得花时间折腾：
- 经常在 Cloudflare Workers 上做小项目、写边缘函数，想省去来回切换 Dashboard 和命令行的时间；
- 在做 AI 应用开发，想把 Cloudflare 的存储、计算能力作为 AI 的"工具"开放给模型调用；
- 公司内部有现成的 REST API，想快速让 AI 助手能调用这些接口，而不想为每个接口手写工具封装；
- 对 MCP 协议本身感兴趣，想找一个官方维护、文档齐全的参考实现来学习怎么搭建 MCP 服务。
如果你是纯前端、完全没碰过 Cloudflare 或云服务，那建议先去把 Workers 的免费套餐和入门文档过一遍，否则后面配置 API Token 和权限的时候会有点懵。MCP server 本身不复杂，但它操作的对象是云资源，你需要有最基础的账户和资源概念。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Cloudflare 官方 MCP Server 全家桶
Cloudflare 目前放出的 MCP server 不是只有一个，而是一整套。我实际用下来，感觉官方是分两条线在推：一条是"管理 Cloudflare 平台资源"，另一条是"把 Cloudflare 的能力变成通用 AI 工具"。下面逐个拆解。
2.1 Workers MCP Server：平台管理主力
这个是最核心的 MCP server，包名是 @cloudflare/mcp-server-workers，它面向的是 Workers 平台上所有资源的操作。我用下来感觉它暴露的工具覆盖了日常运维的大部分场景：
- Worker 脚本管理：列出所有脚本、查看脚本内容、部署新脚本、删除脚本；
- 资源绑定配置：给 Worker 添加或修改 KV namespace、D1 数据库、R2 bucket 等 binding；
- KV 操作：创建 KV namespace、列出所有 namespace；
- D1 操作：创建 D1 数据库、查看数据库列表；
- R2 操作：创建 R2 bucket、查看 bucket 列表。
它还有一个很聪明的设计：建了一个叫"资源列表"的能力，AI 在和用户对话时可以先通过这个工具把当前账号下有哪些 Worker、哪些存储资源拉一遍，再根据上下文决定怎么操作。这就像你请了个运维，他上来先把你服务器上的东西盘点了一遍，再听你安排活。
鉴权方式用的是 Cloudflare API Token，配合账号 ID 一起用。Token 的权限范围完全由你自己控制，可以做到只给 Workers 写的权限，不给其他资源权限，这在多账号场景下特别有用。
2.2 Browser Rendering MCP Server：把浏览器变成 AI 的眼睛和手
第二个是 @cloudflare/mcp-server-browser-rendering，它封装的是基于 Puppeteer 的浏览器自动化能力。工具包括打开网页、页面截图、生成 PDF、执行页面内的 JavaScript 等。
这个 server 有意思的地方在于，它不是一个"云端服务"，而是运行在你自己机器上的本地浏览器。AI 调用它的时候，你会看到浏览器窗口真的自己打开了，一个页面一个页面地跳转、截图。这种"眼见为实"的体验比纯 API 调用直观很多，调试的时候也方便——你能直接看到 AI 正在干什么。
它和 Playwright MCP、Chrome MCP 这些同类工具定位一样，但因为是 Cloudflare 官方维护的，跟其他 Cloudflare 服务的配合更顺。比如你做一个网页内容抓取的场景，可以用它打开页面、把渲染后的 HTML 抓下来，然后存到 R2 里去。这套链路里所有环节都是 Cloudflare 自家的东西，出问题好排查。
2.3 OpenAPI MCP Server：把 REST API 一键变成 AI 工具
第三个是 OpenAPI MCP Server，包名是 @cloudflare/openapi-mcp-server。它解决的问题非常实际：很多团队有现成的 REST API，API 文档用 OpenAPI 规范（以前叫 Swagger）写的，现在想让 AI 能直接调用这些接口，怎么办？
常规做法是手写一个 MCP server，把每个接口封装成一个工具，费时费力。用这个 OpenAPI MCP server，你只需要把 OpenAPI 规范的 JSON/YAML 文件喂给它，它会自动生成一个 MCP server，把规范里的每个接口变成对应的工具，并且支持配置 API Key、Bearer Token、基础 URL 这些鉴权信息。
我打个比方：OpenAPI 规范就像是接口的"使用说明书"，这个 MCP server 是"阅片机"——你说明书丢进去，它自动把里面的每个接口变成 AI 能看懂、能调用的工具卡片。对于企业内部有几十上百个接口的系统，这个工具能省下好几天的开发量。
2.4 Remote MCP：把本地 MCP server 搬到云端
最后一个是 remote-mcp，它不是 MCP server 本身，而是一个"远程化"工具。它能把运行在你本地的 MCP server 通过 Cloudflare Worker 暴露成一个远程 URL，这样你在任何地方、任何 MCP 客户端里都能访问到这个本地服务，而不需要内网穿透或者公网服务器。
原理上是借助 Cloudflare 的边缘网络和 Tunnel 能力做转发。比如你在公司内网跑了一个连内部数据库的 MCP server，用 remote-mcp 包装一下，回到家之后你依然可以让家里的 AI 客户端调用它。这在多智能体协作、远程团队共享 MCP 服务这些场景里非常实用——多个智能体可以连同一个远程 MCP 端点，共享同一套工具能力。
这四样东西的定位差异，我整理成了一张表：
| MCP Server | 作用对象 | 典型场景 | 运行位置 |
|---|---|---|---|
| Workers MCP Server | Cloudflare 平台资源 | 自然语言管理 Worker、KV、D1、R2 | 本地命令行 |
| Browser Rendering MCP | 本地浏览器 | 网页抓取、截图、自动化操作 | 本地浏览器 |
| OpenAPI MCP Server | 任意 REST API | 把 OpenAPI 文档转成 AI 可调用的工具 | 本地或容器 |
| remote-mcp | 任意本地 MCP server | 把本地 MCP 服务远程共享出去 | 本地 + Cloudflare 边缘 |
3. 手把手接入：把 Cloudflare MCP 跑起来
理论说得再多，不如亲手跑一遍。这一节我按实际操作的顺序，把接入 Cloudflare MCP 的完整步骤写出来。我默认你用的是 Claude Code 或 Cursor 这类支持 MCP 的客户端，环境是 macOS 或 Linux，Windows 的话在 WSL2 里操作是一样的。
3.1 准备工作：账号、Node 环境和 API Token
第一步，确认你有 Cloudflare 账号。没账号先去注册，Workers 有免费额度，个人折腾完全够用。登录后进 Dashboard，在右侧找到"我的个人资料"或者直接在 Workers 页面里，进入 API Tokens 的创建页面。
第二步，创建 API Token。这里有个值得注意的细节：Cloudflare 的 API Token 有两种创建方式，一种是直接点"创建令牌"，选预设模板；另一种是"创建自定义令牌"，自己勾选权限。我建议用自定义令牌，把权限范围限制到最小。比如你只是想管理 Workers，那就只勾选"Workers Scripts"的编辑权限，再加"Account Settings"的读取权限，资源范围限定到你的账号即可。Token 的权限越小，安全风险越低，这个习惯值得养成。
第三步，确认 Node.js 环境。Cloudflare 的 MCP server 都是通过 npx 运行的，Node.js 版本建议 18 以上。命令行里跑一下 node -v 确认版本，太老的话先升级。
3.2 用 Claude Code 接入 Workers MCP Server
Claude Code 是 Anthropic 推出的命令行 AI 编程工具，它对 MCP 的支持比较早也比较好。安装 MCP server 用的是 claude mcp add 命令，格式如下：
bash复制claude mcp add workers -- npx @cloudflare/mcp-server-workers
执行完之后，把环境变量配上。你可以在系统的 shell 配置文件（~/.zshrc 或 ~/.bashrc）里加上这两行：
bash复制export CLOUDFLARE_API_TOKEN="你的_API_Token"
export CLOUDFLARE_ACCOUNT_ID="你的_账号_ID"
账号 ID 在 Dashboard 的 URL 里可以看到，或者在 Workers 页面右侧的"账户 ID"一栏直接复制。配好之后，开一个新的 Claude Code 会话，让模型"列出当前账号下的 Workers"，如果它能正确返回列表，说明 MCP server 已经跑通了。
我用下来这个流程整体很顺，唯一要注意的是：环境变量改完之后，需要重启终端或者用 source 重新加载，否则 Claude Code 起来的时候读不到这些变量，MCP server 会因为缺少鉴权信息直接报错。
3.3 在 Cursor 里配置 MCP Server
Cursor 的配置路径不太一样，它是在图形界面里做的。步骤如下：
- 打开 Cursor，进入设置（Settings），找到 MCP 相关选项。不同版本菜单位置略有差异，新版一般在左下角头像菜单里，或者在设置页面搜 "MCP"。
- 添加一个全局 MCP Server，命令填
npx @cloudflare/mcp-server-workers。 - 环境变量这里要注意：Cursor 的 MCP 配置界面没有直接填环境变量的地方，你需要把 Token 和账号 ID 写进命令行里。有两种做法，一种是写一个启动脚本（比如
cf-mcp.sh），在脚本里 export 环境变量再执行 npx；另一种是直接用env CLOUDFLARE_API_TOKEN=xxx CLOUDFLARE_ACCOUNT_ID=xxx npx @cloudflare/mcp-server-workers这样的完整命令。 - 保存后，MCP server 会自动启动，界面里会显示工具列表和连接状态。如果状态是红色或者显示错误，点开看日志，大部分问题出在环境变量没有正确传递。
我个人的建议是：如果你主力用的是 Cursor，推荐把 MCP server 的启动命令封装成一个脚本文件，这样可读性好，后续改 Token 也方便，不用在设置界面的小输入框里塞一长串命令。
3.4 接入 Browser Rendering MCP
浏览器渲染这个 server 的安装和 Workers MCP 类似，也是通过 npx 跑：
bash复制claude mcp add browser -- npx @cloudflare/mcp-server-browser-rendering
它不需要 API Token，因为它操作的是你本地浏览器，不涉及 Cloudflare 账号资源。首次调用某个浏览器工具时，它会自动启动一个 Puppeteer 管理的浏览器实例，后续操作都在这个实例里进行。
我遇到过一个问题：某些 Linux 服务器环境缺少浏览器运行依赖，启动会报错。解决办法是安装 Puppeteer 需要的系统库，比如 libnss3、libatk 这些。如果你是在自己电脑上跑，一般不会有这个问题；但如果是在 Docker 容器或者 CI 环境里，就要提前把依赖装好。
3.5 连接 OpenAPI MCP Server
OpenAPI MCP Server 的用法稍微不一样。它不是简单地 npx 一个命令，而是先要告诉它你的 OpenAPI 规范在哪里、鉴权方式是什么。基本命令格式是：
bash复制npx @cloudflare/openapi-mcp-server --spec ./openapi.json --base-url https://api.example.com --api-key YOUR_KEY
其中 --spec 指向你的 OpenAPI 文档路径，--base-url 是接口的基础地址，--api-key 是调用接口时带的密钥。启动后，它会读取规范文件，为里面的每个 API 路径生成一个 MCP 工具，然后在 MCP 客户端里看到的就是一长串工具列表。
如果接口很多（几十个甚至上百个），工具列表会非常长。这时候建议在客户端里做好分组管理，或者只在需要的时候才连接这个 server，用完就断开，避免每次都加载一大堆工具，影响 AI 的上下文效率。
4. 实战：三个值得一试的 Cloudflare MCP 场景
工具装好了，接下来看实际能拿它干什么。我挑了三个自己试过、也确实在用的场景，每个都写清楚了链路和效果。
4.1 用自然语言部署一个带 KV 存储的 Worker
第一个场景是我最常用的：让 AI 帮我创建和部署 Worker。我给它的话是："创建一个 Worker，路径 /count，用 KV 存储做计数器，每次访问返回当前次数并加一。"
接下来发生的事情很有意思：AI 先调用资源列表工具，看看我账号下有没有合适的 KV namespace，发现没有之后，它会主动调用创建 KV namespace 的工具建一个，然后编写 Worker 代码，再调用部署工具把脚本推上去，最后把 route 配置好。整个过程它还会在对话里实时告诉你每一步在做什么。
这个场景的体验价值在于：过去这个流程至少要打开两三个页面、复制粘贴好几次代码，现在一句话搞定。而且因为 MCP server 暴露的操作是结构化的，AI 不太会"自由发挥"到出格——它只能调用预定义的工具，每一步操作都有明确的函数和参数约束。这就是 MCP 比让 AI 直接输出一段 API 请求让你自己跑要安全得多的原因。
4.2 网页内容抓取 + R2 存档
第二个场景是内容采集。我用 Browser Rendering MCP 打开一个网页，等页面渲染完成，抓取正文内容，然后调用 Workers MCP server 里的 R2 工具，把内容存进 R2 bucket。整个过程也是纯对话式控制。
这里有个细节值得分享：有些网站的内容是 JavaScript 动态渲染的，直接抓 HTML 源码拿不到东西。Browser Rendering MCP 的优势就在于它操作的是真浏览器，会执行页面里的 JS，等 networkidle 或者特定元素出现后再抓取，拿到的就是渲染完成后的 DOM。你可以让 AI"等待页面里的某个选择器出现后再抓取"，这比传统爬虫的固定延时等待要可靠得多。
不过要提醒一句：抓取别人的网页内容，要注意版权和 robots 协议的约束，别把采集工具用在违法违规的用途上。做工具的人更要有边界感。
4.3 把内部 API 变成 AI 能用的工具
第三个场景是团队协作里特别实用的。我们组有一套内部服务，API 文档是 OpenAPI 规范写的，之前想让 AI 调用这些接口，得手动写工具封装，费时费力。用 OpenAPI MCP Server 之后，直接把规范文件丢给它，AI 就能调用所有接口了。
我实际测试的场景是：让 AI"查询昨天订单的统计数据并按金额排序"，它自动调用了对应的订单查询接口，还自己处理了参数拼接和结果格式化。这个能力对于内部工具型 AI 的门槛降低不是一星半点——以前你得为每个接口写代码，现在只要文档是规范的就直接能用。
如果想把这个能力做成服务而不是只在本地跑，可以把 OpenAPI MCP Server 和 remote-mcp 结合起来，包装成一个远程端点，团队里所有人都能通过自己的 MCP 客户端连接。这就意味着你搭建了一次，全组共享。
4.4 MCP 多智能体场景的扩展想法
多说一句多智能体。现在很多团队在做多智能体协作，基本思路是不同的 agent 负责不同的专业领域，通过 MCP server 共享工具和数据。Cloudflare MCP 在这一块的价值在于：Workers MCP server 可以作为所有 agent 的"基础设施操作入口"，OpenAPI MCP server 可以让所有 agent 访问公司的统一 API，remote-mcp 则让这些 agent 无论跑在哪里都能连上同一套 MCP 服务。它不需要你额外搭复杂的中间层，用现成的协议和组件拼起来就行。
我试过一个简单的 demo：一个 agent 负责收集网页信息，通过 Browser Rendering MCP 抓数据；另一个 agent 负责把数据存到 Cloudflare D1 数据库，通过 Workers MCP server 操作；还有一个总控 agent 负责调度前两个。三个 agent 通过同一个 MCP 客户端连接不同的 server，各司其职。虽然还只是雏形，但已经能感受到多智能体 + MCP 的组合潜力了。
5. 常见问题排查与避坑
最后这部分是我最有感触的。MCP 这个东西，装起来不难，但用起来时不时会冒出各种问题。我把踩过的坑和解决方法整理成了一份速查表，希望能帮你少走弯路。
5.1 问题速查表
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
| MCP server 启动报错，提示缺少环境变量 | API Token 或账号 ID 没传进去 | 检查 CLOUDFLARE_API_TOKEN 和 CLOUDFLARE_ACCOUNT_ID 是否设置，重启终端或客户端 |
| 连接成功但调用工具时报权限错误 | API Token 权限范围不够 | 去 Cloudflare Dashboard 检查 Token 的权限配置，补上对应的编辑权限 |
npx 首次运行很慢 |
npx 在下载包 | 首次运行耐心等，或者用 npm install -g 全局安装，之后启动会快很多 |
| Browser Rendering 启动浏览器失败 | 系统缺少浏览器依赖库 | 安装 Puppeteer 所需系统依赖，Linux 环境常见，如 libnss3、libatk 等 |
| 工具调用超时 | 操作本身耗时较长，或网络问题 | 适当增加客户端 MCP 调用的超时时间；确认网络到 Cloudflare API 的连通性 |
| Cursor 里 MCP 显示红色 | 命令或环境变量配置问题 | 查看 MCP 日志，确认启动命令是否完整、路径是否正确、npx 是否能被找到 |
| 部署 Worker 后路由不生效 | 路由绑定时域名或路径写错 | 让 AI 用资源列表工具检查当前路由配置，或者去 Dashboard 手工核对 |
5.2 关于 API Token 安全的三条建议
API Token 是整个 Cloudflare MCP 的钥匙，丢了比丢密码还麻烦。这里我必须多说几句：
第一，最小权限原则。Token 只给当前场景需要的权限，不要图省事直接给"编辑所有资源"的全权限。MCP server 暴露的工具很强大，AI 一旦拿到高权限 Token，理论上能做账号下的所有操作，权限越大风险越大。
第二，定期轮换。Token 可以设置有效期，建议设置一个合理的过期时间，到期重新生成。如果你把 Token 写在某个共享的脚本里被同事看到了，立即去 Dashboard 吊销并重新生成，不要拖延。
第三，不要提交到代码仓库。这个错误我见过不止一次——有人图方便把配置 MCP server 的脚本带 Token 直接推到 Git 仓库里了。Token 一旦提交，就等于公开了。正确做法是把 Token 放在系统的密钥管理工具或者本地环境变量文件里，并把这个文件加入 .gitignore。
5.3 我在实际使用中的几个小技巧
最后分享几个只有玩熟了才会发现的细节：
第一个是优先用"资源列表"类工具。当你让 AI 操作某个资源但不确定名称时，先让它把当前账号下的资源列出来，再基于结果操作。这样能避免 AI 因为名称猜错去创建重复资源。
第二个是给 AI 说清楚账号上下文。Cloudflare MCP 一次只能操作一个账号（由 API Token 决定），如果团队有多个账号，建议为每个账号配一个独立的 MCP server 条目，用不同的名字区分，比如 workers-prod、workers-staging，这样 AI 调用的时候才不会串。
第三个是善用隔离环境。云资源操作不像本地代码可以随便试错，Worker 部署错了可能影响线上业务。我在测试阶段会用一个单独的子账号或者专门的测试域名来跑 Cloudflare MCP，验证没问题了再切换生产环境的 Token。这个习惯帮我避免了很多事故。
第四个是关于 OpenAPI MCP Server 的效率问题。接口文档很大时，每次都全量加载工具会让 AI 的上下文窗口被塞满，响应变慢。我的做法是提前把 OpenAPI 规范按照业务模块拆分成多个文件，对应启动多个 MCP server 实例，需要哪个模块就连接哪个，AI 的注意力反而更集中。
5.4 关于"要不要自己实现 MCP server"的一点思考
现在网上好多人问"需要自己实现 MCP server 还是直接用现成的"。我的回答是：能用现成的先用现成的，Cloudflare 官方这几个 server 都是开源的，质量有保障；只有当你需要暴露特定领域能力、现有工具覆盖不了的时候，才需要自己写。而且自己写 MCP server 也不难，本质就是定义一个工具列表和对应的执行函数，用官方 SDK 几十行代码就能跑起来。
如果你是想学习 MCP 协议本身，读 Cloudflare 官方这几个 MCP server 的源码是很好的入门材料——它们是生产级别的实现，代码结构清晰，还配套了完整的文档和示例。我在研究 MCP 鉴权设计和工具编排方式的时候，就从 Workers MCP server 的源码里学到了不少东西，包括 OAuth 认证在 MCP 场景下怎么设计和远程 MCP 端点如何处理跨域请求。这些是看协议文档得不到的真东西。
从我自己的经验来说，Cloudflare MCP 不是那种装完就吃灰的玩具，它是真正能改变日常开发习惯的工具。我现在的日常工作流里，凡是涉及 Workers 的部署和资源管理，基本都通过 MCP 完成了，Dashboard 用得越来越少。而且随着 MCP 生态越来越成熟，这种"自然语言操作基础设施"的方式会越来越普及——提前把这个工具链摸熟，后面只会越来越顺手。