Skip to main content
模型上下文协议 (MCP) 遵循正式的治理模型，以确保透明的决策制定和社区参与。本文档概述了项目的组织方式以及决策的制定方式。

​
技术治理

MCP 项目采用分层结构，类似于 Python、PyTorch 和其他开源项目：
  • 贡献者社区，他们提交问题、创建拉取请求并为项目做出贡献。
  • 一小组维护者驱动 MCP 项目内的组件，例如 SDK、文档等。
  • 贡献者和维护者由核心维护者监督，他们驱动整体项目方向。
  • 核心维护者有两位首席核心维护者，他们是包罗万象的决策制定者。
  • 维护者、核心维护者和首席核心维护者组成MCP 指导小组。
所有维护者都应强烈倾向于 MCP 的设计理念。技术治理过程中的成员资格是针对个人的，而不是公司的。也就是说，没有为特定公司保留席位，成员资格与个人相关联，而不是雇用该人的公司。这确保维护者为协议本身和开源社区的最佳利益行事。

​
渠道

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

​
维护者

维护者负责 MCP 项目内的工作组或兴趣小组。这些通常是独立的仓库，例如特定语言的 SDK，但也可以扩展到仓库的子目录，例如 MCP 文档。维护者可以采用自己的规则和程序来做出决策。维护者应独立为各自项目做出决策，但可在需要时推迟或升级到核心维护者。 维护者负责：
  • 与社区贡献者进行深思熟虑和富有成效的互动，
  • 维护和改进 MCP 项目的各自领域，
  • 支持文档、路线图和其他 MCP 项目的相邻部分，
  • 将社区想法呈现给核心。
维护者应在需要时提出额外维护者。维护者只能由核心维护者或首席核心维护者随时任命和移除，无需理由。 维护者对各自仓库拥有写入和/或管理员访问权限。

​
核心维护者

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

​
首席维护者 (BDFL)

MCP 有两位首席维护者：Justin Spahr-Summers 和 David Soria Parra。首席维护者可以否决核心维护者或维护者的任何决策。这种模型在开源社区中也常称为仁慈独裁者终身 (BDFL)。首席维护者应公开阐明他们的决策制定，并为他们的决策提供清晰理由。首席维护者是核心维护者小组的一部分。 首席维护者负责确认或移除核心维护者。 首席维护者尽可能成为 MCP 项目所有基础设施的管理员。这包括但不限于所有沟通渠道、GitHub 组织和仓库。

​
决策流程

核心维护者小组每两周开会讨论和投票提案，以及讨论任何需要的主题。如有需要，可以使用共享的 Discord 服务器讨论和投票较小的提案。 首席维护者、核心维护者和维护者小组应尝试每三到六个月面对面开会。

​
流程

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

​
工作组和兴趣小组

MCP 协作和贡献围绕两个结构组织：工作组和兴趣小组。 兴趣小组负责识别和阐明 MCP 应解决的问题，主要通过促进社区内的开放讨论。相比之下，工作组专注于通过协作生产可交付成果来开发具体解决方案，例如 SEP 或规范的社区所有实现。虽然兴趣小组的输入可以帮助证明形成工作组的合理性，但这不是严格要求。同样，在提交 SEP 或其他社区提案时，鼓励但不强制来自兴趣小组或工作组的贡献。 我们强烈鼓励所有对特定 SEP 感兴趣的贡献者首先在兴趣小组内协作。这种协作过程有助于确保提议的 SEP 与协议需求一致，并为其采用者指明正确方向。

​
治理原则

所有小组在遵守这些核心原则的同时自我治理：
  1. 明确的贡献和决策制定流程
  2. 开放沟通和透明决策
两者都必须：
  • 记录他们的贡献流程
  • 维护透明沟通
  • 公开做出决策（小组必须发布会议记录和提案）
没有指定流程的项目和工作组默认为：

​
维护职责

没有专用维护者的组件（例如文档）属于核心维护者责任。这些遵循通过拉取请求的标准贡献指南，维护者处理审查，并将任何重大变更升级到核心维护者审查。 核心维护者和维护者应改进 MCP 项目的任何部分，无论正式维护分配如何。

​
规范项目

​
规范增强提案 (SEP)

对规范的提议变更必须以书面形式提出，首先是提案摘要，概述它试图解决的问题，提出解决方案、替代方案、考虑因素、结果和风险。SEP 指南 概述了 SEP 的预期结构信息。SEP 应在规范仓库中作为问题创建，并标有标签 proposal, sep。 所有提案必须有来自 MCP 指导小组（维护者、核心维护者或首席核心维护者）的赞助者。赞助者负责确保提案积极开发，满足提案质量标准，并负责在核心维护者会议中提出和讨论它。维护者和核心维护者小组应定期审查没有赞助者的开放提案。六个月内未找到赞助者的提案自动被拒绝。 一旦提案有赞助者，它们被分配给赞助者并标有 draft。

​
沟通

​
核心维护者会议

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

​
公共聊天

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

​
提名、确认和移除维护者

​
原则

  • 模块维护者小组的成员资格基于功绩给予个人，在他们通过贡献、审查和讨论展示了其工作领域的强大专业知识后，并与整体 MCP 方向一致。
  • 对于维护者小组的成员资格，个人必须展示与整体 MCP 原则的强大和持续一致性。
  • 模块维护者或核心维护者没有任期限制
  • 如果他们长期不积极参与，轻度标准将工作组或子项目维护移至”名誉”状态。每个维护者小组可以为其领域定义适当的不活跃期。
  • 成员资格是针对个人的，而不是公司。

​
提名和移除

  • 核心维护者负责添加和移除维护者。他们将考虑现有维护者的意见。
  • 首席维护者负责添加和移除核心维护者。

​
提名流程

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

​
当前核心维护者

  • Inna Harper
  • Basil Hosmer
  • Paul Carleton
  • Nick Cooper
  • Nick Aldridge
  • Che Liu
  • Den Delimarsky

​
当前维护者和工作组

请参阅维护者列表。