Working and Interest Groups

Within the MCP contributor community we maintain two types of collaboration formats: Interest Groups (IGs) and Working Groups (WGs).

​

Quick Reference

​

When to Use Which

Join an Interest Group when you:

• Have a problem but aren’t sure of the solution
• Want to explore whether an idea has community support
• Are new to MCP and want to learn about a topic area
• Want to share use cases and requirements

Join a Working Group when you:

• Have a specific solution to implement
• Are ready to write code or a SEP
• Can commit regular time to active development
• Want to help build a particular feature

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

​

Interest Groups (IGs)

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. What IGs do:

• Host discussions in Discord channels
• Run regular meetings to share use cases
• Document problem statements and requirements
• Build consensus on what should be prioritized
• Provide input to Working Groups and SEPs

Examples:

• Security in MCP
• Auth in MCP
• Using MCP in enterprise settings
• Tooling and practices for hosting MCP clients

​

Working Groups (WGs)

Goal: Collaborate on a SEP, a series of related SEPs, or an officially endorsed project. WGs produce concrete deliverables. What WGs do:

• Write and iterate on SEPs
• Build reference implementations
• Maintain ongoing projects (Inspector, Registry, SDKs)
• Drive features from proposal to specification

Examples:

• Registry
• Inspector
• Tool Filtering
• Server Identity

​

Governance

The 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.

​

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 — see Governance for role definitions
• 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

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 the access repository
• Proactively recruit and retain broad, representative membership across organizations and perspectives

WG Leads are additionally responsible for:

• Drive proposals through the SEP 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

​

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 — an individual may be a WG Member in a specific group without holding org-wide Member status, and vice versa. 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.

​

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.

​

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 above. 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

​

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 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
• 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.

​

Communication Channels

All groups use the following channels: In addition to Discord, groups can establish a discussion category in GitHub Discussions. Leads will be granted the appropriate roles to manage and moderate discussions.

​

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 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.

​

Lifecycle

Working Group Formation:

• There must be a widely acknowledged concern requiring coordination
• PR for creation of WG into docs/community/<name>/overview.mdx, gated by CODEOWNERS requiring approval by Maintainers
• PR for charter into docs/community/<name>/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
• 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.

​

Charter Amendments

Changes to a group’s charter (WG or IG) require:

• Proposal by Lead/Facilitator or Core Maintainer
• Approval by Core Maintainers

​

Charters

Every 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. See the Group Charter Template for the required structure and a copyable template.

​

FAQ

​

How do I get involved contributing to MCP?

These groups provide an on-ramp:

1. Join Discord and follow IGs relevant to you. Attend live calls. Participate in discussions.
2. Offer to help with operational duties — facilitating calls, preparing agendas, taking notes. Share your use cases in SEP discussions.
3. When ready for hands-on work, contribute to WG deliverables.
4. Sustained contribution is a recognized pathway to WG Member status and contributor ladder advancement.

​

Where can I find a list of all current WGs and IGs?

On the MCP Contributor Discord, there is a section of channels for each Working and Interest Group. Chartered groups also have documentation under docs/community/ in the modelcontextprotocol repository.

​

Do I need to join an IG before starting a WG?

No. 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.

​

Do I need to be in a WG to submit a SEP?

No. Anyone can submit a SEP. However, WG collaboration can strengthen your proposal and help it find a sponsor.

​

What if my IG discussion leads to a concrete solution?

You can either:

• Form a new WG to build the solution
• Join an existing WG if one covers the area
• Submit a SEP directly if the solution is well-defined

​

Can one person be in multiple IGs/WGs?

Yes. Participate in as many groups as your time allows.