Follow Discord
Sweep 10 Nov 2026 · 02:18Z Build v2.1.322 539 read Stable v2.1.311 Latest v2.1.322 Next v2.1.322 Feeds RSS JSON llms.txt llms-full.txt Unofficial
One change · mcp

Working Groups and Interest Groups changedcommunity/working-interest-groups

Nearest release: v2.1.321, published 5 hours after upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.

Upstream edited this page at 9 Nov 2026 13:29 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 9 Nov 2026 13:37 UTC.

Upstream edited
Recorded here
Lines+97added
Lines−239removed
From line 1 where the diff opens
First seen 14 Aug 2026 this site's first read of the page
Recorded edits10to this page, all time

# Working Groups and Interest Groups ## Working groups and interest groups ## Current groups ## Joining a group ## Leadership ## Participation levels ## Making decisions ## Escalation ## Meetings and channels ## Reporting ## Forming a group ### Working group ### Interest group ## Amending or retiring a group # Working and Interest Groups ## Quick Reference ## When to Use Which ## Interest Groups (IGs) ## Working Groups (WGs) ## Governance ### Leadership ### Participation Levels ### Decision-Making Process ### Escalation Path ### Meeting Requirements ### Communication Channels ### Reporting ### Lifecycle ### Charter Amendments ## Charters ## FAQ ### How do I get involved contributing to MCP? ### Where can I find a list of all current WGs and IGs? ### Do I need to join an IG before starting a WG? ### Do I need to be in a WG to submit a SEP? ### What if my IG discussion leads to a concrete solution? ### Can one person be in multiple IGs/WGs?

The whole hunk

from line 1, old and new numbered
/
lines
from line 1
1# Working and Interest Groups
1# Working Groups and Interest Groups
22 
3> Governance rules for the two forms of collaborative groups within the Model Context Protocol community — Working Groups and Interest Groups.
3> The MCP project's working groups and interest groups, how to join or start one, and the operating rules every group follows.
44 
5Within the MCP contributor community we maintain two types of collaboration formats: **Interest Groups (IGs)** and **Working Groups (WGs)**.
5This page lists the project's working groups and interest groups, explains how to join or start one, and sets the operating rules every group follows. The rules were adopted by [SEP-2149](https://modelcontextprotocol.io/seps/2149.md), a Specification Enhancement Proposal (SEP). A group's charter cannot override them, and changing them requires a Process SEP. Group membership is not required to take part in a group's work, though a [SEP](https://modelcontextprotocol.io/community/sep-guidelines.md) needs [prior discussion](https://modelcontextprotocol.io/community/sep-guidelines.md#before-you-write) with the relevant working group and its approval before the pull request is opened. You may take part in as many groups as your time allows.
66 
7## Quick Reference
7## Working groups and interest groups
88 
9| | Interest Group (IG) | Working Group (WG) |
9| | Working group | Interest group |
1010| - | - | - |
11| **Purpose** | Identify and discuss problems | Build concrete solutions |
12| **Output** | Problem statements, use cases, recommendations | SEPs, implementations, code |
13| **Commitment** | Active contribution expected | Active contribution expected |
14| **Duration** | Ongoing as long as topic is relevant | Until deliverables complete |
15| **Leadership** | Facilitator(s) | Lead(s) |
16| **Decisions** | Rough consensus, non-binding | Binding (lazy consensus → vote → escalation) |
17| **Example** | "Security in MCP" — discussing security challenges | "Server Identity" — implementing identity verification |
11| Purpose | Build a concrete solution | Identify and discuss a problem |
12| Output | SEPs, reference implementations, or stewardship of an endorsed project such as the Inspector, the Registry or an SDK | Problem statements, use cases, recommendations, and input to working groups and SEPs |
13| Decisions | Binding within scope: lazy consensus, then vote, then escalation | Non-binding, by rough consensus |
14| Led by | Leads | Facilitators |
15| Duration | Until its deliverables are complete | Ongoing while the topic is relevant |
16| Example | [Transports](https://modelcontextprotocol.io/community/working-groups/transports.md) | [Security](https://modelcontextprotocol.io/community/interest-groups/security.md) |
1817 
19## When to Use Which
18In the usual path an interest group frames a problem, and a new working group, an existing group, or a SEP submitted directly solves it.
2019 
21**Join an Interest Group when you:**
20## Current groups
2221 
23* Have a problem but aren't sure of the solution
24* Want to explore whether an idea has community support
25* Are new to MCP and want to learn about a topic area
26* Want to share use cases and requirements
22Working groups:
2723 
28**Join a Working Group when you:**
24* [MCP Apps](https://modelcontextprotocol.io/community/working-groups/apps.md)
25* [File Uploads](https://modelcontextprotocol.io/community/working-groups/file-uploads.md)
26* [Filesystems](https://modelcontextprotocol.io/community/working-groups/filesystems.md)
27* [Governance](https://modelcontextprotocol.io/community/working-groups/governance.md)
28* [Infrastructure](https://modelcontextprotocol.io/community/working-groups/infrastructure.md)
29* [Inspector V2](https://modelcontextprotocol.io/community/working-groups/inspector-v2.md)
30* [Interceptors](https://modelcontextprotocol.io/community/working-groups/interceptors.md)
31* [Progressive Disclosure](https://modelcontextprotocol.io/community/working-groups/progressive-disclosure.md)
32* [Registry](https://modelcontextprotocol.io/community/working-groups/registry.md)
33* [SDK](https://modelcontextprotocol.io/community/working-groups/sdk.md)
34* [Server Card](https://modelcontextprotocol.io/community/working-groups/server-card.md)
35* [Skills Over MCP](https://modelcontextprotocol.io/community/working-groups/skills-over-mcp.md)
36* [Tasks and Events](https://modelcontextprotocol.io/community/working-groups/tasks-events.md)
37* [Transports](https://modelcontextprotocol.io/community/working-groups/transports.md)
2938 
30* Have a specific solution to implement
31* Are ready to write code or a SEP
32* Can commit regular time to active development
33* Want to help build a particular feature
39Interest groups:
3440 
35**Typical flow**: Discuss a problem in an IG → Validate that it's worth solving → Form or join a WG to build the solution → Submit a SEP → Implement
41* [Agents](https://modelcontextprotocol.io/community/interest-groups/agents.md)
42* [Authorization](https://modelcontextprotocol.io/community/interest-groups/auth.md)
43* [Enterprise](https://modelcontextprotocol.io/community/interest-groups/enterprise.md)
44* [Enterprise-Managed Authorization](https://modelcontextprotocol.io/community/interest-groups/enterprise-managed-authorization.md)
45* [Financial Services](https://modelcontextprotocol.io/community/interest-groups/financial-services.md)
46* [Scientific Computing](https://modelcontextprotocol.io/community/interest-groups/scientific-computing.md)
47* [Security](https://modelcontextprotocol.io/community/interest-groups/security.md)
48* [Tool Annotations](https://modelcontextprotocol.io/community/interest-groups/tool-annotations.md)
3649 
37## Interest Groups (IGs)
50## Joining a group
3851 
39**Goal:** Facilitate discussion and knowledge-sharing among MCP contributors who share interests in a specific topic. The focus is on identifying problems worth solving and gathering requirements — not building solutions.
52Join the group's Discord channel, which the charter names ([Communication](https://modelcontextprotocol.io/community/communication.md#discord) gives the naming convention). Attend the group's call, listed on [meet.modelcontextprotocol.io](https://meet.modelcontextprotocol.io), and follow its agenda and notes thread (see [Meetings and channels](#meetings-and-channels)). Offering to take notes, prepare an agenda or facilitate a call is the fastest way in. Share your use cases in SEP discussions and take on working group deliverables when you are ready.
4053 
41**What IGs do:**
54To be listed as a Participant, ask a Lead. WG Member status follows the nomination process under [Participation levels](#participation-levels). Member lists live in the [access repository](https://github.com/modelcontextprotocol/access), which drives GitHub team membership and Discord roles. The [Antitrust Policy](https://modelcontextprotocol.io/community/antitrust.md) applies in every group meeting.
4255 
43* Host discussions in Discord channels
44* Run regular meetings to share use cases
45* Document problem statements and requirements
46* Build consensus on what should be prioritized
47* Provide input to Working Groups and SEPs
56## Leadership
4857 
49**Examples:**
58Each group has one or more Leads, called Facilitators in an interest group. A Lead or Facilitator must hold at least [Member](https://modelcontextprotocol.io/community/contributor-ladder.md#member) status and show sustained engagement with the group's scope. They must be able to facilitate across organizations, represent several perspectives fairly, and commit to running the group's operations; for a WG Lead that means 2 to 3 hours a week. The group and its leadership must be sponsored by at least two Core Maintainers or one Lead Maintainer.
5059 
51* Security in MCP
52* Auth in MCP
53* Using MCP in enterprise settings
54* Tooling and practices for hosting MCP clients
60Every Lead and Facilitator must:
5561 
56## Working Groups (WGs)
62* schedule and run regular meetings under [Meetings and channels](#meetings-and-channels)
63* set agendas with participants and publish them in advance
64* make sure meeting notes are published
65* keep the charter and other group documentation current
66* keep the member list and access list in the [access repository](https://github.com/modelcontextprotocol/access) current
67* recruit and retain a broad membership across organizations and perspectives
5768 
58**Goal:** Collaborate on a SEP, a series of related SEPs, or an officially endorsed project. WGs produce concrete deliverables.
69A WG Lead must also:
5970 
60**What WGs do:**
71* drive the group's proposals through the [SEP process](https://modelcontextprotocol.io/community/sep-guidelines.md) to resolution
72* triage SEPs in the group's scope and close those that do not fit the roadmap, giving written rationale on the pull request; the author may appeal to Core Maintainers
73* escalate blocked decisions to Core Maintainers with clear context
74* keep the group's roadmap (the charter's Active Work Items) current and feed it into the [project roadmap](https://modelcontextprotocol.io/development/roadmap.md)
75* regularly check the group's general direction with one or more Core Maintainers
76* post the quarterly update under [Reporting](#reporting)
6177 
62* Write and iterate on SEPs
63* Build reference implementations
64* Maintain ongoing projects (Inspector, Registry, SDKs)
65* Drive features from proposal to specification
78Leading a group does not require Maintainer status, and it counts toward advancement to [Maintainer](https://modelcontextprotocol.io/community/contributor-ladder.md#maintainer). A Lead or Facilitator who is not a Maintainer works with one for merge decisions. Lead authority covers group operations, not specification approval. A WG Lead may [sponsor SEPs](https://modelcontextprotocol.io/community/sep-guidelines.md#sponsors) within the group's scope.
6679 
67**Examples:**
80## Participation levels
6881 
69* Registry
70* Inspector
71* Tool Filtering
72* Server Identity
73 
74## Governance
75 
76The following rules apply to all MCP Working Groups and Interest Groups. Individual group charters cannot override these requirements. Where rules differ between WGs and IGs, this is noted explicitly.
77 
78### Leadership
79 
80Each group has one or more **Leads** (referred to as **Facilitators** for Interest Groups).
81 
82**Requirements for all Leads and Facilitators:**
83 
84* Hold at least Member status on the MCP Contributor Ladder — see [Governance](https://modelcontextprotocol.io/community/governance.md) for role definitions
85* Demonstrated sustained engagement with the group's scope area
86* Ability to facilitate across organizational boundaries
87* Commitment to running the group's operations
88* Group and its leadership sponsored by at least two Core Maintainers or one Lead Maintainer
89 
90**Additional requirements for WG Leads:**
91 
92* Commitment to 2-3 hours/week for WG activities
93 
94**All Leads are responsible for:**
95 
96* Schedule and facilitate regular meetings
97* Set agendas in collaboration with participants and publish them in advance
98* Ensure meeting notes are published within 48 hours
99* Maintain the group's documentation
100* Maintain a members list and respective access list in the [access repository](https://github.com/modelcontextprotocol/access)
101* Proactively recruit and retain broad, representative membership across organizations and perspectives
102 
103**WG Leads are additionally responsible for:**
104 
105* Drive proposals through the [SEP process](https://modelcontextprotocol.io/community/sep-guidelines.md) to resolution
106* 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)
107* Escalate blocked decisions to Core Maintainers with clear context
108* Maintain the working group's roadmap
109* Solicit feedback from one or more Core Maintainers on the general direction of the group on a continuous basis
110* Provide quarterly status updates to the Community and Core Maintainer Group
111 
112### Participation Levels
113 
114All groups use the following participation tiers. Note that **WG Member** is a group-specific participation level distinct from the org-wide **Member** role — an individual may be a WG Member in a specific group without holding org-wide Member status, and vice versa.
115 
11682| Level | Description | Privileges |
11783| - | - | - |
118| **Observer** | Anyone interested in following the group's work | Read access, may attend meetings, limited discussion participation |
119| **Participant** | Active contributor to group discussions | Can propose agenda items, participate in async votes |
120| **WG Member** | Sustained contributor with demonstrated expertise | Counted for quorum (WGs only) |
121| **Lead/Facilitator** | Operational leadership of the group | Sets agenda, facilitates, escalates |
84| Observer | Anyone interested in following the group's work | Read access, may attend meetings, limited discussion participation |
85| Participant | Active contributor to group discussions | Can propose agenda items, participate in async votes |
86| WG Member | Sustained contributor with demonstrated expertise | Counted for quorum (WGs only) |
87| Lead/Facilitator | Operational leadership of the group | Sets agenda, facilitates, escalates |
12288 
123Interest 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.
89WG Member is a group-level tier distinct from the project-wide [Member](https://modelcontextprotocol.io/community/contributor-ladder.md#member) role: a person may be a WG Member without holding Member status, and the reverse. Interest groups primarily operate with Observers, Participants and Facilitators, and may adopt the WG Member tier if their work warrants formal decision-making.
12490 
125**Becoming a WG Member** (WGs, and IGs that adopt the WG Member tier):
91In a working group, or an interest group that has adopted the tier, becoming a WG Member requires three things: sustained participation over 3 months with contributions of code, specification text, reviews or documentation; nomination by an existing WG Member or Lead; and no objection from the Leads, Core Maintainers or Lead Maintainers within 7 days. WG Members keep their name, organization and Discord handle current in the group's member list. A WG Member who does not participate for 3 consecutive months is moved to emeritus status and may return by demonstrating renewed participation.
12692 
127* Sustained participation over 3 months
128* Meaningful contributions (code, spec text, reviews, or documentation)
129* Nomination by existing WG Member or Lead
130* No objections from Leads, Core Maintainers, or Lead Maintainers within 7 days
93## Making decisions
13194 
132**WG Member Responsibilities:**
95Working groups make binding decisions within their scope through three steps, each attempted before the next.
13396 
134* Continue contributing in good faith
135* Maintain name, organization, and Discord name in the respective group's member list
971. Lazy consensus. A proposal is announced with a clear deadline of at least 5 days for minor items and 10 days for significant items. Silence is consent. Any WG Member may block with a documented objection, which must propose alternatives or clear criteria for resolution. If no block is raised by the deadline, the proposal is accepted.
982. Formal vote. A vote is triggered when a WG Member blocks during the lazy consensus period, or when a Lead or three or more WG Members request one. Quorum is 50% of active WG Members. Routine matters pass by simple majority and scope changes by a two-thirds majority. Core Maintainer feedback is advisory unless explicitly stated as binding. Every vote is documented with rationale.
993. Escalation. If the vote fails to resolve the matter (no quorum, no passage, or a contested result), the Lead escalates to Core Maintainers under [Escalation](#escalation).
136100 
137**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.
101Interest groups operate by rough consensus and their output is non-binding. An interest group that has adopted the WG Member tier may use these steps for internal decisions.
138102 
139### Decision-Making Process
103Each working group's charter records, in its Authority and Decision Rights table, the decisions the group takes at each level. That table is approved with the charter and changed under [Amending or retiring a group](#amending-or-retiring-a-group).
140104 
141This 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.
105## Escalation
142106 
143**WG Consensus** is achieved through the following progression. Each step is attempted before moving to the next.
107The generic escalation procedure and response-time matrix are defined in the [Contributor Ladder](https://modelcontextprotocol.io/community/contributor-ladder.md#escalation).
144108 
145**1. Lazy Consensus (default)**
109Technical and design disagreements within a group's scope are resolved in the group before Core Maintainers are involved: a working group uses [Making decisions](#making-decisions), and an interest group's Facilitator seeks rough consensus. Scope disputes (whether a topic falls within the charter), authority disputes (whether the group may decide a matter), cross-group conflicts, Code of Conduct or behavioral concerns, and membership or participation disputes should be escalated directly to Core Maintainers.
146110 
147* Proposals announced with clear deadline (5 days minimum for minor items, 10 days for significant items)
148* Silence is consent
149* Any WG Member may block with documented objection
150* Blocks must propose alternatives or clear criteria for resolution
151* If no blocks are raised by the deadline, the proposal is accepted
111When a Lead escalates, the Core Maintainer group designates one of its members, who should not share organizational affiliation with the parties involved, to resolve the issue and report back to the group. That Core Maintainer provides binding guidance, requests more information, or recommends that the full Core Maintainer group deliberate. An escalation should receive an initial response within 5 business days.
152112 
153**2. Formal Vote (when lazy consensus is blocked)**
113## Meetings and channels
154114 
155A formal vote is triggered when a WG Member blocks during the lazy consensus period, or when a Lead or three or more WG Members request one.
115Leads set each group's meeting frequency, format and duration; there is no fixed cadence. Every group meeting must:
156116 
157* Quorum: 50% of active WG Members
158* Passage: simple majority for routine matters; 2/3 majority for scope changes
159* Core Maintainer feedback is advisory unless explicitly stated as binding
160* All votes documented with rationale
117* be open to all community participants, with no closed or organization-internal meetings
118* be published on [meet.modelcontextprotocol.io](https://meet.modelcontextprotocol.io) at least 7 days in advance
119* have a public agenda; the agenda or a link to it should be posted as a [GitHub Discussion in the Meeting Notes category](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/) before the meeting
120* have its notes published to the same discussion within 48 hours
121* use the official Google Meet transcription as its only automated record; third-party AI notetakers and meeting bots are not permitted, per the [Code of Conduct](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/CODE_OF_CONDUCT.md#community-meetings)
122* run under the [Code of Conduct](https://modelcontextprotocol.io/community/policies.md#code-of-conduct) and the [Antitrust Policy](https://modelcontextprotocol.io/community/antitrust.md), whose Conduct of Meetings section requires agendas and minutes
123* link [Project Policies](https://modelcontextprotocol.io/community/policies.md) from its agenda
161124 
162**3. Escalation (when voting does not resolve)**
125Leads should involve WG Members and Participants in preparing agendas, taking notes and facilitating.
163126 
164If 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 below.
127Each group has a Discord channel (naming at [Communication](https://modelcontextprotocol.io/community/communication.md#discord)) for quick questions and coordination; responses there are best effort. Long-form technical discussion goes to [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/), which are triaged weekly, and a group may have its own Discussions category on request. Leads are granted the roles needed to manage and moderate both.
165128 
166### Escalation Path
129## Reporting
167130 
168For 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 above. For IGs, the Facilitator should attempt to find rough consensus before escalating.
131Each working group posts a quarterly update at the end of January, April, July and October as a document in its GitHub Discussions category, covering progress against deliverables, blocked items and escalations, membership changes, upcoming priorities, and resource needs. Core Maintainers may take it up at their meeting. Interest groups have no reporting requirement but should keep their charter and member list current.
169132 
170Some disagreements are not appropriate for group-level resolution and should be escalated directly to Core Maintainers:
133## Forming a group
171134 
172* Scope disputes (whether a topic falls within the group's charter)
173* Authority disputes (whether the group has the right to decide a matter)
174* Cross-group conflicts (disagreements spanning multiple WGs or IGs)
175* Code of conduct or behavioral concerns
176* Membership or participation disputes
135### Working group
177136 
178When escalation is necessary:
137A working group is formed when a widely acknowledged problem needs coordinated work. Prior discussion in an interest group helps but is not required. With a clear deliverable you may propose a working group directly. The group and its Leads need the sponsorship set out under [Leadership](#leadership); ask in the Discord channel closest to the topic or in `#wg-ig-group-creation`. Once sponsored, the proposers submit a charter as described in [Submitting a charter](https://modelcontextprotocol.io/community/charter-template.md#submitting-a-charter). The WG Lead approves the initial member list.
179138 
1801. Lead documents the decision, options considered, and points of disagreement
1812. Lead presents the escalation to the Core Maintainer group with a clear ask
1823. 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
1834. The designated CM either: (a) provides binding guidance, (b) requests more information, or (c) recommends the full Core Maintainer group deliberate
1845. Timeline: escalations should receive initial response within 5 business days
139### Interest group
185140 
186### Meeting Requirements
141Fill out the creation template in the `#wg-ig-group-creation` channel on [Discord](https://discord.gg/6CSzBmMkjX). A Core Maintainer reviews the proposal, and the group and its Facilitators need the same sponsorship. Once sponsored, the Facilitators organize the group and submit a charter the same way, with the file under `docs/community/interest-groups/`.
187142 
188Leads 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.
143## Amending or retiring a group
189144 
190Regardless of format or frequency, all group meetings must:
145A change to a group's charter is proposed by a Lead, a Facilitator or a Core Maintainer, approved by Core Maintainers, and recorded in the charter's Changelog.
191146 
192* Be open to all community participants (no closed or organization-internal meetings)
193* Be published on [meet.modelcontextprotocol.io](https://meet.modelcontextprotocol.io) at least 7 days in advance
194* 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/)
195* Have notes published within 48 hours to the same discussion
196* Use the official Google Meet transcription as the only automated record of the meeting. Third-party AI notetakers and meeting bots are not permitted, per the [Code of Conduct](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/CODE_OF_CONDUCT.md#community-meetings)
147A working group is retired when its Lead or a Core Maintainer proposes retirement with rationale and a Core Maintainer or Lead Maintainer approves. It is also retired when it has completed all planned deliverables or has had no active work for a sustained period. Core Maintainers or Lead Maintainers may retire an interest group that is no longer active or needed.
197148 
198Leads should actively involve WG Members and Participants in operational duties such as preparing agendas, taking meeting notes, and facilitating discussions.
199 
200### Communication Channels
201 
202All groups use the following channels:
203 
204| Channel | Purpose | Response Expectation |
205| - | - | - |
206| Discord `#{name}-wg` or `#{name}-ig` | Quick questions, coordination | Best effort |
207| GitHub Discussions | Long-form technical discussion | Weekly triage |
208 
209In addition to Discord, groups can establish a discussion category in [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/). Leads will be granted the appropriate roles to manage and moderate discussions.
210 
211### Reporting
212 
213**Working Groups** provide quarterly updates (end of January, April, July, October) including:
214 
215* Progress against deliverables
216* Blocked items and escalations
217* Membership changes
218* Upcoming priorities
219* Resource needs
220 
221The 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.
222 
223**Interest Groups** do not have formal reporting requirements but should keep their charter and member list current.
224 
225### Lifecycle
226 
227**Working Group Formation:**
228 
229* There must be a widely acknowledged concern requiring coordination
230* PR adding the WG charter as `docs/community/working-groups/<name>.mdx`, written from the [Group Charter Template](https://modelcontextprotocol.io/community/charter-template.md) and including the corresponding navigation entry in `docs/docs.json`, gated by CODEOWNERS requiring approval from Core Maintainers
231* Initial member list approved by WG Lead
232 
233**Interest Group Formation:**
234 
235* Fill out the creation template in the `#wg-ig-group-creation` channel on [Discord](https://discord.gg/6CSzBmMkjX)
236* 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
237* Once sponsored, the Facilitator(s) organize the IG and create a charter via a PR adding `docs/community/interest-groups/<name>.mdx`, written from the same template and including the corresponding navigation entry in `docs/docs.json`, gated by CODEOWNERS requiring approval from Core Maintainers
238 
239**Retirement:**
240 
241* **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.
242* **IGs**: Core Maintainers or Lead Maintainers may retire an IG that is no longer active or needed.
243* In both cases, documentation is archived and channels are marked inactive.
244 
245### Charter Amendments
246 
247Changes to a group's charter (WG or IG) require:
248 
249* Proposal by Lead/Facilitator or Core Maintainer
250* Approval by Core Maintainers
251 
252## Charters
253 
254Every MCP Working Group and Interest Group must maintain a charter document that captures its specific mission, scope, leadership, membership, and operations. The governance rules above apply automatically and do not need to be repeated in the charter.
255 
256See the [Group Charter Template](https://modelcontextprotocol.io/community/charter-template.md) for the required structure and a copyable template.
257 
258## FAQ
259 
260### How do I get involved contributing to MCP?
261 
262These groups provide an on-ramp:
263 
2641. [Join Discord](https://discord.gg/6CSzBmMkjX) and follow IGs relevant to you. Attend [live calls](https://meet.modelcontextprotocol.io/). Participate in discussions.
2652. Offer to help with operational duties — facilitating calls, preparing agendas, taking notes. Share your use cases in SEP discussions.
2663. When ready for hands-on work, contribute to WG deliverables.
2674. Sustained contribution is a recognized pathway to WG Member status and contributor ladder advancement.
268 
269### Where can I find a list of all current WGs and IGs?
270 
271On the [MCP Contributor Discord](https://discord.gg/6CSzBmMkjX), there is a section of channels for each Working and Interest Group. Chartered groups also have documentation under `docs/community/` in the [modelcontextprotocol repository](https://github.com/modelcontextprotocol/modelcontextprotocol).
272 
273### Do I need to join an IG before starting a WG?
274 
275No. IG participation can help validate ideas and build support, but it's not required. You can propose a WG directly if you have a clear deliverable in mind and can secure Core Maintainer sponsorship.
276 
277### Do I need to be in a WG to submit a SEP?
278 
279No. Anyone can submit a SEP, and group membership is not required. The proposal must still be brought to the relevant group's Discord channel before the SEP pull request is opened, as described in the [SEP guidelines](https://modelcontextprotocol.io/community/sep-guidelines.md#step-by-step-process). Beyond that requirement, closer WG collaboration can strengthen your proposal and help it find a sponsor.
280 
281### What if my IG discussion leads to a concrete solution?
282 
283You can either:
284 
285* Form a new WG to build the solution
286* Join an existing WG if one covers the area
287* Submit a SEP directly if the solution is well-defined
288 
289### Can one person be in multiple IGs/WGs?
290 
291Yes. Participate in as many groups as your time allows.
149In both cases the group's documentation is archived and its channels are marked inactive.
292150 
Feedback