治理与管理

Model Context Protocol (MCP) 遵循正式的治理模型，以确保决策透明和社区参与。本文档概述了该项目的组织方式及决策流程。

​

通用项目政策

Model Context Protocol 已注册为 Model Context Protocol a Series of LF Projects, LLC。适用于 Model Context Protocol 及其参与者的政策（包括商标使用指南）位于 https://www.lfprojects.org/policies/。根据本治理文档条款批准的任何治理变更，也必须获得 LF Projects, LLC 的批准。 Model Context Protocol 参与者知悉，所有新贡献的版权将由版权所有者作为独立创作作品保留，且不要求任何贡献者或版权所有者将版权转让给本项目。 除下述情况外，所有针对本项目的代码和规范贡献必须使用 Apache License 2.0 版本（可在此处获取：https://apache.ac.cn/licenses/LICENSE-2.0）（即“项目许可证”）。 所有出站代码和规范均将在项目许可证下提供。核心维护者可在例外情况下批准使用其他开源许可证用于入站或出站贡献。 所有文档（规范除外）均在知识共享署名 4.0 国际许可证 (Creative Commons Attribution 4.0 International) 下提供，网址：https://creativecommons.org/licenses/by/4.0。

​

技术治理

MCP 项目采用类似于 Python、PyTorch 及其他开源项目的层级结构

• 贡献者：提交议题、发起合并请求 (PR)，并为项目做出贡献。
• 维护者：推动 MCP 项目内的特定组件，例如 SDK、文档和工作组。
• 核心维护者：推动整体项目方向，并监督贡献者和维护者。
• 首席维护者：最终决策者（也称为 BDFL - 仁慈的终身独裁者）。

维护者、核心维护者和首席维护者共同组成 MCP 指导小组。 期望所有维护者对 MCP 的设计理念有强烈的认同。技术治理流程中的成员身份属于个人，而非公司。也就是说，没有为特定公司保留的席位，成员身份与个人相关，而非其所受雇的公司。

​

沟通渠道

技术治理通过所有维护者共享的 Discord 服务器进行。每个维护者小组可以选择额外的沟通渠道，但所有决策及其支持性的讨论必须记录在案，并在 Discord 服务器上以透明的方式公开。

​

角色

贡献者阶梯 (Contributor Ladder) 是定义每个角色的权威文档——包括其要求、职责、特权、晋升流程及非活跃政策。本节提供了角色与治理关系的概览。 维护者：管理特定的领域，如 SDK、文档或工作组。他们独立为各自领域做出决策，并在需要时上报给核心维护者。维护者拥有其各自仓库的写入权限。 核心维护者：引导 MCP 规范和整体项目方向。他们可以通过多数投票否决维护者的决定，解决争议，并任命或移除维护者。核心维护者对所有 MCP 仓库拥有管理权限，但使用与外部贡献者相同的合并请求工作流。 首席维护者：拥有最终决策权，并可以否决核心维护者或维护者的任何决定——即众所周知的“仁慈的终身独裁者 (BDFL)”角色。首席维护者负责任命和移除核心维护者，并拥有所有项目基础设施的管理权限。他们属于核心维护者小组，并被期望公开阐明其理由。 贡献者阶梯还定义了成员和社区版主角色，这些角色不在指导小组内。

​

决策流程

核心维护者小组每两周举行一次会议，讨论并投票表决提案，以及讨论任何需要处理的主题。如果需要，共享的 Discord 服务器可用于讨论和投票表决较小的提案。 首席维护者、核心维护者和维护者小组应尽量每三到六个月进行一次线下会面。

​

流程

核心维护者和首席维护者负责 Model Context Protocol 的所有方面，包括文档、议题、内容建议以及 MCP 项目下的所有其他部分。维护者负责其 MCP 项目领域内的文档、议题和内容建议，但鼓励他们参与 MCP 项目的通用维护工作。 维护者、核心维护者和首席维护者应使用与外部贡献者相同的贡献流程，而不是直接对仓库进行更改。这提供了对意图的洞察和讨论的机会。

​

工作组与兴趣小组

MCP 的协作与贡献围绕两种结构组织：工作组和兴趣小组。

• 兴趣小组：通过公开讨论识别并阐明 MCP 应该解决的问题。
• 工作组：通过产生 SEP 或实现等交付成果来开发具体的解决方案。

有关如何创建、参与和促进这些小组的详细信息，请参阅工作组与兴趣小组文档。

​

规范增强提案 (SEPs)

对规范的拟议变更必须作为规范增强提案 (SEPs) 提交。SEP 是提议重大新功能、收集社区意见以及记录设计决策的主要机制。 有关完整的 SEP 流程、格式要求和状态工作流，请参阅 SEP 指南。

​

维护职责

没有专门维护者的组件（如文档）属于核心维护者的职责范围。这些组件遵循通过合并请求的标准贡献指南，由维护者处理审核，如有重大变更则升级至核心维护者审核。 鼓励核心维护者和维护者改进 MCP 项目的任何部分，无论其是否有正式的维护分配。

​

沟通

​

核心维护者会议

核心维护者小组每两周开会讨论提案和项目。提案记录应公开。核心维护者小组将努力每 3-6 个月进行一次线下会面。

​

公开聊天

MCP 项目维护一个公开的 Discord 服务器，其中包含兴趣小组的开放聊天频道。MCP 项目可能会为某些沟通设立私人频道。

​

维护者的提名、确认与移除

维护者小组的成员身份是基于贡献价值在展示了专业知识并与 MCP 方向一致后授予个人的。成员身份与个人相关，而非其雇主，且没有任期限制。 每个角色的提名流程、赞助要求、审核时间表和非活跃标准都在贡献者阶梯的晋升流程中定义。

​

现任首席维护者

• David Soria Parra
• Den Delimarsky

​

现任核心维护者

• Peter Alexander
• Caitie McCaffrey
• Kurtis Van Gent
• Clare Liguori
• Paul Carleton
• Nick Cooper
• Nick Aldridge

​

荣休成员

• Justin Spahr-Summers（联合创始人，荣休首席维护者）
• Basil Hosmer（荣休核心维护者）
• Che Liu（荣休核心维护者）

​

现任维护者与工作组

请参阅维护者列表。