适用范围
本政策规范 MCP 核心规范的特性:协议消息、能力、传输、schema 类型和规范性行为要求。规范文档本身的修订生命周期(草案、当前、最终)在版本控制指南中定义。特性状态
一个规范特性恰好处于以下三种状态之一:
已弃用的特性**可以(MAY)**通过一个取代弃用 SEP、并记录了情况变化的 SEP 恢复为活跃状态。恢复遵循与弃用相同的批准路径。如果该特性后来再次被弃用,则弃用特性中的最短弃用窗口期将从新弃用生效的修订起重新计算。
SDK
从规范中移除并不强制 SDK 从其发布版本中丢弃该特性。该时间线由 SDK 自身的修订支持政策管辖。弃用一个特性
在以下情况可以提议弃用某个特性:- 它已被另一个涵盖相同用例的特性所取代,
- 它带来了无法就地缓解的安全、隐私或互操作性风险,
- 生态遥测数据或 SDK 维护者共识表明,相对于其维护成本,其采用度微乎其微,
- 或核心维护者认为适当的任何其他理由。
- 按名称标识该特性,并链接到其在
schema.ts中的定义(在适用情况下)以及规范正文。 - 对照上述标准陈述理由。
- 记录迁移路径,或明确声明无需迁移。如果迁移路径指名了一个替代特性,该特性必须在弃用生效的修订中处于活跃状态;替代特性与弃用可以在同一修订中落地。
- 指定最短弃用窗口期:即该特性在有资格被移除之前必须保持已弃用状态的月数,至少为十二个月。窗口期从该特性首次被标记为已弃用的规范修订发布之日起计算,而非从 SEP 达到最终状态之日起。该特性在窗口期结束当日或之后作为当前修订发布的第一个规范修订中变得有资格移除;该时点即为该特性的最早移除。
- 该特性在
schema.ts中的条目会获得一个@deprecatedJSDoc 标记,引用弃用 SEP 以及弃用生效的修订。 - 该特性的规范正文会获得一条带有相同信息的弃用通知。
- 该修订的
changelog.mdx会在 “Deprecated” 标题下获得一个条目。“Deprecated” 和 “Removed” 是与既有的 Major/Minor/Other 分组并列的常设变更日志标题。 - 该特性会被添加到已弃用登记表,附带其弃用 SEP、其变为已弃用状态的修订、其迁移路径及其最早移除。
已弃用登记表
docs/specification/draft/deprecated.mdx 是一个单一页面,列出了处于已弃用或已移除状态的每一个特性。它是”什么正在被淘汰、到什么时候”这一问题的权威答案,从而使实现者无需从散布在各修订变更日志中的弃用条目重新拼凑出这幅图景。
Tier 1 SDK 义务
一旦某特性变为已弃用所在的修订作为当前修订发布,Tier 1 SDK:- 必须在其下一个发布版本中,使用该语言的原生机制(例如 Java 中的
@Deprecated、.NET 中的[Obsolete]、TypeScript 中的@deprecatedJSDoc、Go 中的Deprecated:文档约定)标记相应的 API 表面为已弃用,并在机制允许的情况下引用弃用 SEP 和最早移除日期。 - 应当在已弃用特性被使用时发出运行时警告,使用该语言的惯用机制(例如 Python 的
DeprecationWarning、Node.js 的process.emitWarning,或可配置的日志记录器)。
移除一个特性
- 一旦某特性被设定为移除,移除将在最短弃用窗口期结束后,由核心维护者酌情执行。
- 移除需要记录在
changelog.mdx和登记表中。 - 对原始弃用或移除 SEP 的任何更改都需要一个 SEP,例如延长或缩短时间线(加速移除)或将特性恢复为活跃状态(特性状态)。
加速移除
当特性带来活跃的安全风险时,即存在一个已发布安全公告的漏洞,或有记录的在野利用且不存在就地缓解措施,十二个月的下限可以缩短。缩短窗口期需要依据治理决策流程获得核心维护者批准,并记录在弃用 SEP 中,或在风险于该 SEP 已达最终状态之后才浮现的情况下,记录在一个引用它的简短加速移除 SEP 中。缩短后的窗口期仍必须在特性变为已弃用与其最早移除之间提供至少九十天。角色
依据治理角色定义,首席维护者对上述每一项批准保留否决权。