速查
何时使用哪一种
在以下情况加入兴趣组：- 你有一个问题，但不确定解决方案
- 你想探索某个想法是否有社区支持
- 你是 MCP 新人，想了解某个主题领域
- 你想分享用例和需求
- 你有一个具体的解决方案要实现
- 你已准备好编写代码或 SEP
- 你能定期投入时间进行积极开发
- 你想帮助构建某个特定特性
兴趣组（IG）
目标： 促进对某个特定主题有共同兴趣的 MCP 贡献者之间的讨论和知识分享。焦点在于识别值得解决的问题并收集需求——而非构建解决方案。 IG 做什么：- 在 Discord 频道主持讨论
- 举行例会以分享用例
- 记录问题陈述和需求
- 就应优先处理什么构建共识
- 为工作组和 SEP 提供输入
- MCP 中的安全
- MCP 中的授权
- 在企业环境中使用 MCP
- 托管 MCP 客户端的工具和实践
工作组（WG）
目标： 就一个 SEP、一系列相关 SEP，或一个官方认可的项目进行协作。WG 产出具体的交付物。 WG 做什么：- 编写并迭代 SEP
- 构建参考实现
- 维护进行中的项目（Inspector、Registry、SDK）
- 推动特性从提案走向规范
- Registry
- Inspector
- 工具过滤（Tool Filtering）
- 服务器身份（Server Identity）
治理
以下规则适用于所有 MCP 工作组和兴趣组。个别群组的章程不能覆盖这些要求。凡 WG 与 IG 之间规则不同之处，均明确注明。领导层
每个群组有一位或多位 Lead（对兴趣组称为 Facilitator/主持人）。 对所有 Lead 和 Facilitator 的要求：- 在 MCP 贡献者阶梯上至少持有成员（Member）身份——角色定义见治理
- 已展现出对该群组范围领域的持续投入
- 有能力跨组织边界进行主持
- 承诺运营该群组的日常事务
- 群组及其领导层由至少两位核心维护者或一位首席维护者担保
- 承诺每周为 WG 活动投入 2-3 小时
- 安排并主持例会
- 与参与者协作制定议程并提前发布
- 确保会议纪要在 48 小时内发布
- 维护该群组的文档
- 在访问仓库中维护一份成员列表和相应的访问列表
- 主动招募并留住跨组织、跨视角的广泛、有代表性的成员
- 通过 SEP 流程推动提案走向裁决
- 分诊该 WG 范围领域内的 SEP，包括关闭不契合路线图的 SEP（附成文理由；作者可向核心维护者申诉）
- 将受阻的决策附清晰背景上报给核心维护者
- 维护该工作组的路线图
- 持续地就该群组的总体方向征求一位或多位核心维护者的反馈
- 向社区和核心维护者群体提供季度状态更新
参与级别
所有群组使用以下参与层级。注意 WG 成员（WG Member） 是一个群组特定的参与级别，不同于组织范围的 成员（Member） 角色——一个人可以在某个特定群组中是 WG 成员，而不持有组织范围的成员身份，反之亦然。
兴趣组主要以观察者、参与者和主持人运作。如果 IG 的工作需要正式决策，可以采用 WG 成员层级，但并非必需。
成为 WG 成员（WG，以及采用 WG 成员层级的 IG）：
- 持续参与 3 个月以上
- 有意义的贡献（代码、规范文本、评审或文档）
- 由现有 WG 成员或 Lead 提名
- 7 天内 Lead、核心维护者或首席维护者无异议
- 继续本着诚意贡献
- 在相应群组的成员列表中维护姓名、组织和 Discord 名称
决策流程
本节主要适用于作出有约束力决策（技术设计共识、规范变更等）的工作组。兴趣组通常在讨论中以粗略共识运作，不作出有约束力的决策——其产出是建议、问题陈述和用例。采用 WG 成员层级的 IG 可将此流程用于内部决策。 WG 共识 通过以下递进过程达成。每一步在进入下一步之前都会先尝试。1
惰性共识（默认）
- 提案公布时附明确截止期限（次要事项至少 5 天，重大事项 10 天）
- 沉默即同意
- 任何 WG 成员可附成文异议进行阻止（block）
- 阻止必须提出替代方案或明确的解决标准
- 若截止期限前无阻止，则提案被接受
2
正式投票（当惰性共识被阻止时）
当某位 WG 成员在惰性共识期内进行阻止，或当一位 Lead 或三位及以上 WG 成员请求时，触发正式投票。
- 法定人数：活跃 WG 成员的 50%
- 通过：常规事项简单多数；范围变更三分之二多数
- 除非明确声明为有约束力，核心维护者的反馈为建议性
- 所有投票附理由记录
3
上报（当投票无法解决时）
如果投票未能解决该事项（无法定人数、未通过，或结果有争议），Lead 按下方上报路径上报给核心维护者。
上报路径
对于群组范围内的技术和设计分歧，群组应在牵涉核心维护者之前于本地解决分歧。对于 WG，这意味着使用上述决策递进过程。对于 IG，主持人应在上报之前尝试找到粗略共识。 有些分歧不适合在群组层面解决，应直接上报给核心维护者：- 范围争议（某议题是否落在该群组章程内）
- 权限争议（该群组是否有权决定某事项）
- 跨群组冲突（跨越多个 WG 或 IG 的分歧）
- 行为准则或行为相关的关切
- 成员或参与争议
- Lead 记录该决策、所考虑过的选项和分歧点
- Lead 将上报附一个清晰的诉求呈交给核心维护者群体
- 核心维护者群体指定一位 CM——其不应与涉事各方有相同的组织隶属——来解决该问题并向群组反馈
- 被指定的 CM 或者：(a) 提供有约束力的指导，(b) 请求更多信息，或 (c) 建议全体核心维护者群体审议
- 时间线：上报应在 5 个工作日内获得初步回应
会议要求
Lead 根据群组当前的需求和生命周期阶段确定会议频率、形式和时长。没有固定的节奏要求——临近规范发布的 WG 可能每周开会，而处于早期探索的 IG 可能每月开会或主要以异步方式工作。 无论形式或频率如何，所有群组会议都必须：- 向所有社区参与者开放（不得有封闭或组织内部的会议）
- 至少提前 7 天发布在 meet.modelcontextprotocol.io 上
- 有已发布且公开可用的议程。议程或其链接应作为 Meeting Notes 分类下的 GitHub Discussion 发布
- 在 48 小时内将纪要发布到同一个讨论中
沟通渠道
所有群组使用以下渠道：
除 Discord 外，群组可以在 GitHub Discussions 中建立一个讨论分类。Lead 将被授予相应角色以管理和审核讨论。
报告
工作组 提供季度更新（1 月、4 月、7 月、10 月底），包括：- 对照交付物的进展
- 受阻条目和上报
- 成员变动
- 即将到来的优先事项
- 资源需求
生命周期
工作组组建：- 必须存在一个被广泛认可、需要协调的关切
- 提交一个 PR，将 WG 章程添加为
docs/community/working-groups/<name>.mdx，依据群组章程模板撰写，并在docs/docs.json中包含相应的导航条目，由 CODEOWNERS 把关、要求核心维护者批准 - 初始成员列表由 WG Lead 批准
- 在 Discord 的
#wg-ig-group-creation频道填写创建模板 - 一位核心维护者评审该提案；IG 及其主持人必须由至少两位核心维护者或一位首席维护者担保
- 一经担保，主持人组织该 IG，并通过一个 PR 创建章程，将
docs/community/interest-groups/<name>.mdx添加进来，依据同一模板撰写，并在docs/docs.json中包含相应的导航条目，由 CODEOWNERS 把关、要求核心维护者批准
- WG：WG Lead 或核心维护者附理由提议退役；需要核心维护者或首席维护者批准。当 WG 在持续一段时间内没有活跃工作，或已完成所有计划交付物时，也会被退役。
- IG：核心维护者或首席维护者可以退役一个不再活跃或不再需要的 IG。
- 两种情况下，文档都会被归档，频道会被标记为不活跃。
章程修订
对群组章程（WG 或 IG）的更改需要：- 由 Lead/Facilitator 或核心维护者提议
- 由核心维护者批准
章程
每个 MCP 工作组和兴趣组都必须维护一份章程文档，记录其特定的使命、范围、领导层、成员和运作。上述治理规则自动适用，无需在章程中重复。 所需结构和一份可复制的模板参见群组章程模板。常见问题
我如何参与为 MCP 做贡献？
这些群组提供了一条入门通道：- 加入 Discord 并关注与你相关的 IG。参加线上会议。参与讨论。
- 主动帮忙承担运营职责——主持会议、准备议程、记录纪要。在 SEP 讨论中分享你的用例。
- 当准备好动手工作时，为 WG 交付物做贡献。
- 持续的贡献是通往 WG 成员身份和贡献者阶梯晋升的一条受认可的路径。
我在哪里能找到所有当前 WG 和 IG 的列表？
在 MCP 贡献者 Discord 上，有一个为每个工作组和兴趣组设立的频道分区。获章程认可的群组在 modelcontextprotocol 仓库的docs/community/ 下也有文档。
我需要先加入一个 IG 才能启动一个 WG 吗？
不需要。IG 参与有助于验证想法和建立支持，但并非必需。如果你心中有明确的交付物并能获得核心维护者担保，可以直接提议一个 WG。我需要身处某个 WG 才能提交 SEP 吗？
不需要。任何人都可以提交 SEP。不过，WG 协作可以强化你的提案并帮助它找到担保人。如果我的 IG 讨论引出了一个具体的解决方案怎么办？
你可以：- 组建一个新的 WG 来构建该解决方案
- 如果有覆盖该领域的现有 WG，则加入它
- 如果解决方案定义清晰，则直接提交一个 SEP