模型上下文协议 (Model Context Protocol, 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。首席维护者可以否决核心维护者或维护者的任何决定。这种模式在开源社区中通常被称为“终身仁慈独裁者”(Benevolent Dictator for Life, BDFL)。首席维护者应公开阐明其决策过程，并为其决定提供清晰的理由。首席维护者是核心维护者小组的成员。 首席维护者负责确认或移除核心维护者。 在可能的情况下，首席维护者是 MCP 项目所有基础设施的管理员。这包括但不限于所有沟通渠道、GitHub 组织和仓库。

​
决策流程

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

​
流程

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

​
项目和工作组

MCP 项目组织成两个主要结构：项目和工作组。 项目是在专用仓库中维护的具体组件。这些包括规范、TypeScript SDK、Go SDK、Inspector 和其他实现产物。 工作组是协作的论坛，相关方在此讨论 MCP 的特定方面，而无需维护代码仓库。这些包括专注于传输协议、客户端实现和其他跨领域问题的 nhóm。

​
治理原则

所有项目和工作组都实行自治，同时遵守这些核心原则：
  1. 清晰的贡献和决策流程
  2. 开放的沟通和透明的决策
两者都必须：
  • 记录其贡献流程
  • 保持透明的沟通
  • 公开做出决策（工作组必须发布会议记录和提案）
没有指定流程的项目和工作组默认采用：
  • 使用 GitHub 拉取请求和 issue 进行贡献
  • 在官方 MCP 贡献者 Discord 中设立一个公开频道

​
维护职责

没有专门维护者的组件（如文档）由核心维护者负责。这些组件遵循标准的贡献指南，通过拉取请求进行，由维护者处理审查，对于任何重大更改则上报给核心维护者审查。 鼓励核心维护者和维护者改进 MCP 项目的任何部分，无论其正式的维护任务分配如何。

​
规范项目

​
规范增强提案 (SEP)

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

​
沟通

​
核心维护者会议

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

​
公开聊天

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

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

​
原则

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

​
提名和移除

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

​
当前核心维护者

  • Inna Harper
  • Basil Hosmer
  • Paul Carleton
  • Nick Cooper
  • Nick Aldridge
  • Che Liu (刘喆)
  • Den Delimarsky

​
当前维护者和工作组

请参阅维护者列表。