> ## Documentation Index
> Fetch the complete documentation index at: https://modelcontextprotocol.io/llms.txt
> Use this file to discover all available pages before exploring further.
# SEP-2149: MCP Group Governance and Charter Template
> MCP Group Governance and Charter Template
Final
Process
| Field | Value |
| ------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| **SEP** | 2149 |
| **Title** | MCP Group Governance and Charter Template |
| **Status** | Final |
| **Type** | Process |
| **Created** | 2025-01-15 |
| **Author(s)** | David Soria Parra ([@dsp-ant](https://github.com/dsp-ant)), Sarah Novotny ([@sarahnovotny](https://github.com/sarahnovotny)) |
| **Sponsor** | David Soria Parra ([@dsp-ant](https://github.com/dsp-ant)) |
| **PR** | [#2149](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2149) |
***
## Abstract
This SEP establishes governance rules and a standardized charter template for MCP's two collaborative group types: **Working Groups (WGs)** and **Interest Groups (IGs)**. Working Groups produce concrete deliverables — SEPs, implementations, and code. Interest Groups facilitate discussion and knowledge-sharing to identify problems and gather requirements. The governance rules define the requirements that all groups must follow, with lighter expectations for IGs where appropriate. The charter template defines the structure each group uses to document its specific mission, scope, leadership, and work. Together they address community feedback about unclear authority delegation and inconsistent processes across groups.
This SEP is a companion to [SEP-2148: MCP Contributor Ladder](./2148-contributor-ladder.md), which defines the org-wide contributor roles (Member, Maintainer, Core Maintainer, Lead Maintainer) referenced throughout this document. Group leadership roles intersect with the contributor ladder: WG Leads and IG Facilitators must hold at least Member status on the ladder, and group participation is a recognized pathway to ladder advancement.
## Motivation
Community interviews and feedback identified several challenges with the current group structure:
1. **Unclear Authority**: It's not always clear what decisions a working group can make autonomously versus what requires Core Maintainer approval. This leads to hesitation and bottlenecks.
2. **Inconsistent Decision-Making**: Different groups operate with different norms. Decisions made in one meeting may be contradicted in another, with no clear process for resolution.
3. **Participation Confusion**: Community members are uncertain about who should participate in groups, what levels of involvement exist, and how to become more involved.
4. **Scope Creep**: Without explicit boundaries, groups may gradually expand into areas owned by other groups or outside their mandate.
5. **Missing Escalation Paths**: When groups get stuck, there's no clear path to resolution, leading to prolonged disagreements or abandoned initiatives.
6. **WG/IG Distinction**: The difference between Working Groups and Interest Groups is not always clear to participants, leading to mismatched expectations about outputs and commitment.
A standardized charter template and shared governance rules address these issues by establishing consistent processes across all groups while requiring each group to explicitly define its specific scope and boundaries.
## Specification
MCP maintains two types of collaborative groups:
* **Working Groups (WGs)** produce concrete deliverables — SEPs, reference implementations, and code. Active contribution is expected.
* **Interest Groups (IGs)** facilitate discussion and knowledge-sharing around a topic area. They produce problem statements, use cases, and recommendations. Active contribution is expected.
This specification has two parts:
1. **Group Governance** — rules that apply to all MCP groups (WGs and IGs), with differences noted where applicable
2. **Charter Template** — the structure each group fills in to define its specific mission, scope, and operations
***
### Part 1: Group Governance
The following rules apply to all MCP Working Groups and Interest Groups. Individual charters cannot override these requirements. Where rules differ between WGs and IGs, this is noted explicitly.
#### 1.1 Leadership
Each group has one or more **Leads** (referred to as **Facilitators** for Interest Groups).
**Requirements for all Leads and Facilitators:**
* Hold at least Member status on the [MCP Contributor Ladder](./2148-contributor-ladder.md)
* Demonstrated sustained engagement with the group's scope area
* Ability to facilitate across organizational boundaries
* Commitment to running the group's operations
* Group and its leadership sponsored by at least two Core Maintainers or one Lead Maintainer
**Additional requirements for WG Leads:**
* Commitment to 2-3 hours/week for WG activities
#### 1.2 Leadership Responsibilities
**All Leads are responsible for:**
* Schedule and facilitate regular meetings
* Set agendas in collaboration with participants and publish them in advance
* Ensure meeting notes are published within 48 hours
* Maintain the group's documentation
* Maintain a members list and respective access list in [https://github.com/modelcontextprotocol/access](https://github.com/modelcontextprotocol/access)
* Proactively recruit and retain broad, representative membership across organizations and perspectives
**WG Leads are additionally responsible for:**
* Drive proposals through the [SEP](https://modelcontextprotocol.io/community/sep-guidelines) (Specification Enhancement Proposal) process to resolution
* Triage SEPs in the WG's scope area, including closing SEPs that do not fit the roadmap (with documented rationale; authors may appeal to Core Maintainers)
* Escalate blocked decisions to Core Maintainers with clear context
* Maintain the working group's roadmap
* Solicit feedback from one or more Core Maintainers on the general direction of the group on a continuous basis
* Provide quarterly status updates to the Community and Core Maintainer Group
#### 1.3 Participation Levels
All groups use the following participation tiers. Note that **WG Member** is a group-specific participation level distinct from the org-wide **Member** role defined in the [Contributor Ladder](./2148-contributor-ladder.md) — an individual may be a WG Member in a specific group without holding org-wide Member status, and vice versa.
| Level | Description | Privileges |
| -------------------- | ------------------------------------------------- | ------------------------------------------------------------------ |
| **Observer** | Anyone interested in following the group's work | Read access, may attend meetings, limited discussion participation |
| **Participant** | Active contributor to group discussions | Can propose agenda items, participate in async votes |
| **WG Member** | Sustained contributor with demonstrated expertise | Counted for quorum (WGs only) |
| **Lead/Facilitator** | Operational leadership of the group | Sets agenda, facilitates, escalates |
Interest Groups primarily operate with Observers, Participants, and Facilitators. IGs may adopt the WG Member tier if their work warrants formal decision-making, but are not required to.
**Becoming a WG Member (WGs, and IGs that adopt the WG Member tier):**
* Sustained participation over 3 months
* Meaningful contributions (code, spec text, reviews, or documentation)
* Nomination by existing WG Member or Lead
* No objections from Leads, Core Maintainers, or Lead Maintainers within 7 days
**WG Member Responsibilities:**
* Continue contributing in good faith
* Maintain name, organization, and Discord name in the respective group's member list
**Active vs. Emeritus:** WG Members who do not participate for 3 consecutive months are moved to emeritus status and may return by demonstrating renewed participation.
#### 1.4 Decision-Making Process
This section applies primarily to Working Groups, which make binding decisions (consensus on technical designs, spec changes, etc.). Interest Groups typically operate by rough consensus in discussions and do not make binding decisions — their output is recommendations, problem statements, and use cases. IGs that adopt the WG Member tier may use this process for internal decisions.
**WG Consensus** is achieved through the following progression. Each step is attempted before moving to the next:
**Step 1: Lazy Consensus (default)**
* Proposals announced with clear deadline (5 days minimum for minor items, 10 days for significant items)
* Silence is consent
* Any WG Member may block with documented objection
* Blocks must propose alternatives or clear criteria for resolution
* If no blocks are raised by the deadline, the proposal is accepted
**Step 2: Formal Vote (when lazy consensus is blocked)**
A formal vote is triggered when:
* A WG Member blocks during the lazy consensus period
* A Lead or three or more WG Members request a formal vote
Voting rules:
* Quorum: 50% of active WG Members
* Passage: Simple majority for routine matters; 2/3 majority for scope changes
* Core Maintainer feedback is advisory unless explicitly stated as binding
* All votes documented with rationale
**Step 3: Escalation (when voting does not resolve)**
If a vote fails to resolve the matter (no quorum, does not pass, or the result is contested), the Lead escalates to Core Maintainers following the escalation path defined below.
#### 1.5 Escalation Path
For technical and design disagreements within a group's scope, groups should resolve disagreements locally before involving Core Maintainers. For WGs, this means using the decision-making progression (lazy consensus → vote → escalation). For IGs, the Facilitator should attempt to find rough consensus before escalating.
Some disagreements are not appropriate for group-level resolution and should be escalated directly to Core Maintainers:
* Scope disputes (whether a topic falls within the group's charter)
* Authority disputes (whether the group has the right to decide a matter)
* Cross-group conflicts (disagreements spanning multiple WGs or IGs)
* Code of conduct or behavioral concerns
* Membership or participation disputes
When escalation is necessary:
1. Lead documents the decision, options considered, and points of disagreement
2. Lead presents the escalation to the Core Maintainer group with a clear ask
3. The Core Maintainer group designates a CM—who should not share organizational affiliation with the parties involved—to resolve the issue and report back to the group
4. The designated CM either: (a) provides binding guidance, (b) requests more information, or (c) recommends the full Core Maintainer group deliberate
5. Timeline: Escalations should receive initial response within 5 business days
#### 1.6 Meeting Requirements
Leads determine meeting frequency, format, and duration based on the group's current needs and lifecycle stage. There is no fixed cadence requirement — a WG near a specification release may meet weekly, while an IG in early exploration may meet monthly or work primarily asynchronously.
Regardless of format or frequency, all group meetings must:
* Be open to all community participants (no closed or organization-internal meetings)
* Be published on [meet.modelcontextprotocol.io](https://meet.modelcontextprotocol.io) at least 7 days in advance
* Have agendas published and publicly available. The agenda or a link to the agenda should be published as a [GitHub Discussion in the Meeting Notes category](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/)
* Have notes published within 48 hours to the same discussion
Leads should actively involve WG Members and Participants in operational duties such as preparing agendas, taking meeting notes, and facilitating discussions.
#### 1.7 Communication Channels
All groups use the following channels:
| Channel | Purpose | Response Expectation |
| ------------------------------------ | ------------------------------ | -------------------- |
| Discord `#{name}-wg` or `#{name}-ig` | Quick questions, coordination | Best effort |
| GitHub Discussions | Long-form technical discussion | Weekly triage |
In addition to Discord, groups can establish a discussion category in the [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/). Leads will be granted the appropriate roles to manage and moderate discussions.
#### 1.8 Reporting
**Working Groups** provide quarterly updates (end of January, April, July, October) including:
* Progress against deliverables
* Blocked items and escalations
* Membership changes
* Upcoming priorities
* Resource needs
The quarterly updates are provided as a document posted in the [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/) category of the Working Group. They are optionally discussed
with the Core Maintainers in a core maintainer meeting.
**Interest Groups** do not have formal reporting requirements but should keep their charter and member list current.
#### 1.9 Lifecycle
**Working Group Formation:**
* There must be a widely acknowledged concern requiring coordination
* PR for creation of WG into `docs/community//overview.mdx`, gated by CODEOWNERS requiring approval by Maintainers
* PR for charter into `docs/community//charter.mdx`, gated by CODEOWNERS requiring approval from Core Maintainers
* Initial member list approved by WG Lead
**Interest Group Formation:**
* Fill out the creation template in the `#wg-ig-group-creation` channel on [Discord](https://discord.gg/6CSzBmMkjX)
* A Core Maintainer reviews the proposal; the IG and its Facilitator(s) must be sponsored by at least two Core Maintainers or one Lead Maintainer
* Once sponsored, the Facilitator(s) organize the IG and create a charter
**Retirement:**
* **WGs**: WG Lead or Core Maintainer proposes retirement with rationale; Core Maintainer or Lead Maintainer approval required. WGs are also retired when they have no active work for a sustained period or have completed all planned deliverables.
* **IGs**: Core Maintainers or Lead Maintainers may retire an IG that is no longer active or needed.
* In both cases, documentation is archived and channels are marked inactive.
#### 1.10 Charter Amendments
Changes to a group's charter (WG or IG) require:
* Proposal by Lead/Facilitator or Core Maintainer
* Approval by Core Maintainers
***
### Part 2: Charter Template
Every MCP Working Group and Interest Group must maintain a charter document following this template structure. Charters are stored as MDX files at `docs/community//charter.mdx` in the modelcontextprotocol repository and added to the `docs/docs.json` file. A copyable version of this template is published at [`docs/community/charter-template.mdx`](/community/charter-template).
The charter captures information specific to each group. Governance rules from Part 1 apply automatically and do not need to be repeated in the charter. Sections marked **(WG only)** are required for Working Groups but optional for Interest Groups.
#### 1. Group Type
State whether this is a **Working Group** or an **Interest Group**.
#### 2. Mission Statement
A 2-3 sentence summary of the group's purpose, articulating:
* The problem space being addressed
* Why cross-cutting collaboration is needed
* For WGs: what concrete deliverables the group will produce
* For IGs: what discussions and knowledge-sharing the group will facilitate
*WG Example:*
> The Transport Working Group exists to evolve MCP's transport mechanisms to support diverse deployment scenarios—from local subprocess communication to horizontally-scaled cloud deployments—while maintaining protocol coherence and backward compatibility.
*IG Example:*
> The Enterprise IG explores the challenges of deploying MCP in enterprise environments, gathering use cases and requirements to inform future specification work.
#### 3. Scope
**In Scope**: Enumerated responsibilities.
For WGs, this includes:
* Specification Work: Specific spec sections or SEPs owned
* Reference Implementations: SDK components or reference implementations
* Cross-Cutting Concerns: Areas requiring coordination with other groups
* Documentation: Documentation responsibilities
For IGs, this includes:
* Topic areas for discussion
* Types of output (problem statements, use cases, recommendations)
**Out of Scope**: Explicit statements of what is NOT within the group's purview to prevent mission creep.
**Related Groups**: List of other WGs or IGs with intersecting work and nature of overlap.
#### 4. Leadership
**Leads/Facilitators** table with:
* Role, Name, Organization, GitHub handle, Term
Leadership requirements and responsibilities are defined in the governance rules (Sections 1.1 and 1.2).
#### 5. Authority & Decision Rights (WG only)
Each WG must explicitly define its decision authority. The decision-making process and escalation path are defined in the governance rules (Sections 1.4 and 1.5). This section documents which decisions the WG can make at which authority level.
*Example:*
| Decision Type | Authority Level |
| ----------------------------------- | ------------------------------------------------------ |
| Meeting logistics & scheduling | WG Leads (autonomous) |
| Proposal prioritization within WG | WG Leads (autonomous) |
| SEP triage & closure (in scope) | WG Leads (autonomous, with documented rationale) |
| Technical design within scope | WG consensus |
| Spec changes (additive) | WG consensus → Core Maintainer approval |
| Spec changes (breaking/fundamental) | WG consensus → Core Maintainer approval + wider review |
| Scope expansion | Core Maintainer approval required |
| WG Member approval | WG Member sponsors |
IGs do not make binding decisions and do not need this section.
#### 6. Membership
List current group members and their participation levels, if any. Leave out if no members exist yet.
Participation tiers and membership criteria are defined in the governance rules (Section 1.3).
#### 7. Operations
Document the group's current meeting approach. Meeting requirements and communication channels are defined in the governance rules (Sections 1.6 and 1.7).
*Example:*
| Meeting | Frequency | Duration | Purpose |
| --------------- | --------------- | -------- | ------------------------------------- |
| Working Session | Weekly/Biweekly | 60 min | Technical discussion, proposal review |
| Office Hours | Monthly | 30 min | Open Q\&A for newcomers and observers |
#### 8. Deliverables & Success Metrics (WG only)
**Active Work Items:**
| Item | Status | Target Date | Champion |
| ------------- | --------------------- | ----------- | -------- |
| SEP-XXX: Name | Draft/Review/Approved | Date | Name |
**Success Criteria:** Measurable outcomes for WG success.
Quarterly reporting requirements are defined in the governance rules (Section 1.8).
IGs do not track formal deliverables but may list current discussion topics or planned outputs (problem statements, recommendations, etc.) in their charter.
#### 9. Changelog
Track charter versions with date and changes.
## Rationale
### Why Separate Governance from Charter Template?
Separating fixed governance rules from the per-group charter template makes it clear what is consistent across all groups (decision-making, membership tiers, escalation) versus what each group defines for itself (scope, leadership roster, deliverables). This prevents groups from accidentally diverging on process while preserving flexibility where it matters.
### Why Cover Both WGs and IGs?
Working Groups and Interest Groups serve different purposes but share common operational needs — leadership, meeting requirements, communication channels, and escalation paths. A unified governance framework ensures consistency while clearly articulating where IGs have lighter requirements (no formal decision authority, no deliverables tracking, no quarterly reporting).
### Why a Standardized Template?
Standardization:
* Ensures all groups address critical governance questions
* Makes it easier for community members to understand any group's operations
* Reduces overhead for forming new groups
* Creates accountability through explicit documentation
### Why Explicit Authority Tables?
The authority table directly addresses the "unclear authority" feedback. By enumerating decision types and required approvals, WGs and community members know exactly what can be decided autonomously versus what needs escalation. IGs are exempt from this because they produce recommendations, not binding decisions.
### Why Tiered Participation?
Different engagement levels serve different community needs:
* **Observers** can learn without commitment
* **Participants** can contribute without full WG Member responsibilities
* **WG Members** take on accountability and get decision rights (primarily WGs)
* **Leads/Facilitators** provide operational continuity
### Why Lazy Consensus as Default?
Lazy consensus:
* Enables efficient decision-making for routine matters
* Reduces meeting burden
* Documents decisions through announcement/deadline structure
* Preserves blocking rights for substantive concerns
Voting is reserved for contested or high-impact decisions.
### Model Inspiration
This template is adapted from Kubernetes governance structures and tailored for MCP's specific needs identified through community interviews.
## Backward Compatibility
### Transition for Existing Groups
Working Groups and Interest Groups that exist at the time this SEP is accepted are grandfathered in — they are recognized as valid groups and do not need to re-apply through the formation process defined in Section 1.9.
However, existing groups must create a charter conforming to the template in Part 2 within **8 weeks** of this SEP's acceptance. During this transition period:
* Existing groups continue to operate under their current processes
* Leads/Facilitators are responsible for drafting the charter
* Core Maintainers will review and approve both WG and IG charters
* Groups that do not produce a charter within 8 weeks will be considered inactive and subject to retirement
## Security Implications
No direct security implications. However, clear authority delegation and decision processes indirectly support security by ensuring decisions are made at appropriate levels with proper accountability.
## Reference Implementation
This SEP is implemented by:
1. `docs/community/working-interest-groups.mdx` — governance rules (Part 1) published as the Working and Interest Groups page on modelcontextprotocol.io
2. `docs/community/charter-template.mdx` — copyable charter template (Part 2) linked from the above
3. Both pages added to `docs/docs.json` under the Community → Governance navigation group
4. Existing WGs and IGs must create conforming charters at `docs/community//charter.mdx` within 8 weeks of acceptance