SEP-1302: Formalize Working Groups and Interest Groups in MCP Governance

---

​

Abstract

A short (~200 word) description of the technical issue being addressed. In SEP-994, we introduced a notion of “Working Groups” and “Interest Groups” that facilitate MCP sub-communities for discussion and collaboration. This SEP aims to formally define those two terms: what they are meant to achieve, how groups can be created, how they are governed, and how they can be retired. Interest Groups work to define problems that MCP should solve by facilitating discussions, while Working Groups push forward specific solutions by collaboratively producing deliverables (in the form of SEPs or community-owned implementations of the specification). Interest Group input is a welcome (but not required) justification for creation of a Working Group. Interest Group or Working Group input is collectively a welcome (but not required) input into a SEP.

​

Motivation

The motivation should clearly explain why the existing protocol specification is inadequate to address the problem that the SEP solves. The community has already been self-organizing into several disparate systems for these collaborative groups:

• The Steering group has had a long-standing practice of managing a handful of collaborative groups through Discord channels (e.g. security, auth, agents). See bottom of MAINTAINERS.md.
• The “CWG Discord” has had a semi-formal process for pushing equivalent grassroots initiatives, mostly in pursuit of creating artifacts for SEP consideration (e.g. hosting, UI, tool-interfaces, search-tools)

With SEP-994 resulting in the merging of the Discord communities, we have a need to:

• Merge the existing initiatives into one unified approach, so when we reference “working group” or “interest group”, everyone knows what that means and what kind of weight the reference might carry
• Standardize a process around the creation (and eventual retirement) of such groups
• Properly distinguish between “working” and “interest” groups; the CWG experience has shown two very different motivations for starting a group worth treating with different expectations and lifecycle. Put succinctly, “interest” groups are about brainstorming possible problems, and “working” groups are about pushing forward specific solutions.

These groups exist to:

• Facilitate high signal spaces for discussion such that those opting into notifications and meetings feel most content is relevant to them and they can meaningfully contribute their experience and learn from others
• Create norms, expectations, and single points of involved leadership around making collaborative progress towards concrete deliverables that help evolve MCP

It will also form the foundation for cross-group initiatives, such as maintaining a calendar of live meetings.

​

Specification

The technical specification should describe the syntax and semantics of any new protocol feature. The specification should be detailed enough to allow competing, interoperable implementations. A PR with the changes to the specification should be provided.

​

Interest Groups (IG) [Problems]

Goal: facilitate discussion and knowledge-sharing among MCP community members with similar interests surrounding some MCP sub-topic or context. The focus is on collecting problems that may or may not be worth solving with SEPs or other community artifacts. Expectations:

• At least one substantive thread / conversation per month
• AND/OR a live meeting attended by 3+ unaffiliated individuals

Examples:

• Security in MCP (currently: #security)
• Auth in MCP (currently: #auth)
• Using MCP in an internal enterprise setting (currently: #enterprise-wg)
• Tooling and practices surrounding hosting MCP servers (currently: #hosting-wg)
• Tooling and practices surrounding implementing MCP clients (currently: #client-implementors)

Lifecycle:

• Creation begins by filling out a template in #wg-ig-group-creation Discord channel
• A community moderator will review and call for a vote in the (private) #community-moderators Discord channel. Majority positive vote by members over a 72h period approves creation of the group. Can be reversed at any time (e.g. after more input comes in). Core and lead maintainers can veto.
• Facilitator(s) and Maintainer(s) responsible for organizing IG into meeting expectations
  • Facilitator is an informal role responsible for shepherding or speaking for a group
  • Maintainer is an official representative from the MCP steering group (not required for every group to have this)
• IG is retired only when community moderators or core+ maintainers decide it is not meeting expectations
  • This means successful IG’s will live on in perpetuity

Creation Template:

• Facilitator(s)
• Maintainer(s) (optional)
• Flag potential overlap with other IG’s
• How this IG differentiates itself from the related IG’s
• First topic you want to discuss

There is no requirement to be part of an IG to start a WG, or even to start a SEP. However, forming consensus in IG’s to support justifying the creation of a WG is often a good idea. Similarly, citing IG or WG support of a SEP helps the SEP as well.

​

Working Groups (WG) [Solutions]

Goal: facilitate MCP community collaboration on a specific SEP, themed series of SEPs, or officially endorsed Project. Expectations:

• Minimum monthly progress towards at least one SEP or spec-related implementation OR holds maintenance responsibilities for a Project
• Facilitator(s) is/are responsible for fielding status update requests by community moderators or maintainers

Examples:

• Registry
• Inspector
• Tool Filtering
• Server Identity

Lifecycle:

• Creation begins by filling out a template in #wg-ig-group-creation Discord channel
• A community moderator will review and call for a vote in the (private) #community-moderators Discord channel. Majority positive vote by members over a 72h period approves creation of the group. Can be reversed at any time (e.g. after more input comes in). Core and lead maintainers can veto.
• Facilitator(s) and Maintainer(s) responsible for organizing WG into meeting expectations
  • Facilitator is an informal role responsible for shepherding or speaking for a group
  • Maintainer is an official representative from the MCP steering group (not required for every group to have this)
• WG is retired when either:
  • Community moderators or core+ maintainers decide it is not meeting expectations
  • The WG does not have a WIP Issue/PR for at least a month, or has completed all Issues/PRs it intends to pursue.

Creation Template:

• Facilitator(s)
• Maintainer(s) (optional)
• Explanation of interest/use cases (ideally from an IG but can come from anywhere)
• First Issue/PR/SEP you intend to procure

​

WG/IG Facilitators

A “Facilitator” role in a WG or IG does not result in a maintainership role across the MCP organization. It is an informal role into which anyone can self-nominate, responsible for helping shepherd discussions and collaboration within the group. Core Maintainers reserve the right to modify the list of Facilitators and Maintainers for any WG/IG at any time. PR for the changes to our documentation we’d want to enact this SEP: https://github.com/modelcontextprotocol/modelcontextprotocol/pull/1350

​

Rationale

The rationale explains why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. The design above comes from experience in facilitating the creation of + observing the behavior of informal “Community Working Groups” in the CWG Discord, and leading one of / participating in / observing the “Steering Committee Working Groups”. While the Steering WG’s were usually informally created by Lead Maintainers, the CWG Discord had a lightweight WG-creation process that involved similar steps to the proposal above (community members would propose WG’s in #working-group-ideation, and moderators would create channels from that collaboration). As precedent, the WG and IG concepts here are similar to W3C’s notion of Working Groups and Interest Groups.

​

Considerations

In proposing the WG/IG design, we took the following into consideration:

​

Clear on-ramp for community involvement

A very common question for folks looking to invest in the MCP ecosystem is, “how do I get involved?” These IG and WG abstractions help provide an elegant on-ramp:

1. Join the Discord, follow the conversation in IGs relevant to you. Attend live calls. Participate.
2. Offer to facilitate calls. Contribute your use cases in SEP proposals and other work.
3. When you’re comfortable contributing to deliverables, jump in to contribute to WG work.
4. Do this for a period of time, get noticed by WG maintainers to get nominated as a new maintainer.

​

Minimal changes to existing governance structure

We did not want this change to introduce new elections, appointments, or other notions of leadership. We leverage community moderators to thumbs-up creation of new groups, allow core maintainers to veto, maintainership status stays unchanged, and the notion of “facilitator” is new but self-nominated, so does not introduce any new governance processes.

​

Alignment with current status quo

There is a clear “migration” path for the existing “CWG” working groups and Steering working groups - just a matter of sorting out what is “working” vs. “interest”, but functionally this proposal stays out of the way of changing anything that has been working within each group’s existing structure.

​

Nature of requests for gathering spaces

It has been clear from the requests to CWG that some groups form with a motivation to collaborate on some deliverable (e.g. search-tools), and others form due to common interests and a want for sub-community but not yet specific deliverables (e.g. enterprise). Hence, we separate the motivations into Working Groups vs. Interest Groups.

​

Potential for overlap in scope

In the requests for new group spaces, it is sometimes non-obvious why a new one needs to exist. For example, the stated motivation for enterprise at times sounded like it may just be another flavor of hosting. We ultimately settled on a distinction that made it clear one was not a direct subset of the other, but the concern of making clear boundaries between groups (and letting community moderators / maintainers centralize the decision-making around “what are the right layers of abstraction”) is what led to the questions in the creation templates around e.g. “flag potential overlap with other IG’s”.

​

Path to retiring stale groups

Many working groups in the old CWG and Steering models have gone stale since creation. They serve no real purpose and should be retired. For this, we introduce the formal concept of facilitators and optional maintainers in groups; and the community moderator right to retire them. By having at least informal leadership in place per group, a moderator can easily make the decision to retire a group if everyone is in agreement to proceed.

​

Alternatives Considered

​

Hierarchy between IGs and WGs

We considered requiring that WGs be owned or spawned by a “sponsor” IG, for the purpose of more clearly exhibiting a progression of ideas to the community; but decided against this requiring to avoid adding a new layer of governance and alignment with how the less formal groups works today.

​

A single WG concept (instead of both WG and IG)

There has been regular tension in both CWG and the Steering group around the question of “is XYZ really a working group? how will maintainership work?” By making IG’s explicitly discussion-oriented and maintainership involvement optional, we create a space to drive those discussions without requiring some formal expectation of deliverables like we might in a well-defined WG.

​

Free-for-all WG/IG creation process

While very community-driven, the concern of group overlap would quickly fragment the conversations and collaboration to an untenable level; we need a centralized point of discernment here.

​

Backward Compatibility

All SEPs that introduce backward incompatibilities must include a section describing these incompatibilities and their severity. The SEP must explain how the author proposes to deal with these incompatibilities. There is no major change suggested in the day to day of existing groups - the expectations laid out of IGs and WGs are easily met by existing active groups as long as they keep doing as they are doing. A migration path for all groups is laid out below.

​

Reference Implementation

The reference implementation must be completed before any SEP is given status “Final”, but it need not be completed before the SEP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of “rough consensus and running code” is still useful when it comes to resolving many discussions of protocol details. The below is the suggested migration path for each group. “Migration” just involves acknowledgement of this SEP and the expectations of each group, plus methodology for possible eventual retirement (or immediate retirement, in some cases). After this SEP is approved, we can ping each of the groups to confirm they are on board with the migration plan.

​

Steering Working Groups

• All official SDK groups —> Working Groups
• Registry —> Working Group
• Documentation —> Working Group
• Inspector —> Working Group
• Auth —> Interest Group + some WGs: client-registration, improve-devx, profiles, tool-scopes
• Agents —> Working Group [Long Running / Async Tool Calls; unless we want an Agents IG on top of that?]
• Connection Lifetime —> Retire
• Streaming —> Retire
• Spec Compliance —> Retire (good idea but stale; would be good for someone to spearhead a new Working Group)
• Security —> Interest Group (perhaps with Security Best Practices WG?)
• Transports —> Interest Group
• Server Identity —> Working Group
• Governance —> Working Group (or Retire if no more work here?)

​

Community Working Groups

• agent-comms —> Retire
• enterprise —> Interest Group (request a proposal to start)
• hosting —> Interest Group (request a proposal to start)
• load-balancing —> Retire
• model-awareness —> Working Group (request a proposal to start)
• search-tools (tool-filtering) —> Working Group
• server-identity —> merge with Steering equivalent
• security —> merge with Steering equivalent
• server-identity —> merge with Steering equivalent
• tool-interfaces —> Retire
• ui —> Interest Group
• schema-validation —> Retire (same as Steering equivalent)