​
什么是SEP？

SEP 代表规格增强提案。SEP 是一份设计文档，为 MCP 社区提供信息，或描述 Model Context Protocol 或其流程或环境的新功能。SEP 应提供功能的技术规范及其理由的简明说明。 我们打算将SEP作为提出主要新功能、收集社群关于某个问题的意见以及记录MCP设计决策的主要机制。SEP的作者负责在社群内建立共识并记录不同意见。 由于 SEPs 以版本化仓库中的文本文件形式（GitHub Issues）维护，其修订历史就是功能提案的历史记录。

​
什么是一个合格的SEP？

目标是将标准增强提案(SEP)流程保留给那些足够重大的变更，这些变更需要广泛的社区讨论、正式的设计文档以及决策过程的历史记录。对于较小、更直接的变更，通常更适合使用常规的GitHub议题或拉取请求。 如果您的变更包含以下任何内容，请考虑提议一个SEP：
  • 新功能或协议变更: 对Model Context Protocol中功能的任何新增、修改或删除。包括:
    • 添加新的API端点或方法。
    • 修改现有数据结构或信息的语法或语义。
    • 引入一个新的标准，用于实现不同兼容modelcontextprotocol工具之间的互操作性。
    • 对规范本身的定义、呈现或验证方式的重大更改。
  • 重大变更：任何不向后兼容的更改。
  • 管理或流程变更: 任何改变项目决策机制、贡献指南（如本文件本身）的提案。
  • 复杂或有争议的主题：如果某个变更可能出现多个有效解决方案或引发重大争议，SEP流程会提供必要框架来探索替代方案、记录基本原理，并在实施开始前建立社区共识。

​
SEP 类型

存在三种SEP类型：
  1. 标准追踪 SEP 描述了 modelcontextprotocol 的新功能或实现。它也可能描述将在核心协议规范之外支持的互操作性标准。
  2. 信息类 SEP 描述一个 Model Context Protocol 设计问题，或为 MCP 社区提供通用指南或信息，但不提出新功能。信息类 SEP 不一定代表 MCP 社区的共识或建议。
  3. 过程 SEP 描述了围绕 modelcontextprotocol 的过程，或对过程提出变更（或过程中的事件）。过程 SEP 与标准跟踪 SEP 类似，但适用于 modelcontextprotocol 协议之外的领域。

​
提交一个SEP

SEP流程从针对Model Context Protocol的一个新构想开始。强烈建议每个SEP仅包含一项关键提议或一个新构想。小的改进或补丁通常不需要SEP，可以通过向MCP仓库提交拉取请求直接整合到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仍未找到赞助人，核心维护者可以将SEP状态标记为dormant。

​
SEP格式

每个SEP应包含以下部分：
  1. 前言 — 一段简短的描述性标题、每位作者的姓名和联系信息、当前状态。
  2. 摘要 — 对所处理技术问题的简短描述（约200字）。
  3. 动机 — 动机应清晰说明为何现有协议规范不足以解决该SEP所处理的问题。对于想要修改Model Context Protocol的SEP而言，动机陈述至关重要。缺乏充分动机的SEP提交可能会被直接拒绝。
  4. 规格说明 — 技术规格说明应当描述任何新协议特性的语法和语义。规格说明应足够详细，以便能够实现可相互操作的竞争性实现。应提供一个包含对规格说明更改的PR。
  5. 理论依据 — 理论依据解释了为何做出特定的设计决策。它应描述已考虑过的替代设计及相关工作。理论依据应提供社区内达成共识的证据，并讨论在讨论过程中提出的重要反对意见或担忧。
  6. 向后兼容性 — 所有引入向后不兼容性的SEP必须包含一个部分描述这些不兼容性及其严重程度。SEP必须解释作者建议如何处理这些不兼容性。
  7. 参考实现 — 在 SEP 获得「最终」状态之前必须完成参考实现，但在 SEP 被接受之前不需要完成。虽然在编写代码之前就规范和理由达成共识具有一定价值，但在解决协议细节的许多讨论时，「粗略共识与运行代码」原则仍然非常有用。
  8. 安全影响 — 如果存在与SEP相关的安全顾虑，应明确列出这些问题，以确保SEP评审人员能够充分知晓。

​
SEP 状态

SEP可以处于以下状态之一
  • proposal: 没有赞助人的SEP提案。
  • draft: 拥有赞助者的SEP提案。
  • in-review: SEP 提案待审阅。
  • accepted: 核心维护者已接受SEP，但仍需最终的措辞和参考实现。
  • rejected: SEP被核心维护员驳回。
  • withdrawn: SEP 已撤销。
  • final: 特殊教育计划 已最终确定。
  • superseded: 这个SEP已经被一个更新的SEP所取代。
  • dormant: 尚未找到赞助方并因此被关闭的SEP。

​
SEP 审查与解决

SEP 每两周由 MCP 核心维护者团队审核一次。 对于被采纳的SEP，必须满足某些最低标准：
  • 展示该提案的原型实现
  • 对 MCP 生态系统的明显益处
  • 社区支持与共识
一旦一个SEP被接受，参考实现必须完成。当参考实现完成并被纳入主源代码仓库后，状态将更改为“最终版”。 SEP也可以被"拒绝"或"撤回"。"撤回"的SEP可以在以后重新提交。

​
报告 SEP 错误或提交 SEP 更新

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

​
转让SEP所有权

将SEPs的所有权转移给新的SEP作者有时是必要的。通常，我们希望保留原始作者作为转移后SEP的共同作者，但这确实取决于原始作者。转移所有权的一个合理原因是原始作者不再有时间或兴趣更新它或遵循SEP流程，或者已经从网络上消失（即无法联系或未回复邮件）。转移所有权的一个坏原因是因为你不同意SEP的方向。我们尝试围绕SEP建立共识，但如果不可能，你始终可以提交一个竞争的SEP。 本文件置于公共领域或CC0-1.0-Universal许可下，以较宽松者为准。