​
什么是 SEP？

SEP 代表规范增强提案 (Specification Enhancement Proposal)。SEP 是一份设计文档，旨在向 MCP 社区提供信息，或描述模型上下文协议、其流程或环境的新功能。SEP 应提供该功能的简明技术规范及其基本原理。 我们希望 SEP 成为提出重大新功能、就某个问题收集社区意见以及记录 MCP 设计决策的主要机制。SEP 作者负责在社区内建立共识，并记录不同意见。 由于 SEP 作为文本文件保存在带版本控制的仓库 (GitHub Issues) 中，其修订历史即为该功能提案的历史记录。

​
什么情况需要 SEP？

我们的目标是将 SEP 流程用于那些重大到需要广泛社区讨论、正式设计文档以及决策过程历史记录的变更。对于较小、较直接的变更，常规的 GitHub issue 或 pull request 通常更为合适。 如果您的变更涉及以下任何一项，请考虑提出 SEP：
  • 新功能或协议变更：任何在模型上下文协议中添加、修改或删除功能的变更。这包括：
    • 添加新的 API 端点或方法。
    • 更改现有数据结构或消息的语法或语义。
    • 为不同 MCP 兼容工具之间的互操作性引入新标准。
    • 对规范本身的定义、呈现或验证方式进行重大更改。
  • 破坏性变更：任何不向后兼容的变更。
  • 治理或流程变更：任何改变项目决策制定、贡献指南（如本文档本身）的提案。
  • 复杂或有争议的话题：如果一项变更可能有多种有效的解决方案或引发重大辩论，SEP 流程可以提供必要的框架来探索替代方案、记录基本原理，并在实施开始前建立社区共识。

​
SEP 类型

SEP 分为三种类型：
  1. 标准类 (Standards Track) SEP 描述模型上下文协议的新功能或实现。它也可能描述一个将在核心协议规范之外支持的互操作性标准。
  2. 信息类 (Informational) SEP 描述模型上下文协议的设计问题，或向 MCP 社区提供一般性指导或信息，但不提出新功能。信息类 SEP 不一定代表 MCP 社区的共识或推荐。
  3. 流程类 (Process) SEP 描述围绕 MCP 的流程，或提议对某个流程进行变更（或在流程中引入一个事件）。流程类 SEP 类似于标准类 SEP，但适用于 MCP 协议本身以外的领域。

​
提交 SEP

SEP 流程始于一个针对模型上下文协议的新想法。强烈建议单个 SEP 只包含一个关键提案或新想法。小的增强或补丁通常不需要 SEP，可以通过向 MCP 仓库提交 pull request 来注入 MCP 开发工作流。SEP 越专注，通常就越容易成功。 每个 SEP 都必须有一位 SEP 作者——即使用下述风格和格式撰写 SEP、在适当的论坛引导讨论，并尝试围绕该想法建立社区共识的人。SEP 作者应首先尝试确定这个想法是否适合成为一个 SEP。在 MCP 社区论坛（Discord、GitHub Discussions）上发帖是最好的方式。

​
SEP 工作流程

SEP 应作为 GitHub Issue 提交到规范仓库中。标准的 SEP 工作流程如下：
  1. 您，作为 SEP 作者，创建一个格式规范的 GitHub Issue，并附上 SEP 和 proposal 标签。SEP 编号与 GitHub Issue 编号相同，两者可以互换使用。
  2. 寻找一位核心维护者或维护者来赞助您的提案。核心维护者和维护者会定期审查开放的提案列表，以决定赞助哪些提案。您可以在您的提案中@维护者列表中的相关维护者。
  3. 一旦找到赞助者，该 GitHub Issue 将被分配给赞助者。赞助者会添加 draft 标签，确保 SEP 编号在标题中，并分配一个里程碑。
  4. 赞助者将非正式地审查该提案，并可能根据社区反馈要求进行修改。当准备好进行正式审查时，赞助者会添加 in-review 标签。
  5. 添加 in-review 标签后，SEP 进入由核心维护者团队进行的正式审查阶段。SEP 可能会被接受、拒绝或退回修订。
  6. 如果 SEP 在三个月内没有找到赞助者，核心维护者可能会以 dormant（休眠）状态关闭该 SEP。

​
SEP 格式

每个 SEP 应包含以下部分：
  1. 前言 (Preamble) — 简短的描述性标题、每位作者的姓名和联系信息、当前状态。
  2. 摘要 (Abstract) — 对所要解决的技术问题的简短（约200字）描述。
  3. 动机 (Motivation) — 动机应清楚地解释为什么现有的协议规范不足以解决 SEP 所要解决的问题。对于希望改变模型上下文协议的 SEP 来说，动机至关重要。没有充分动机的 SEP 提交可能会被直接拒绝。
  4. 规范 (Specification) — 技术规范应描述任何新协议功能的语法和语义。规范应足够详细，以允许不同但可互操作的实现。应提供一个包含对规范变更的 PR。
  5. 基本原理 (Rationale) — 基本原理部分解释了为什么做出特定的设计决策。它应描述曾被考虑过的替代设计和相关工作。基本原理应提供社区内达成共识的证据，并讨论在讨论期间提出的重要反对意见或担忧。
  6. 向后兼容性 (Backward Compatibility) — 所有引入向后不兼容性的 SEP 都必须包含一个章节，描述这些不兼容性及其严重程度。SEP 必须解释作者提议如何处理这些不兼容性。
  7. 参考实现 (Reference Implementation) — 在任何 SEP 被赋予“最终 (Final)”状态之前，必须完成参考实现，但不必在 SEP 被接受之前完成。虽然在编写代码之前就规范和基本原理达成共识的方法有其优点，但在解决许多协议细节的讨论时，“粗略共识和可用代码”的原则仍然很有用。
  8. 安全影响 (Security Implications) — 如果 SEP 存在安全方面的顾虑，应明确写出这些顾虑，以确保 SEP 的审查者能够意识到它们。

​
SEP 状态

SEP 可以处于以下状态之一：
  • proposal (提案)：没有赞助者的 SEP 提案。
  • draft (草稿)：有赞助者的 SEP 提案。
  • in-review (审查中)：准备好接受审查的 SEP 提案。
  • accepted (已接受)：已被核心维护者接受，但仍需最终确定措辞和参考实现的 SEP。
  • rejected (已拒绝)：被核心维护者拒绝的 SEP。
  • withdrawn (已撤回)：已撤回的 SEP。
  • final (最终)：已最终确定的 SEP。
  • superseded (已取代)：已被新的 SEP 取代的 SEP。
  • dormant (休眠)：未找到赞助者并随后被关闭的 SEP。

​
SEP 审查与决议

SEP 由 MCP 核心维护者团队每两周审查一次。 要使一个 SEP 被接受，它必须满足以下最低标准：
  • 一个能展示该提案的原型实现
  • 对 MCP 生态系统有明确的好处
  • 社区支持和共识
一旦 SEP 被接受，就必须完成参考实现。当参考实现完成并并入主源代码库时，状态将更改为“最终 (Final)”。 一个 SEP 也可能被“拒绝 (Rejected)”或“撤回 (Withdrawn)”。处于“已撤回”状态的 SEP 可以在以后重新提交。

​
报告 SEP Bug 或提交 SEP 更新

如何报告 bug 或提交 SEP 更新取决于几个因素，例如 SEP 的成熟度、SEP 作者的偏好以及您评论的性质。对于尚未达到 final 状态的 SEP，最好直接将您的评论和更改发送给 SEP 作者。一旦 SEP 最终确定，您可以将修正作为 GitHub issue 上的评论提交，或向参考实现提交 pull request。

​
转让 SEP 所有权

有时，有必要将 SEP 的所有权转让给新的 SEP 作者。通常，我们希望保留原作者作为转让后 SEP 的共同作者，但这实际上取决于原作者的意愿。转让所有权的一个好理由是原作者不再有时间或兴趣更新它或跟进 SEP 流程，或者已经“人间蒸发”（即无法联系或不回复电子邮件）。一个不好的转让理由是您不同意 SEP 的方向。我们努力围绕一个 SEP 建立共识，但如果无法做到，您随时可以提交一个与之竞争的 SEP。 本文档置于公共领域或采用 CC0-1.0-Universal 许可，以更宽松者为准。