本地怎么测 MCP server：别直接上生产
数据截至 2026-07，各项目能力以官方文档当前版本为准。
本地测 MCP server，测的从来不是”我这台机器上能不能跑起来”，而是”换一个客户端、换一个网络路径、换一个协议版本，它还成不成立”。前者跑通只说明代码没有语法错误，后者才决定它上线之后会不会在别人手里炸开。2026-07-28 发布的新规范把协议层改成了无状态、把 Tasks 挪出了核心、又收紧了授权，这三件事同时把”本地能跑”和”生产能用”之间的距离重新拉开了一次，本地验证清单必须跟着改。
一个很常见的误解是：MCP server 无非就是暴露几个工具函数，本地用调试工具连上去、看到工具列表、点一下能返回结果，就算测完了。这个流程本身没错，它确实是第一步，但它验证的只是”我的实现和我自己的调用方式互相自洽”。真正会出问题的地方，几乎都在这条路径之外——版本握手、授权参数校验、长任务的中断与恢复、负载均衡后面第二次请求落到另一个进程上。这些在单机单进程的本地环境里，默认全部是通过的，因为它们压根没有被触发。
一、先分清本地测试的三层，别把第一层当成全部
把本地验证拆成三层，能省掉大量”上线才发现”的返工：
第一层是连通与握手。 server 启动起来、客户端能建立连接、能完成协议版本协商、能拿到工具清单。这一层失败通常报错很直白，也最容易修。
第二层是工具行为。 每个工具在正常入参下返回什么、在缺参数/错类型/超长输入下返回什么、报错时返回的是结构化错误还是一段裸异常堆栈。这一层是本地最能发挥价值的地方，因为它不依赖真实网络环境，纯靠构造输入就能覆盖。
第三层是协同与部署形态。 换一个客户端实现、换一个协议版本、加一层网关、开多个进程——这一层本地只能部分模拟，剩下的必须靠预发环境和灰度。
绝大多数人只做了第一层，做完就觉得测完了。实际情况是：第一层一次性通过之后基本不会再回归，第二层能挡掉大部分线上工单，第三层挡掉的则是那种”能把整个 agent 卡死”的故障。精力分配应该反过来。
二、2026-07-28 这版规范改了什么，直接影响本地怎么测
先把背景说清楚。MCP 于 2024-11 发布，到 2026-07 大约一年八个月；2025-12 Anthropic 把它捐给了 Linux 基金会下的 Agentic AI Foundation，到现在约七个月，已经是厂商中立、社区治理的标准。2026-07-28 发布的新规范，官方称是自协议发布以来最大的一次修订，此前已经放出过 release candidate。
这次修订包含六块内容：无状态协议内核、Extensions 框架、Tasks、MCP Apps、授权加固、以及一套正式的弃用策略。其中 MCP Apps 这一块，官方博客并没有展开细节，这里也不替它补充设想，具体形态以官方规范文档当前版本为准。
对本地测试影响最直接的是三块：无状态内核、Tasks 移出核心、授权加固。下面分开讲。
三、协议层无状态之后，本地要主动制造”换进程”的场景
新规范在协议层实现了无状态，由六个 SEP（Specification Enhancement Proposal）共同完成，兑现了此前 “The Future of MCP Transports” 里的计划。实际带来的变化很具体：以前需要粘性会话、需要共享 session 存储、需要网关做深度包检测才能正确转发的远程 server，现在可以直接跑在普通的轮询负载均衡后面，按 Mcp-Method 头路由。协议层不再要求会话追踪。
要注意的是，“协议层无状态”不等于”你的 server 不能有状态”。应用层的状态是另一回事——业务数据、缓存、用户上下文该存还得存，只是不能再假设”同一个会话的所有请求都会落到同一个进程上”。
本地怎么验这一点？单开一个进程是验不出来的，因为所有请求天然落在同一份内存里。可操作的做法有几个：
- 在本地起两个及以上的 server 实例，前面挂一个最简单的轮询转发，然后跑一遍完整的工具调用流程。任何依赖”上一次请求留下的内存变量”的实现，都会在这里露馅。
- 给 server 加一个”实例标识”字段写进日志，本地跑的时候直接看一次业务流程跨了几个实例、有没有在跨实例的地方失败。
- 主动重启：在一段多轮交互进行到一半时把当前实例杀掉，看客户端能不能继续。这个动作在本地做只要几秒，放到生产环境就是一次事故。
- 把所有”我先在内存里存一下，下次请求再取”的代码翻出来单独审一遍。这类写法在有粘性会话的年代是可用的，现在是定时炸弹。
四、Tasks 移出核心之后，长任务的本地验证要换个问法
新规范把用于长时间运行操作的 Tasks 特性从核心协议移到了 extension。同时 Extensions 框架允许用户自建 extension，与官方认可的 extension 并存。
这个改动对本地测试的含义是：你不能再默认”对面的客户端一定支持长任务”。以前它在核心里，实现方可以假设它存在；现在它是一个扩展，对面支不支持要看具体实现。
本地要补的验证是这么几条：
- 在”对面不支持这个 extension”的假设下跑一遍。 你的 server 需要有一个明确的降级路径——是直接拒绝并给出可读的错误，还是退回同步执行并接受更长的等待。两种都可以，但必须是想清楚之后选的，而不是运行时才发现没有分支。
- 长任务的中断恢复要在本地手动触发。 任务执行到一半断开连接、客户端重连之后能不能拿到进度或结果，这是长任务实现里最容易出问题的地方，本地断网或者直接掐掉客户端进程就能复现。
- 如果你自建了 extension，要单独测它的协商环节。 自建扩展和官方扩展可以并存，也就意味着协商结果有多种组合，本地至少要覆盖”都支持""只支持官方""都不支持”这三种。
- 别把长任务和超时混为一谈。 一个跑五分钟的正常任务，和一个卡住不动的异常任务，在客户端看来可能是同一个现象，server 侧要能区分并上报。
五、授权是本地最难测的一段，也最不能跳过
这次修订用六个 SEP 让授权规范更贴近真实的 OAuth 2.0 / OpenID Connect 部署，其中包括要求客户端按 RFC 9207 校验 iss 参数（SEP-2468）。
授权难测的原因很实在：本地开发时大家习惯把鉴权关掉，或者用一个写死的 token 跳过整条链路。结果就是授权相关的代码路径在本地一次都没被执行过，上线当天第一次真实运行。
现实一点的做法：
- 本地至少要跑一遍开启鉴权的完整流程，哪怕用的是本地起的测试身份提供方，也比整条关掉强。关键是让校验代码真的被执行到。
- 专门构造几个”应该被拒绝”的用例：
iss不匹配、token 过期、受众不对、签名被改。授权的正确性一半体现在正常通过，另一半体现在该拒绝的时候确实拒绝了。只测通过路径等于没测。 - 把鉴权失败时的错误返回也当成接口的一部分来测。 返回信息既要让调用方知道该修什么，又不能把内部细节漏出去。
- 授权相关的具体参数名、必选项和校验规则，以官方规范文档当前版本为准，不要照抄几个月前的教程——这一块正是这次改动最大的区域之一。
六、版本兼容：本地跑通不等于对面跑通
这次修订的破坏性是官方明说的。维护者 David Soria Parra 称这是自加入授权以来最实质的变更，原话是 “A lot of things that made MCP are gone.”。更具体的一条是：2026-07-28 版本的 server 可能无法与旧 client 协同，反之亦然。同时，弃用机制给旧版本留了十二个月的窗口。
这意味着本地测试必须包含一项以前可以省略的动作：用不止一个版本的客户端连一遍。只用你手边那个刚更新过的客户端测，测出来的结论只对那一个版本成立。
具体能做的：
- 本地保留一个旧版本的客户端环境，新旧各连一次，把握手阶段的协商结果和失败信息都记下来。
- 明确写下你的 server 声明支持哪些协议版本，并且在代码里真的按这个声明拒绝范围外的连接，而不是让它连上之后在某个工具调用里莫名其妙地失败。握手阶段失败是清晰的，运行中失败是难查的。
- 把十二个月窗口当成排期依据而不是拖延理由：窗口的意义是让你有时间做双版本并行，不是让你到最后一个月才开始改。
七、一份可以照着走的本地顺序
把上面的内容压成一条实际执行路径，大致是这样：
- 单实例起 server，用调试客户端连通，确认握手和工具清单正常。具体用哪个调试工具、命令怎么写，以官方仓库和文档当前版本为准。
- 逐个工具跑正常入参，确认返回结构符合你自己声明的 schema。
- 逐个工具跑异常入参：缺字段、类型错、超长、空值。确认返回的是结构化错误。
- 开启鉴权重跑一遍，并补上”应该被拒绝”的几个用例。
- 起多实例加轮询转发，重跑完整流程，中途杀一个实例。
- 如果用到长任务扩展，补协商组合与中断恢复。
- 换一个版本的客户端，重跑第 1 步和第 2 步。
- 全部通过之后再进预发，生产走灰度。
这八步里，第 5 步和第 7 步是最容易被跳过的，也是这次规范修订之后最值得加进去的两步。
八、本地测不出来的东西，得诚实承认
本地环境有几件事结构性地做不到，硬要在本地覆盖只会浪费时间：
- 真实并发下的资源竞争。 本地起几个进程模拟不了生产的流量形态，连接池耗尽、下游限流这类问题基本只能在预发或灰度暴露。
- 真实网关和中间设备的行为。 企业环境里的代理、防火墙、TLS 终止层会对请求头做各种处理，本地没有这一层。按
Mcp-Method头路由这件事，能不能在你们公司的网关上正确生效，只能在真实链路上试。 - 对面客户端的实现差异。 各家客户端对规范的落地程度不一样，本地手头有几个就只能测几个。
- 长时间运行后的退化。 内存缓慢增长、连接泄漏这类问题需要时间维度，本地跑几分钟看不出来。
对这几类，正确的应对不是”想办法在本地测出来”，而是承认它们必须靠灰度、可观测性和可回滚的发布流程兜住。上线前把回滚路径准备好，比多写十个本地用例更实际。
九、找 server 参考实现的时候看哪里
需要对照别人怎么实现时，官方注册表 registry.modelcontextprotocol.io 提供 server 发现、文档与 API 参考，由 modelcontextprotocol GitHub 组织维护，是社区驱动的。路线图上还有 MCP Server Cards——一种通过 .well-known URL 暴露 server 元数据的标准，让注册表和爬虫不用建立连接就能发现能力。
生态规模方面，按官方与行业公开资料的口径，公开的 MCP server 数量超过一万个在生产中使用，SDK 月下载量超过九千七百万。这类数字是汇总口径而非精确统计，看个量级就好——它的实际意义是：你遇到的问题大概率有人遇到过，翻一翻注册表和仓库 issue 往往比自己硬猜快。
另外提醒一句：这次修订时效性很强，中文资料几乎没有跟上，网上仍能搜到把 2025 年的版本当作当前稳定版、并预告”下一版暂定 2026 年 6 月”的页面，这类内容已经过期，不要拿来当依据。以官方 blog 与规范文档当前版本为准。
小结
本地测 MCP server 的价值，集中在工具行为这一层——构造异常入参、验证错误返回，这是本地能做得最扎实、性价比也最高的部分。协议层无状态化之后，多实例和杀进程要主动在本地制造，不能等生产暴露。Tasks 移到扩展之后，“对面不支持”是一个必须有明确分支的正常情况，而不是意外。授权这一段本地最容易被关掉，也最该开着跑一遍，且必须测”该拒绝时确实拒绝了”。最后，新旧版本可能互不兼容是官方明说的事实，十二个月窗口是用来做双版本并行的，不是用来拖的——本地跑通只是让你有资格进预发，离”能上生产”还隔着灰度和回滚。