跳到主要内容
模型上下文协议 (MCP) 遵循正式的治理模型，以确保决策的透明度和社区的参与。本文档概述了项目的组织方式以及决策的制定流程。

​
项目通用政策

模型上下文协议已作为 Model Context Protocol a Series of LF Projects, LLC 成立。适用于模型上下文协议及参与者的政策（包括商标使用指南）位于 https://www.lfprojects.org/policies/。根据本治理文档规定批准的治理变更还必须获得 LF Projects, LLC 的批准。 模型上下文协议参与者承认，所有新贡献的版权将由版权持有者作为独立作品保留，且不要求任何贡献者或版权持有者将版权转让给项目。 除下述情况外，所有向项目提交的代码和规范贡献必须使用 Apache License, Version 2.0（详见：https://apache.ac.cn/licenses/LICENSE-2.0）（即“项目许可证”）。 所有对外发布的代码和规范将根据项目许可证提供。核心维护者可根据例外情况批准对入站或出站贡献使用替代的开源许可证。 所有文档（不包括规范）将根据知识共享署名 4.0 国际许可协议 (CC BY 4.0) 提供，详见：https://creativecommons.org/licenses/by/4.0。

​
技术治理

MCP 项目采用分层结构，类似于 Python、PyTorch 和其他开源项目
  • 由贡献者组成的社区，负责提交 issue、提出 pull request 并为项目做出贡献。
  • 一小部分维护者负责推动 MCP 项目中的各个组件，例如 SDK、文档等。
  • 贡献者和维护者由核心维护者监督，核心维护者负责驱动项目的整体方向。
  • 核心维护者中有两名首席核心维护者，他们是兜底的决策者。
  • 维护者、核心维护者和首席核心维护者共同构成 MCP 指导小组。
所有维护者都应高度认同 MCP 的设计理念。技术治理过程中的成员身份针对个人而非公司。也就是说，没有为特定公司保留的席位，成员身份与个人相关联，而非雇用该个人的公司。这确保了维护者能够从协议本身和开源社区的最佳利益出发采取行动。

​
渠道

技术治理通过一个共享的 Discord 服务器进行，该服务器由所有维护者、核心维护者和首席维护者组成。每个维护者小组可以选择额外的沟通渠道，但所有决策及其支持性的讨论必须被记录并透明地在 Discord 服务器上公开。

​
维护者

维护者负责 MCP 项目内的工作组或兴趣小组。这些通常是独立的仓库，如特定语言的 SDK，但也可以扩展到仓库的子目录，如 MCP 文档。维护者可以采用自己的规则和程序来做出决策。维护者应独立为其各自的项目做出决策，但在需要时可以推迟或升级给核心维护者。 维护者负责：
  • 与社区贡献者进行周全且高效的互动，
  • 维护并改进其负责的 MCP 项目区域，
  • 支持文档、路线图及 MCP 项目的其他相关部分，
  • 向核心层提交来自社区的想法。
鼓励维护者在需要时提议增加维护者。维护者只能由核心维护者或首席核心维护者在任何时间且无需理由地任命或移除。 维护者对其各自的仓库拥有写入和/或管理权限。

​
核心维护者

核心维护者应深入理解模型上下文协议及其规范。其职责包括：
  • 设计、审查和引导 MCP 规范以及 MCP 项目所有其他部分（如文档）的演进，
  • 制定项目一致的长期愿景，
  • 以公平透明的方式调解和解决有争议的问题，在可能的情况下寻求共识，并在必要时做出果断选择，
  • 任命或移除维护者，
  • 以符合 MCP 最佳利益的方式管理 MCP 项目。
核心维护者作为一个整体，有权通过多数票否决维护者做出的任何决策。核心维护者有权按其认为合适的方式解决争议。核心维护者应公开阐明其决策过程。核心小组负责采用自己的程序来做出决策。 核心维护者通常拥有所有 MCP 仓库的写入和管理权限，但应使用与外部贡献者相同的贡献机制（通常是 pull-request）。出于安全考虑的情况除外。

​
首席维护者 (BDFL)

MCP 有两名首席维护者：Justin Spahr-Summers 和 David Soria Parra。首席维护者可以否决核心维护者或维护者的任何决策。这种模式在开源社区中通常被称为“仁慈的独裁者 (BDFL)”。首席维护者应公开阐明其决策并给出明确的决策理由。首席维护者是核心维护者小组的成员。 首席维护者负责确认或移除核心维护者。 在可能的情况下，首席维护者是 MCP 项目所有基础设施的管理员。这包括但不限于所有沟通渠道、GitHub 组织和仓库。

​
决策流程

核心维护者小组每两周开会一次，讨论提案并对提案进行投票，同时也讨论任何需要的议题。共享的 Discord 服务器可用于在必要时讨论和表决较小的提案。 首席维护者、核心维护者和维护者小组应尝试每三到六个月进行一次线下会面。

​
流程

核心维护者和首席维护者负责模型上下文协议的所有方面，包括 MCP 项目下的文档、issue、内容建议及所有其他部分。维护者负责其所负责 MCP 项目区域的文档、issue 和内容建议，但鼓励参与 MCP 项目的通用维护。维护者、核心维护者和首席维护者应使用与外部贡献者相同的贡献流程，而不是直接修改仓库。这有助于洞察意图并提供讨论机会。

​
工作组与利益小组

MCP 的协作和贡献围绕两种结构组织：工作组 (Working Groups) 和兴趣小组 (Interest Groups)。 兴趣小组负责识别和阐明 MCP 应解决的问题，主要是通过促进社区内的开放讨论。相比之下，工作组专注于通过协作产出交付成果（如 SEP 或规范的社区自有实现）来开发具体解决方案。虽然来自兴趣小组的意见有助于证明成立工作组的合理性，但这并非严格要求。同样，在提交 SEP 或其他社区提案时，鼓励但不强制要求必须来自兴趣小组或工作组的贡献。 我们强烈建议所有有兴趣针对特定 SEP 开展工作的贡献者先在兴趣小组内进行协作。这种协作过程有助于确保拟议的 SEP 符合协议需求，并且是适合其采用者的方向。

​
治理原则

所有小组在遵守以下核心原则的同时实行自治
  1. 清晰的贡献和决策流程
  2. 公开的沟通和透明的决策
两者都必须：
  • 记录其贡献流程
  • 保持透明沟通
  • 公开做出决策（小组必须发布会议记录和提案）
没有指定流程的项目和工作组默认使用：

​
维护职责

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

​
规范项目

​
规范增强提案 (SEP)

对规范的拟议变更必须以书面版本的形式提交，首先是提案摘要，概述其试图解决的问题，并提出解决方案、备选方案、考量因素、结果和风险。SEP 指南概述了 SEP 预期结构的信息。SEP 以 pull request 的形式提交到规范仓库中的 seps/ 目录。 所有提案必须有一位来自 MCP 指导小组（维护者、核心维护者或首席核心维护者）的担保人 (Sponsor)。担保人负责确保提案得到积极开发、符合提案质量标准、更新 Markdown 文件中的 SEP 状态，并在核心维护者会议上进行演示和讨论。维护者和核心维护者小组应定期审查没有担保人的开放提案。六个月内未找到担保人的提案将自动拒绝。 提案一旦获得担保人，担保人会将自己分配给该 PR，并将 SEP 状态更新为 draft（草案）。

​
沟通

​
核心维护者会议

核心维护者小组每两周开会讨论提案和项目。关于提案的说明应予以公开。核心维护者小组将力争每 3-6 个月进行一次线下会面。

​
公开聊天

MCP 项目维护一个公开的 Discord 服务器，并为兴趣小组设有开放聊天频道。MCP 项目可能为某些沟通设有私有频道。

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

​
原则

  • 模块维护者小组的成员身份是基于功绩授予个人的。这些个人需通过贡献、审查和讨论证明其在工作领域的强大专业知识，并与 MCP 的整体方向保持一致。
  • 要成为维护者小组成员，个人必须证明其与 MCP 整体原则有着强有力且持续的一致性。
  • 模块维护者或核心维护者没有任期限制
  • 如果工作组或子项目维护者在长时间内不积极参与，则采用轻量化标准将其转为“名誉 (emeritus)”状态。每个维护者小组可以根据其领域定义合适的非活跃期限。
  • 成员身份属于个人，而非公司。

​
提名与移除

  • 首席维护者负责增加和移除核心维护者。
  • 核心维护者负责增加和移除维护者。他们会考虑现有维护者的意见。
  • 如果一个拥有 2 名以上现有维护者的工作组或兴趣小组一致同意增加额外维护者（最高不超过 5 人），他们可以在无需核心维护者审查的情况下执行。

​
提名流程

如果维护者（或核心/首席维护者）希望提出一项提名供核心/首席维护者考虑，应遵循以下流程：
  1. 收集提名证据。这通常表现为在所考虑维护权责的仓库中合并 PR 的历史记录。
  2. 在相关小组的维护者之间讨论，看他们是否支持批准该提名。
  3. 私信社区管理员或核心维护者在 Discord 中创建一个私有频道，格式为 nomination-{name}-{group}。将所有核心维护者、首席维护者以及相关小组的共同维护者加入其中。
  4. 提供被提名人的背景信息。有关包含内容的建议见下文。
  5. 创建一个 Discord 投票，请核心/首席维护者对提名投 赞成/反对 票。鼓励但不强制要求达成一致共识。
  6. 在核心/首席维护者讨论和/或投票后，如果提名获得通过，拥有更新 GitHub 和 Discord 角色权限的相关成员会将获提名者添加到相应小组。提名人应在相关的 Discord 频道中宣布新的维护者身份。
  7. 临时 Discord 频道将在一周后删除。
在提名某人时建议向核心维护者分享的信息类型：
  • GitHub 个人主页链接、LinkedIn 个人主页链接、Discord 用户名
  • 您提名该个人担任哪个/哪些小组的维护者
  • 该小组是否同意应提升此人为维护者
  • 其迄今为止的贡献描述（包括最实质性贡献的链接）
  • 未来预期贡献的描述（例如：他们是否渴望成为维护者？他们是否有精力这样做？）
  • 关于个人的其他背景信息（例如：当前雇主、参与 MCP 的动机）
  • 您认为与提名相关的任何其他需要考虑的事项

​
当前核心维护者

  • Peter Alexander
  • Caitie McCaffrey
  • Kurtis Van Gent
  • Paul Carleton
  • Nick Cooper
  • Nick Aldridge
  • Che Liu
  • Den Delimarsky

​
当前维护者与工作组

请参阅 维护者列表。