先把适用边界划清楚
边缘部署的收益是免运维与就近响应，代价是不能再依赖本地文件系统、本机 Git 仓库与内网服务。开工前判断一次：要暴露的工具是否只依赖 HTTP 就能完成？答案是要，这套架构才成立。
为什么选择 Serverless 边缘架构？
传统的云主机部署需要持续支付服务器租金、维护系统补丁与网络证书。而 MCP 工具调用通常是离散的、按需触发的。
Cloudflare Workers 具有秒级冷启动、全球 300+ 边缘节点路由以及极高性价比（每天免费 10 万次请求），是部署公共或团队轻量 MCP Server 的绝佳平台。
1. 创建 Worker 项目
npm create cloudflare@latest mcp-edge-worker
cd mcp-edge-worker
npm install @modelcontextprotocol/sdk
模板选择以你熟悉的为准；上面这三步只保证项目骨架与 SDK 就位，真正的协议处理还需要自己写。
2. 实现边缘端 SSE 处理
利用 Web 标准的 ReadableStream 与 TransformStream 响应客户端的长连接请求，实现无需持久 Node.js 进程的高并发服务。
配合 Cloudflare Access 或自定义 API Key 头部鉴权，可以安全将内部系统能力暴露给团队成员的 Cursor 或 Claude。
这里有一个绕不开的结构问题：SSE 与 Streamable HTTP 都是有会话状态的连接，而 Worker 实例是无状态的。实践中的常规做法是用 Durable Object 承载每个会话的状态与消息通道，让同一会话的请求落到同一个实例上。具体绑定写法以官方文档为准。
3. 用 wrangler 管配置与密钥
项目根的 wrangler.toml 至少需要这几项（字段随版本演进，以官方文档为准）：
| 配置项 | 作用 | 备注 |
|---|---|---|
name | Worker 名称 | 决定默认访问域名 |
main | 入口脚本 | 指向上一步的源文件 |
compatibility_date | 运行时能力开关 | 升级前先把这一项对齐 |
vars | 非敏感配置 | 例如上游 API 基址 |
密钥不要写进 vars：
wrangler secret put MCP_API_TOKEN
wrangler dev
wrangler deploy
wrangler dev 在本地起一个与边缘同构的运行时，先在这里把工具列表与调用跑通，再部署。
4. 哪些工具适合放边缘
| 适合 | 不适合 |
|---|---|
| 公共数据查询、汇率/天气/文档检索 | 读写本地代码仓库 |
| 封装只读内部 API | 需要长事务或大文件上传的任务 |
| 无状态计算与格式转换 | 依赖内网可达性的操作 |
判断标准是"单次请求能否自成一体"。需要跨调用维持大量中间状态的 Agent 工作流，更适合放在持久进程里，由边缘只做鉴权与转发。
怎么验证部署成功
按顺序做四项检查，任何一步失败都能立刻定位层次：
curl -i https://<worker-url>/sse（路径按你的实现）响应头是text/event-stream，并且能持续收到首条事件。wrangler tail里能看到对应请求，且没有未捕获异常。- 客户端把端点填进去后能拉到工具列表，调用一个最轻的工具能拿到结构化结果。
- 故意去掉鉴权头再请求，应当返回 401 而不是工具清单——这条不通过，说明鉴权逻辑根本没生效。
常见故障速查
| 现象 | 原因 | 处理 |
|---|---|---|
| 连接立刻关闭 | 响应未声明 SSE 内容类型或被缓冲 | 检查响应头与代理缓冲 |
| 工具列表为空 | 初始化握手未完成就返回 | 用 Inspector 直连端点看报文 |
| 会话状态丢失 | 请求落到不同实例 | 用 Durable Object 绑定会话 |
| 偶发 5xx 且无日志 | CPU 或执行时长达到上限 | 拆分调用、把重活交给上游服务 |
| 跨域请求被拒 | 未处理 OPTIONS 预检 | 补 CORS 中间件与允许头 |
| 冷启动感觉慢 | 依赖体积过大 | 精简包体、减少顶层初始化 |
小结
边缘 MCP 的选型可以用三个问题收口：工具是否只依赖 HTTP、会话能否用 Durable Object 承载、单请求计算量是否在额度内。三条都为是，边缘方案的成本优势很实在；有一条为否，就应该回到容器或本地进程，别为了"零服务器"硬迁。