> ## Documentation Index
> Fetch the complete documentation index at: https://mcp.transdocs.org/llms.txt
> Use this file to discover all available pages before exploring further.

# SEP 指南

> 用于向 Model Context Protocol 提出变更的规范增强提案（SEP）指南

## 什么是 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 分为三种类型：

1. **标准轨道（Standards Track）** SEP 描述 Model Context Protocol 的新功能或实现。它也可以描述一个将在核心协议规范之外支持的互操作性标准。
2. **信息类（Informational）** SEP 描述一个 Model Context Protocol 的设计问题，或向 MCP 社区提供一般性指南或信息，但不提出新功能。信息类 SEP 不一定代表 MCP 社区的共识或建议。
3. **流程类（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 提交到 [规范仓库](https://github.com/modelcontextprotocol/modelcontextprotocol)。标准的 SEP 工作流程如下：

1. 你（SEP 作者）创建一个格式良好的 GitHub Issue，并添加 `SEP` 和 `proposal` 标签。SEP 编号与 GitHub Issue 编号相同，两者可以互换使用。
2. 找到一位核心维护者（Core Maintainer）或维护者（Maintainer）来赞助你的提案。核心维护者和维护者会定期查看开放提案列表，决定赞助哪些提案。你可以在提案中@ [维护者列表](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md)中的相关维护者。
3. 一旦找到赞助者，GitHub Issue 将分配给该赞助者。赞助者将添加 `draft` 标签，确保 SEP 编号出现在标题中，并分配一个里程碑。
4. 赞助者将非正式地审查该提案，并可能根据社区反馈要求修改。准备正式审查时，赞助者将添加 `in-review` 标签。
5. 添加 `in-review` 标签后，该 SEP 将进入核心维护者团队的正式审查阶段。SEP 可能被接受、拒绝或退回修改。
6. 如果在三个月内未找到赞助者，核心维护者可能会将该 SEP 关闭为 `dormant` 状态。

### SEP 格式

每个 SEP 应该包含以下部分：

1. **前言（Preamble）** —— 简短的描述性标题，每位作者的姓名和联系方式，当前状态。
2. **摘要（Abstract）** —— 约200字的技术问题描述。
3. **动机（Motivation）** —— 动机应清楚地解释为什么现有协议规范无法解决该 SEP 所解决的问题。对于希望更改 Model Context Protocol 的 SEP 来说，动机尤为关键。缺乏足够动机的 SEP 提案可能会被直接拒绝。
4. **规范（Specification）** —— 技术规范应描述任何新协议功能的语法和语义。规范应足够详细，以便实现多个可互操作的实现。应提供一个包含规范变更的 PR。
5. **理由（Rationale）** —— 理由应解释为何做出特定设计决策。应描述考虑过的其他设计方案和相关工作。理由应提供社区内共识的证据，并讨论讨论过程中提出的重要反对意见或担忧。
6. **向后兼容性（Backward Compatibility）** —— 所有引入向后不兼容性的 SEP 必须包含一个描述这些不兼容性及其严重程度的部分。SEP 必须说明作者打算如何处理这些不兼容性。
7. **参考实现（Reference Implementation）** —— 在任何 SEP 被赋予 "Final" 状态之前，必须完成参考实现，但无需在 SEP 被接受之前完成。虽然在编写代码之前就规范和理由达成共识是有价值的，但“大致共识和可运行的代码”原则在解决许多协议细节讨论时仍然很有用。
8. **安全影响（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 被接受，就必须完成参考实现。当参考实现完成并合并到主源代码仓库后，状态将更改为 "Final"。

SEP 也可以被 "Rejected" 或 "Withdrawn"。被 "Withdrawn" 的 SEP 可在以后重新提交。

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

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

## 转移 SEP 所有权

有时需要将 SEP 的所有权转移给新的作者。通常，我们希望保留原作者作为共同作者，但这取决于原作者的意愿。一个好的转移理由是原作者不再有时间或兴趣更新它，或继续跟进 SEP 流程，或者已经失联（例如无法通过电子邮件联系）。一个不好的转移理由是你不同意 SEP 的方向。我们努力在 SEP 周围建立共识，但如果无法实现，你始终可以提交一个竞争性的 SEP。

## 版权

本文件置于公共领域或 CC0-1.0-Universal 许可证之下，以更宽松者为准。