MCP 协议火了之后，一个别扭的事实越来越明显：大部分 MCP 服务器还跑在本地。你在 Claude Desktop 里调用工具，背后是一个 Node 进程在你的笔记本上默默工作。关机就不灵了，换机器得重配，团队协作更是无从谈起。
Cloudflare 的 building-mcp-server-on-cloudflare 这个 Skill，试图把 MCP 服务器的部署图景从”本地小作坊”拉到”全球边缘网络”。它不是给你看一个 demo 然后让你自己琢磨，而是把从工具定义到 OAuth 认证到生产部署的完整链路拆成了可执行的步骤，跑在 Cloudflare Workers 。
说真的，这东西的野心比表面上看起来大得多。它不只是”教你怎么部署 MCP 服务器”，而是暗示了一整套新范式：MCP 服务器应该像 Web 应用一样部署，有域名、有认证、有自动扩缩，任何人都能在任意客户端调用。
换个角度讲，这个 Skill 在试图回答一个还没被充分讨论的问题：当你的 AI Agent 需要全天候访问一组工具时，这些工具应该住在哪里？Cloudflare 的回答简单直接，住 Workers 上。
环境准备
上手门槛不高，但有几样东西得先备好。
Cloudflare 账号是必需的，而且要开通 Workers 功能。免费套餐足够开发测试用，每天 10 万次请求的配额对个人 MCP 服务器来说绰绰有余。Node.js 18 以上，npm、pnpm 或 yarn 随便选一个你顺手的。
Wrangler CLI 是 Cloudflare Workers 的命令行工具，负责本地调试和部署。装一遍就行：
npm install -g wrangler
装完之后跑个 wrangler login 把 CLI 和你 Cloudflare 账号打通，整个链路就通了。这步没什么坑。
新手最容易卡在什么地方？Durable Objects 的概念。如果你的 MCP 服务器需要状态管理（比如会话记忆、数据持久化），Durable Objects 是绕不开的。好消息是，这个 Skill 提供的两个模板已经把 DO 的配置写死在 wrangler.toml 里了，你不需要手动配。但如果你的工具想访问 D1 数据库或 KV 存储，得在 wrangler.toml 里手动加 binding，不然运行时会找不到。
操作流程
整个流程从一行脚手架命令开始，五步走完。
第一步，选模板。Skill 给了两个入口：公共服务器模板（remote-mcp-authless）和 GitHub OAuth 认证模板（remote-mcp-github-oauth）。前者适合内部工具或公开 API，任何人拿到 URL 就能调。后者适合需要区分用户身份的场景，连接工具前先要用户登录授权。
npx create cloudflare@latest -- my-mcp-server --template=cloudflare/ai/demos/remote-mcp-authless
第二步，定义工具。这是整个流程的核心。tools 函数用 Zod 做参数校验，返回值走 MCP 协议的标准 format。一个天气查询工具长这样：
this.server.tool(
"get_weather",
{ city: z.string() },
async ({ city }) => {
const response = await fetch(`https://api.weather.com/${city}`);
const data = await response.json();
return {
content: [{ type: "text", text: JSON.stringify(data) }],
};
}
);
参数类型、校验规则、错误处理全部自动生成，不需要额外写胶水代码。值得留意的是，这里的 fetch 是 Cloudflare Workers 的原生 API，不需要额外 import。这意味着你在工具函数里可以调任何 HTTP API，不受 Node 生态的限制。
第三步，本地测试。起开发服务器后用 MCP Inspector 验证工具是否正常注册：
npm start
# 另一个终端
npx @modelcontextprotocol/inspector@latest
Inspector 打开后输入 http://localhost:8787/sse，能看到 “List Tools” 按钮就说明工具注册成功。这步可以省你很多排查时间，别跳过。
第四步，部署。一行命令推到生产环境：
npx wrangler deploy
MCP 服务器会分配一个 your-worker.your-account.workers.dev/sse 的全球域名。从部署完成到全球可用，通常不超过 30 秒。
第五步，连接客户端。Claude Desktop 是目前主流的 MCP 客户端，但它本身不支持远程 MCP 传输协议。Cloudflare 提供了 mcp-remote 代理来桥接，配置文件里加上这段就行：
{
"mcpServers": {
"my-server": {
"command": "npx",
"args": ["mcp-remote", "https://your-mcp.your-account.workers.dev/sse"]
}
}
}
重启 Claude Desktop 后就能调用你的远程工具了。整个过程从零到能用在 Claude 里调工具，不折腾的话 15 分钟够了。
关键设计
这个 Skill 最聪明的设计决策，是选了 McpAgent 作为核心基类而不是纯函数式的 createMcpHandler。
McpAgent 底层绑定了 Durable Objects，每个客户端连接对应一个独立的 DO 实例。这意味着你的 MCP 服务器天然具备会话状态管理能力。用户在对话中途断开重连，工具调用的上下文不会丢。对一个需要多轮交互的工具来说（比如逐页分析 PDF、逐步执行 CI/CD 流程），这个能力不是锦上添花，是刚需。
createMcpHandler 的方案更快更轻，适合查天气、做数学这种无状态工具。McpAgent 多了 DO 的开销，但换来了每个会话独立的作用域。从 SKILL.md 的结构来看，设计者明显把 McpAgent 当成了默认推荐路径，公共模板用的是它，认证模板用的也是它。
如果让我猜设计意图，这种选择暗示 Cloudflare 对 MCP 服务器的定位不只是”API 网关”，而是”会话感知的 Agent 工具服务”。这点跟 Anthropic 的 MCP 协议设计方向一致，但落地得更具体。
两个模式的 trade-off 也很清晰。公共模式部署快、零配置，但任何拿到 URL 的人都能调你的工具，适合内部测试或个人项目。OAuth 认证模式多了身份注入和权限范围控制，但附加的配置负担也不少：
-
OAuth App 注册和配置 -
回调 URL 与 Worker 路由对齐 -
Client ID 和 Client Secret 管理 -
Token 刷新逻辑和过期处理
这些步骤每一个都不难，但加起来就是一段不短的调试时间。关键是报错信息往往不够明确，回调 URL 差一个斜杠就 401，排查起来很磨人。
这两条路径不是”先用公共模式，以后再加认证”那么简单。认证模式的代码结构（路由分发、token 校验、scope 检查）和公共模式差异不小，迁移有成本。
使用场景
最直接的使用场景：你写了一个内部工具链，想随时通过 Claude Desktop 调用它。
之前你得把工具跑在本地的 Docker 里，Node 进程常驻后台。换台电脑得重来一遍，团队里其他人想用还得每个人配一套。用这个 Skill 部署到 Workers 后，工具变成了一个全球可达的端点，你跟同事配同一个 mcp-remote 地址就行。
另一个容易被忽略的场景是构建公开 MCP 服务。比如你维护了一个开放数据 API，以前用户得翻你的文档、写 HTTP 请求、解析 JSON。现在你给这个 API 包一层 MCP 工具，用户直接用自然语言就能查询你的数据。这个 Skill 的公共模板恰好适合这种场景，一行命令部署，开箱即用。
Cloudflare 自己在文档里提到的做法更激进：把 Cloudflare 平台本身的 API 能力暴露成 MCP 工具。具体来说就是：
-
D1 数据库的 SQL 查询 -
KV 存储的键值读写 -
R2 对象存储的文件操作 -
Workers AI 的模型调用
一个 Agent 通过 MCP 协议直接操作这些资源，所有动作都发生在 Workers 的边缘节点上。这意味着你的 AI Agent 不再是”调用外部 API 的工具人”，而是”可以直接操控基础设施的 operator”。
这个方向一旦跑通，MCP 服务器就不只是”你能调的工具”，而是”你能直接操控的基础设施”。从 Skill 的架构选择来看（McpAgent + DO + Cloudflare Bindings），这条路径是技术上行得通的。社区里已经有人在讨论用 MCP 工具替代部分 CI/CD 步骤的可行性了。
洞察与反思
MCP 服务器的远程化部署是个明显的趋势，但这个 Skill 让我意识到它的推动力比我想象中更具体。
之前大家讨论 MCP 的未来，更多聚焦在协议层面的几个议题：
-
Streamable HTTP 替代 SSE 的时间表 -
工具发现机制的设计方案 -
动态注册的标准化推进
但基础设施层面的问题其实更迫切：如果 MCP 要成为 AI Agent 的标准工具接口，它必须像 REST API 一样可部署、可发现、可治理。只靠本地进程是走不到那一步的。
从这个角度看，Cloudflare 在这个 Skill 上的投入不只是”做个教程”。Workers 的无服务器架构天然适合 MCP 服务器的特性：请求驱动（按调用计费）、全球低延迟（边缘节点就近响应）、状态管理（Durable Objects）。这些能力恰好是运行生产级 MCP 服务所需的基础。
但我有一个保留意见：OAuth 认证的复杂度。Skill 提供的 GitHub OAuth 模板是一个起点，但实际部署中你会发现 OAuth Provider 的接入不是”换个配置文件”就能搞定的事。Token 刷新、权限细粒度控制、多 Provider 并存，这些在文档里要么一笔带过，要么指向 references 让你自己看。对于一个 Skill 来说这不算缺陷，因为”指导”和”代劳”的边界本来就模糊。
另一个值得关注的点是生态锁定。用 McpAgent 类构建的工具只能在 Cloudflare Workers 上运行。如果你以后想把服务器迁移到 AWS Lambda 或自建 Node 服务，重写是跑不掉的。当然，反过来说，Workers 的全球部署能力和边缘计算优势也是其他平台短期追不上的。选择权在开发者自己手上。
| 资源 | 地址 |
|---|---|
| Skill 主页 | https://smithery.ai/skills/cloudflare/building-mcp-server-on-cloudflare |
| GitHub（Cloudflare Skills） | https://github.com/cloudflare/skills |
| Cloudflare MCP 文档 | https://developers.cloudflare.com/agents/model-context-protocol/ |
| MCP Inspector | https://github.com/modelcontextprotocol/inspector |
总结
把这个 Skill 从头到尾走一遍，我对 MCP 服务器的部署方式的认知确实变了。之前默认就是本地跑，现在觉得远程部署才是正确的默认选项。
MCP 协议本身还在快速迭代，但基础设施层面的探索已经跑在前面了。building-mcp-server-on-cloudflare 把这整套流程做成了可复用的操作路径：
-
模板创建：两行命令选好服务器类型 -
工具定义：Zod 校验加异步函数，写业务逻辑就够了 -
本地测试：Inspector 验证，跑通再部署 -
生产部署：一行 wrangler deploy，全球分发
每一步都省掉了反复查文档和试错的时间。
如果你已经在用 MCP 工具但还在本地跑，或者想把自己开发的能力暴露给 AI Agent 调用，花 15 分钟跑一遍这个 Skill 的流程，比你想象的值。