什么是 SEP？
SEP 是 Specification Enhancement Proposal（规范增强提案）的缩写。SEP 是一份设计文档，向 MCP 社区提供信息，或描述 Model Context Protocol 及其流程或环境的新特性。SEP 应当提供该特性的简洁技术规范以及提出该特性的理由。 我们希望 SEP 成为提出重大新特性、收集社区意见以及记录 MCP 设计决策的主要机制。SEP 作者负责在社区中建立共识，并记录不同意见。 由于 SEP 是以文本文件的形式维护在一个版本控制仓库中（GitHub Issues），它们的修订历史即为该特性提案的历史记录。什么样的变更适合 SEP？
我们的目标是将 SEP 流程保留用于那些足够重要、需要广泛的社区讨论、正式的设计文档以及决策过程历史记录的变更。对于较小、较直接的变更，通常更适合使用普通的 GitHub issue 或 pull request。 如果你的变更涉及以下任何一种情况，请考虑提交 SEP：- 新增功能或协议变更：任何添加、修改或删除 Model Context Protocol 功能的变更。包括：
- 添加新的 API 端点或方法。
- 修改现有数据结构或消息的语法或语义。
- 引入一种用于不同 MCP 兼容工具之间互操作性的新标准。
- 对规范本身的定义、展示或验证方式的重大修改。
- 破坏性变更：任何不向后兼容的变更。
- 治理或流程变更：任何更改项目决策机制或贡献指南的提案（比如本文档本身）。
- 复杂或有争议的主题：如果某个变更可能有多种有效解决方案，或者会引发重大讨论，那么 SEP 流程提供了必要的框架，用于探索替代方案、记录理由，并在实施前建立社区共识。
SEP 类型
SEP 分为三种类型：- 标准轨道（Standards Track） SEP 描述 Model Context Protocol 的新功能或实现。它也可以描述一个将在核心协议规范之外支持的互操作性标准。
- 信息类（Informational） SEP 描述一个 Model Context Protocol 的设计问题，或向 MCP 社区提供一般性指南或信息，但不提出新功能。信息类 SEP 不一定代表 MCP 社区的共识或建议。
- 流程类（Process） SEP 描述与 MCP 相关的流程，或提出对某个流程（或流程中的事件）的更改。流程类 SEP 类似于标准轨道 SEP，但适用于 MCP 协议本身以外的领域。
提交 SEP
SEP 流程始于对 Model Context Protocol 的新想法。我们强烈建议每个 SEP 只包含一个关键提案或新想法。小型增强或补丁通常不需要 SEP，可以通过向 MCP 仓库提交 pull request 来实现。SEP 越聚焦，成功的可能性越高。 每个 SEP 必须有一个 SEP 作者 —— 该作者应按照下面描述的格式和风格撰写 SEP，引导在适当论坛中的讨论，并尝试建立社区共识。SEP 作者应首先判断该想法是否适合提交为 SEP。向 MCP 社区论坛（Discord、GitHub Discussions）发帖是实现此目的的最佳方式。SEP 工作流程
SEPs 应作为 GitHub Issue 提交到 规范仓库。标准的 SEP 工作流程如下：- 你（SEP 作者）创建一个格式良好的 GitHub Issue，并添加
SEP和proposal标签。SEP 编号与 GitHub Issue 编号相同，两者可以互换使用。 - 找到一位核心维护者（Core Maintainer）或维护者（Maintainer）来赞助你的提案。核心维护者和维护者会定期查看开放提案列表，决定赞助哪些提案。你可以在提案中@ 维护者列表中的相关维护者。
- 一旦找到赞助者，GitHub Issue 将分配给该赞助者。赞助者将添加
draft标签，确保 SEP 编号出现在标题中，并分配一个里程碑。 - 赞助者将非正式地审查该提案，并可能根据社区反馈要求修改。准备正式审查时，赞助者将添加
in-review标签。 - 添加
in-review标签后，该 SEP 将进入核心维护者团队的正式审查阶段。SEP 可能被接受、拒绝或退回修改。 - 如果在三个月内未找到赞助者，核心维护者可能会将该 SEP 关闭为
dormant状态。
SEP 格式
每个 SEP 应该包含以下部分：- 前言（Preamble） —— 简短的描述性标题，每位作者的姓名和联系方式，当前状态。
- 摘要（Abstract） —— 约200字的技术问题描述。
- 动机（Motivation） —— 动机应清楚地解释为什么现有协议规范无法解决该 SEP 所解决的问题。对于希望更改 Model Context Protocol 的 SEP 来说，动机尤为关键。缺乏足够动机的 SEP 提案可能会被直接拒绝。
- 规范（Specification） —— 技术规范应描述任何新协议功能的语法和语义。规范应足够详细，以便实现多个可互操作的实现。应提供一个包含规范变更的 PR。
- 理由（Rationale） —— 理由应解释为何做出特定设计决策。应描述考虑过的其他设计方案和相关工作。理由应提供社区内共识的证据，并讨论讨论过程中提出的重要反对意见或担忧。
- 向后兼容性（Backward Compatibility） —— 所有引入向后不兼容性的 SEP 必须包含一个描述这些不兼容性及其严重程度的部分。SEP 必须说明作者打算如何处理这些不兼容性。
- 参考实现（Reference Implementation） —— 在任何 SEP 被赋予 “Final” 状态之前，必须完成参考实现，但无需在 SEP 被接受之前完成。虽然在编写代码之前就规范和理由达成共识是有价值的，但“大致共识和可运行的代码”原则在解决许多协议细节讨论时仍然很有用。
- 安全影响（Security Implications） —— 如果 SEP 存在安全问题，应明确写出，以确保评审者了解这些问题。
SEP 状态
SEP 可以处于以下一种状态：proposal：尚未有赞助者的 SEP 提案。draft：已有赞助者的 SEP 提案。in-review：准备接受审查的 SEP 提案。accepted：被核心维护者接受，但仍需最终文字润色和参考实现的 SEP。rejected：被核心维护者拒绝的 SEP。withdrawn：被撤回的 SEP。final：已最终确定的 SEP。superseded：已被更新的 SEP 替代的 SEP。dormant：未找到赞助者并随后被关闭的 SEP。
SEP 审查与决议
SEPs 由 MCP 核心维护者团队每两周审查一次。 要接受一个 SEP，必须满足以下最低标准：- 展示提案的原型实现
- 对 MCP 生态系统的明确益处
- 社区支持和共识
报告 SEP 错误或提交 SEP 更新
如何报告错误或提交 SEP 更新取决于多个因素，例如 SEP 的成熟度、SEP 作者的偏好以及你评论的性质。对于尚未达到final 状态的 SEP，最好将你的意见和修改直接发送给 SEP 作者。一旦 SEP 被最终确定，你可以将更正作为 GitHub 评论提交到该 issue，或提交到参考实现的 pull request。