技术治理
MCP 项目采用类似 Python、PyTorch 等开源项目的层级结构：- 一群贡献者提交 issue、发起 Pull Request 并为项目做出贡献。
- 一小部分维护者推动 MCP 项目中的各个组件，如 SDK、文档等。
- 贡献者和维护者由核心维护者监督，后者主导整个项目方向。
- 核心维护者中有两名首席核心维护者，作为最终决策者。
- 维护者、核心维护者与首席核心维护者共同组成MCP 指导小组。
沟通渠道
技术治理通过所有维护者、核心维护者及首席维护者共用的 Discord 服务器 进行。各维护者小组可选择额外沟通渠道，但所有决策及其支撑讨论必须记录并在 Discord 服务器上透明公开。维护者
维护者负责 MCP 项目中的单个项目或技术工作组。通常是独立仓库，如语言专属 SDK，也可延伸到仓库子目录，如 MCP 文档。维护者可自行制定决策规则与流程。维护者应独立为其项目做决策，必要时可递延或上报至核心维护者。 维护者负责：- 与社区贡献者进行周到且富有成效的互动；
- 维护并改进其在 MCP 项目中的相应领域；
- 支持文档、路线图及 MCP 项目的其他相邻部分；
- 向核心维护者呈现社区的想法。
核心维护者
核心维护者需对模型上下文协议及其规范有深入理解。其职责包括：- 设计、审查并引导 MCP 规范及 MCP 项目其他部分（如文档）的演进；
- 为项目阐明统一的长期愿景；
- 公平透明地调解并解决争议，尽可能寻求共识，必要时果断决策；
- 任命或移除维护者；
- 以 MCP 的最大利益托管 MCP 项目。
首席维护者（BDFL）
MCP 设有两名首席维护者：Justin Spahr-Summers 和 David Soria Parra。首席维护者可否决核心维护者或维护者的任何决策。此模式在开源社区中通常被称为终身仁慈独裁者（BDFL）。首席维护者应公开阐明其决策过程，并为决策提供清晰理由。首席维护者是核心维护者小组的成员。 首席维护者负责确认或移除核心维护者。 首席维护者在可行范围内是所有 MCP 项目基础设施的管理员，包括但不限于所有沟通渠道、GitHub 组织及仓库。决策流程
核心维护者小组每两周召开一次会议，讨论并投票表决提案，以及讨论任何必要议题。如有需要，可在共用 Discord 服务器上讨论并投票较小提案。 首席维护者、核心维护者及维护者小组应每三至六个月尝试线下会面一次。流程
核心维护者与首席维护者负责模型上下文协议的所有方面，包括文档、issue、内容建议及 MCP 项目 下的所有其他部分。维护者负责其领域内 MCP 项目的文档、issue 和内容建议，但鼓励参与 MCP 项目的整体维护。维护者、核心维护者及首席维护者应像外部贡献者一样使用相同的贡献流程，而非直接更改仓库。这有助于了解意图并提供讨论机会。项目与工作组
MCP 项目分为两大结构：项目和工作组。 项目是独立仓库中维护的具体组件，包括规范、TypeScript SDK、Go SDK、Inspector 及其他实现产物。 工作组是协作论坛，感兴趣方可在此讨论 MCP 的特定方面，而不维护代码仓库，包括专注传输协议、客户端实现及其他跨领域问题的组。治理原则
所有项目与工作组在遵循以下核心原则的前提下自主治理：- 清晰的贡献与决策流程
- 开放沟通与透明决策
- 记录其贡献流程
- 保持透明沟通
- 公开决策（工作组必须发布会议记录与提案）
- GitHub Pull Request 与 issue 作为贡献方式
- 官方 MCP 贡献者 Discord 中的公开频道
维护职责
无专属维护者的组件（如文档）由核心维护者负责。这些组件通过 Pull Request 遵循标准贡献指南，维护者负责审查，重大变更需提交核心维护者审查。 鼓励核心维护者与维护者改进 MCP 项目的任何部分，无论是否有正式维护指派。规范项目
规范增强提案（SEP）
对规范的更改必须以书面形式提出，首先概述提案摘要，说明要解决的问题、提出的解决方案、替代方案、考量、结果及风险。SEP 指南 概述了 SEP 的预期结构。SEP 应作为 issue 创建在 规范仓库 中，并打上proposal, sep 标签。
所有提案必须由 MCP 指导小组（维护者、核心维护者或首席核心维护者）中的一名赞助人支持。赞助人负责确保提案得到积极开发，符合提案质量标准，并在核心维护者会议中负责展示与讨论。维护者与核心维护者小组应定期审查无赞助人的公开提案。六个月内未找到赞助人的提案将自动被拒绝。
一旦提案获得赞助人，将分配给该赞助人并打上 draft 标签。
沟通
核心维护者会议
核心维护者小组每两周召开一次会议讨论提案及项目。提案记录应公开。核心维护者小组将尽力每 3-6 个月线下会面一次。公开聊天
MCP 项目维护一个 公开 Discord 服务器，为兴趣小组提供公开聊天。MCP 项目可能设有某些私人频道用于特定沟通。维护者提名、确认与移除
原则
- 模块维护者小组成员资格授予在个人层面，基于其在贡献、审查与讨论中展现的对其工作领域的深厚专业知识，并与整体 MCP 方向保持一致。
- 要加入维护者小组，个人需展现对整体 MCP 原则的持续且强烈的认同。
- 模块维护者或核心维护者无任期限制。
- 若工作组成员长期不活跃，可将工作小组或子项目维护者移至“名誉”状态，标准宽松。各维护者小组可定义适合其领域的不活跃期限。
- 成员资格授予个人，而非公司。
提名与移除
- 核心维护者负责新增和移除维护者，他们会充分考虑现有维护者的意见。
- 首席维护者负责新增和移除核心维护者。
提名流程
如果一位维护者（或核心/首席维护者）希望向核心/首席维护者提出提名，应按以下流程操作：- 收集提名证据。通常表现为在被考虑维护权的仓库中已合并 PR 的历史记录。
- 与相关组的维护者讨论，征求他们是否支持批准该提名。
- 私信社区版主或核心维护者，在 Discord 创建一个私密频道，格式为
nomination-{name}-{group}。添加所有核心维护者、首席维护者以及该相关组的共同维护者。 - 为被提名人提供背景信息。下文给出了可包含内容的建议。
- 创建一个 Discord 投票，请核心/首席维护者对提名投赞成或反对。鼓励达成共识，但非强制。
- 核心/首席维护者讨论和/或投票后，若提名获得通过，具有权限的相关成员将更新 GitHub 和 Discord 角色，把被提名人加入相应组。提名者应在相关 Discord 频道宣布新的维护者身份。
- 一周后，临时 Discord 频道将被删除。
- GitHub 个人资料链接、LinkedIn 个人资料链接、Discord 用户名
- 拟提名该人担任维护者的组别
- 该组是否一致同意将其提升为维护者
- 迄今为止的贡献描述（包括最重要的贡献链接）
- 对未来贡献的预期（例如：他们是否渴望成为维护者？是否有时间精力？）
- 关于该人的其他背景（如当前雇主、参与 MCP 的动机）
- 你认为与提名相关的其他信息
当前核心维护者
- Inna Harper
- Basil Hosmer
- Paul Carleton
- Nick Cooper
- Nick Aldridge
- Che Liu
- Den Delimarsky