MCP 更可预测的发布周期
内容提要
MCP 规范改为每半年发布一次，固定在3月和9月最后一个周二，下次为2027年3月30日；未就绪提案顺延，不拖延整体发布。新增发布经理角色协调提案与SDK工作，发布前八个月启动规划，经软冻结、SDK测试版和硬冻结后发布。此变更不影响现有客户端和服务器。
延伸解读
固定节奏对开发者的实际意义
MCP 规范改为每年 3 月和 9 月最后一个周二发布，并提前公布提案截止和 SDK 测试版日期，开发者可以据此倒推自己的实现与测试计划。未就绪的提案顺延到后续版本，不会拖累整体发布，这意味着围绕已确定版本做规划的风险降低，但依赖新提案的项目需要关注其是否进入当次发布。
发布经理与冻结机制如何降低协调成本
新增的发布经理角色负责跟踪提案作者、工作组和多个 SDK 维护者之间的依赖，帮助在截止前解决问题。流程上设置软冻结和硬冻结：软冻结要求提案标记为 Final 并合并，之后只接受修复和澄清；硬冻结后仅允许关键安全或阻塞性缺陷修复。这种分层冻结让 SDK 维护者有稳定变更集可实现，也让最终检查月有明确边界。
SDK 延迟不会推迟规范发布
文章明确，如果某个 Tier 1 SDK 未能按时提供稳定支持，会记录这一缺口，但不会移动规范发布日期。对使用 SDK 的客户端和服务器开发者来说，这意味着规范版本与 SDK 可用性可能不完全同步，需要留意具体 SDK 的发布说明。同时，SDK 测试版阶段鼓励社区用现有客户端和服务器进行测试，以便在修正仍可进入发布时发现问题。
现有客户端和服务器无需改动
此次变更只影响发布准备流程，不改变 MCP 消息或版本协商机制，因此现有客户端和服务器不需要因为这一公告做任何修改。规范版本继续使用日期格式。对于想参与贡献的开发者，文章建议将想法带到工作组讨论，不需要等待下一个发布周期，也不需要已有完整提案。
Q&A
MCP 规范现在的发布频率和具体日期是什么？
MCP 规范改为每半年发布一次，固定在每年3月和9月的最后一个周二发布。下一次发布定于2027年3月30日，版本号为2027-03-30。
如果某个提案在发布前没准备好，会推迟整个发布吗？
不会。未就绪的提案会顺延到后续发布，而不会拖延整体发布。提案作者可以继续完善，其他人也能按原计划准备。
新增的 Release Manager 角色主要负责什么？
Release Manager 负责协调提案作者、工作组和 SDK 维护者之间的工作，跟踪进度、发现依赖阻塞并推动问题在截止日期前解决。他们帮助提案进入评审队列，规划和管理 SDK 实现工作，并跟进发布前需要关注的事项。
从规划到发布，一个发布周期内有哪些关键时间节点？
发布前8个月启动规划；6个月前开始核心维护者评审，持续到软冻结；2.5个月前软冻结，所有提案必须标记为 Final 并合并；1.5个月前发布 Tier 1 SDK 测试版；1个月前硬冻结，仅接受关键安全或阻塞性修复；发布日发布规范和说明。
这次发布周期变更会影响现有的 MCP 客户端或服务器吗？
不会。此变更只改变发布准备方式，不改变 MCP 消息或版本协商机制，因此现有客户端和服务器无需做任何修改。
普通开发者如何参与 MCP 的改进和发布过程？
可以将想法带到工作组讨论，无需完整提案即可参与；提案准备好后可由工作组或核心维护者赞助进入 SEP 评审队列；还可以测试 SDK 原型或对进行中的提案提供反馈。
