什么是 SEP？
SEP 代表规范增强提案 (Specification Enhancement Proposal)。SEP 是一份设计文档，用于向 MCP 社区提供信息，或描述模型上下文协议 (Model Context Protocol) 及其流程的新功能。SEP 应提供该功能的简明技术规范以及该功能的理由。 SEP 是提议主要新功能、收集社区对某个问题的意见以及记录 MCP 设计决策的主要机制。SEP 作者负责在社区内建立共识并记录反对意见。 在起草 SEP 时，作者应查阅 MCP 设计原则，其中概述了指导协议演进的核心价值观和权衡。 SEP 作为 markdown 文件维护在规范仓库的seps/ 目录 中。它们的修订历史作为功能提案的历史记录。
何时编写 SEP
SEP 流程保留给那些需要广泛社区讨论、正式设计文档和历史记录的重大更改。对于较小的更改，常规的 GitHub 拉取请求通常更合适。 如果您的更改涉及以下内容，请编写 SEP：- 新功能或协议更改 - 在协议中添加、修改或删除功能（新的 API 方法、消息格式更改、互操作性标准）
- 破坏性更改 - 任何不向后兼容的更改
- 治理或流程更改 - 更改决策或贡献指南
- 复杂或有争议的主题 - 可能有多种有效解决方案或引发重大辩论的更改
- Bug 修复和拼写纠正
- 文档澄清
- 为现有功能添加示例
- 不改变行为的次要模式修复
SEP 类型
SEP 有四种类型：- 标准轨道 - 描述 Model Context Protocol 的新功能或实现，或核心规范之外支持的互操作性标准。
- 信息性 - 描述设计问题，或在不提议新功能的情况下向社区提供指南/信息。
- 流程 - 描述围绕 MCP 的某个流程，或提议对某个流程的更改（如本文档）。
- 扩展轨道 - 描述协议扩展。遵循与标准轨道 SEP 相同的审查和接受流程，但表明该提案针对的是扩展而不是协议新增。有关扩展生命周期，请参阅 创建扩展。
SEP 工作流程
逐步流程
Prior discussion is required. SEP authors must discuss the idea with the relevant working or interest group in Discord before opening the SEP pull request, and the PR description must link to that discussion (a Discord thread, WG/IG meeting notes, or a GitHub Discussion). A SEP without a linked prior discussion is not accepted. If no relevant group exists, start a conversation in GitHub Discussions or the#general channel in Discord instead. If there is enough interest, it may be worth creating a new IG or WG. The effort involved in finding sponsors and facilitators is a good signal of whether the idea has sufficient traction.
- 与相关小组讨论：将你的想法带到匹配的工作组或兴趣组中，并在那里完善。保留讨论链接（Discord 线程、会议记录或 GitHub Discussion），以便将其添加到 PR 描述中。
-
起草你的 SEP：将其写成名为
0000-your-feature-title.md的 Markdown 文件，使用0000作为占位符。遵循下面的 SEP 格式。 -
创建拉取请求：将你的 SEP 文件添加到规范仓库的
seps/目录中。该仓库仅接受协作者提交的拉取请求。 -
更新 SEP 编号：创建 PR 后，使用 PR 编号重命名文件（例如，PR #1850 变为
1850-your-feature-title.md）并更新 SEP 头部。 -
寻找赞助人：从维护者列表中标记一位核心维护者或维护者。选择负责领域与你的提案相关的人。提示：
- 标记 1-2 位相关维护者，而不是所有人
- 在相关 Discord 频道中分享你的 PR
- 如果 2 周后没有回应，请在
#general中询问
-
赞助人指派自己：赞助人同意后，会将自己指派给 PR，并将 SEP 状态更新为
draft。 - 非正式审查：赞助人审查提案并可能请求更改。讨论发生在 PR 评论中。
-
正式审查：准备就绪后，赞助人将状态更新为
in-review。在此之前，赞助人会确认小组讨论已经完成，并且其链接已包含在 PR 描述中。SEP 进入核心维护者的正式审查（每两周举行会议）。 -
决议：SEP 可能被标记为
accepted、rejected或退回修改。赞助人更新状态。 -
最终确定：接受后，必须完成参考实现。对于具有可观察协议行为的标准轨道 SEP，还必须合并一个一致性测试。作者将规范更改（模式更改、规范文本和变更日志条目）添加到 SEP 的拉取请求中。SEP 无需 SDK 实现即可变为
final。完成这些工作后，赞助人将状态更新为final，SEP 的 PR 即可合并。已合并的 SEP 会发布在 SEP 索引中，并可通过编号在modelcontextprotocol.io/seps/<number>访问（例如 /seps/1850）。
SEP 状态
重要区别：
dormant 与 rejected 不同。休眠的 SEP 只是没有找到赞助人——想法可能仍然有效。如果情况发生变化（新的社区兴趣、新的用例），可以通过寻找赞助人并重新打开 PR 来恢复休眠的 SEP。
SEP 格式
每个 SEP 应包含以下部分：1. 前言
简短的描述性标题、作者姓名/联系信息、当前状态、SEP 类型和 PR 编号。2. 摘要
对所解决的技术问题的简短（约 200 字）描述。3. 动机
为什么现有的协议规范不足。这至关重要——没有充分动机的 SEP 可能会被直接拒绝。4. 规范
描述新功能语法和语义的技术规范。必须足够详细，以便进行竞争性的互操作实现。5. 理由
为何做出特定的设计决策、考虑的替代设计以及相关的工作。应提供社区共识的证据并解决讨论期间提出的反对意见。6. 向后兼容性
所有引入向后不兼容性的 SEP 必须描述这些不兼容性、其严重程度以及如何处理它们。7. 参考实现
必须在 SEP 达到“最终”状态之前完成，但在接受之前不必完成。8. 安全影响
任何与 SEP 相关的安全问题都应明确记录。 有关完整的文件结构，请参阅 SEP 模板。原型要求
在 SEP 被接受之前，您需要“一个演示提案的原型实现”。以下是符合条件的内容： 可接受的原型：- 官方 SDK 之一中的工作实现（作为分支/分叉）
- 演示关键机制的独立概念验证
- 显示提议行为的集成测试
- 实现该功能的参考服务器或客户端
- 演示核心功能按描述工作
- 显示 API 设计是实用且符合人体工程学的
- 揭示任何边缘情况或实现挑战
- 可供审查者运行（包括设置说明）
- 仅伪代码
- 没有代码的设计文档
- “相信我，它有效”——审查者需要看到它
赞助人角色
赞助人是核心维护者或维护者，他们在审查过程中支持 SEP。赞助人的职责包括：- 审查提案并提供建设性反馈
- 根据社区意见请求更改
- 更新 SEP 状态 随着提案的进展
- 当 SEP 准备就绪时启动正式审查
- 在核心维护者会议上展示和讨论提案
- 确保提案符合质量标准
状态管理
发起人负责更新 SEP 状态。 这确保状态转换由具有相应权限和上下文的人适当地进行。 发起人：- 直接在 SEP markdown 文件中更新
Status字段（或者，如果他们无法访问源仓库，则与作者合作设置正确的状态） - 将匹配的标签应用于拉取请求（例如，
draft、in-review、accepted）
SEP 审查与决议
SEP 由 MCP 核心维护者团队每两周审查一次。 SEP 要被接受，必须满足以下标准：- 一个展示该提案的原型实现
- 对 MCP 生态系统有明确的好处
- 社区支持和共识
一致性测试要求
对于引入或修改可观察协议行为的标准轨道 SEP，在 SEP 能够达到Final 状态之前，必须将一致性场景合并到 一致性仓库 中。
所需内容：
- 一个标记有 SEP 编号的一致性场景，目标为一致性仓库的 draft 规范版本标签
- 一个结构化的可追踪性文件（
sep-NNNN.yaml），将 SEP 的规范部分中的每个 MUST/MUST NOT 和 SHOULD/SHOULD NOT 映射到检查 ID 或已记录的排除项（如果是框架缺口，则附带跟踪 issue） - 该场景在 SEP 的参考实现上通过测试
- 流程类和信息类 SEP
- 没有可观察协议行为的标准轨道 SEP（文档澄清、非验证性 schema 注释、实现加固建议）
- 赞助人 确保编写一致性场景，并验证可追踪性文件覆盖 SEP 中每一项 MUST/MUST NOT 和 SHOULD/SHOULD NOT
- 一致性仓库维护者 审查场景 PR 的技术正确性
- 测试作者可以是任何人：SEP 作者、SDK 维护者、社区贡献者
拒绝后
拒绝不是永久性的。你可以：- 解决反馈 - 如果提出了具体顾虑，解决它们并重新提交
- 讨论拒绝原因 - 在 Discord 中询问以了解理由
- 提交竞争性 SEP - 有时不同的方法效果更好
- 等待合适的时机 - 社区需求会演变；今天被拒绝的内容以后可能会受到欢迎。
报告 SEP 错误或更新
对于尚未达到final 状态的 SEP，请直接在该 SEP 的拉取请求中发表评论。
最终版 SEP 作为已接受设计的历史记录予以保留。它们在最终确定后不会更新。如果规范在某个 SEP 达到 Final 状态后发生变化，则以当前规范为准。每个最终版 SEP 页面都会显示相关说明。
转移 SEP 所有权
偶尔有必要将 SEP 的所有权转移给新作者。一般来说，我们希望保留原作者作为共同作者，但这取决于原作者。 转移所有权的好理由：- 原作者不再有时间和兴趣
- 原作者无法联系
- 你不同意方向（改为提交竞争性 SEP）。