Merge pull request modelcontextprotocol#1350 from tadasant/tadasant/sep-1302

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

Author: olaservo

MAINTAINERS.md

@@ -1,8 +1,8 @@
 # MCP Maintainers
 
-This document lists current maintainers and working groups in the Model Context Protocol project.
+This document lists current maintainers in the Model Context Protocol project.
 
-**Last updated:** July 23, 2025
+**Last updated:** August 17, 2025
 
 ## Lead Maintainers
 
@@ -102,33 +102,43 @@ This document lists current maintainers and working groups in the Model Context
 - [Jonathan Hefner](https://github.com/jonathanhefner)
 - [Tadas Antanavicius](https://github.com/tadasant)
 
-## Working Groups
+## Working Group & Interest Group Maintainers
 
-### Security Working Group
+[Working Groups and Interest Groups](https://modelcontextprotocol.io/community/working-interest-groups) are not required to have maintainers (they can be managed by informal facilitators), but maintainers may be appointed on an as-needed basis.
+
+### Security Interest Group
 
 - [Den Delimarsky](https://github.com/dend)
 - [Paul Carleton](https://github.com/pcarleton)
 - [Jenn Newton](https://github.com/jenn-newton)
 
-### Authorization Working Group
+### Authorization Interest Group
 
 - [Aaron Parecki](https://github.com/aaronpk)
 - [Darin McAdams](https://github.com/D-McAdams)
 - [Paul Carleton](https://github.com/pcarleton)
 
-### Client Implementor Working Group
+### Client Implementor Interest Group
 
 - [Michael Feldstein](https://github.com/msfeldstein)
 - [Harald Kirschner](https://github.com/digitarald)
 - [Connor Peet](https://github.com/connor4312)
 
-### Transports Working Group
+### Transports Interest Group
 
 - [Kurtis Van Gent](https://github.com/kurtisvg)
 - [Jonathan Hefner](https://github.com/jonathanhefner)
 - [Shaun Smith](https://github.com/evalstate)
 - [Harvey Tuch](https://github.com/htuch)
 
+### Server Identity Working Group
+
+- [Nick Cooper](https://github.com/nicknotfun)
+
+### Long-Running / Async Tool Calls Working Group
+
+- [Inna Harper](https://github.com/ihrpr)
+
 ## About This Document
 
 This document is updated by the MCP maintainers and reflects the current

docs/community/communication.mdx

@@ -30,9 +30,7 @@ The Discord server will have both public and private channels.
 - **Purpose**: Open community engagement, collaborative development, and transparent project coordination.
 - Primary use cases:
   - **Public SDK and tooling development**: All development, from ideation to release planning, happens in public channels (e.g., `#typescript-sdk-dev`, `#inspector-dev`).
-  - **Working and interest group discussions** (`#client-implementors`, `#agents-wg`, etc.)
-    - **Working Group**: Some specific goal or project in mind (such as an SDK, inspector, registry, server-identity, load-balancing, etc).
-    - **Interest Group**: An abstract gathering of folks that might raise a range of various topics. Some might get actioned on as one-offs, others might spin into Working Groups.
+  - **[Working and Interest Group](/community/working-interest-groups) discussions**
   - **Community onboarding** and contribution guidance.
   - **Community feedback** and collaborative brainstorming.
   - Public **office hours** and **maintainer availability**.

docs/community/governance.mdx

@@ -23,7 +23,7 @@ Technical Governance is facilitated through a shared [Discord server](/community
 
 ### Maintainers
 
-Maintainers are responsible for individual projects or technical working groups within the MCP project. These generally are independent repositories such as language-specific SDKs, but can also extend to subdirectories of a repository, such as the MCP documentation. Maintainers may adopt their own rules and procedures for making decisions. Maintainers are expected to make decisions for their respective projects independently, but can defer or escalate to the core maintainers when needed.
+Maintainers are responsible for [Working or Interest Groups](/community/working-interest-groups) within the MCP project. These generally are independent repositories such as language-specific SDKs, but can also extend to subdirectories of a repository, such as the MCP documentation. Maintainers may adopt their own rules and procedures for making decisions. Maintainers are expected to make decisions for their respective projects independently, but can defer or escalate to the core maintainers when needed.
 
 Maintainers are responsible for the:
 
@@ -68,17 +68,17 @@ The lead maintainer, core maintainer, and maintainer group should attempt to mee
 
 Core and lead maintainers are responsible for all aspects of Model Context Protocol, including documentation, issues, suggestions for content, and all other parts under the [MCP project](https://github.com/modelcontextprotocol). Maintainers are responsible for documentation, issues, and suggestions of content for their area of the MCP project, but are encouraged to partake in general maintenance of the MCP projects. Maintainers, core maintainers, and lead maintainers should use the same contribution process as external contributors, rather than making direct changes to repos. This provides insight into intent and opportunity for discussion.
 
-### Projects and Working Groups
+### Working and Interest Groups
 
-The MCP project is organized into two main structures: projects and working groups.
+MCP collaboration and contributions are organized around two structures: [Working Groups and Interest Groups](/community/working-interest-groups).
 
-Projects are concrete components maintained in dedicated repositories. These include the Specification, TypeScript SDK, Go SDK, Inspector, and other implementation artifacts.
+Interest Groups are responsible for identifying and articulating problems that MCP should address, primarily by facilitating open discussions within the community. In contrast, Working Groups focus on developing concrete solutions by collaboratively producing deliverables, such as SEPs or community-owned implementations of the specification. While input from Interest Groups can help justify the formation of a Working Group, it is not a strict requirement. Similarly, contributions from either Interest Groups or Working Groups are encouraged, but not mandatory, when submitting SEPs or other community proposals.
 
-Working groups are forums for collaboration where interested parties discuss specific aspects of MCP without maintaining code repositories. These include groups focused on transport protocols, client implementation, and other cross-cutting concerns.
+We strongly encourage all contributors interested in working on a specific SEP to first collaborate within an Interest Group. This collaborative process helps ensure that the proposed SEP aligns with protocol needs and is the right direction for its adopters.
 
 #### Governance Principles
 
-All projects and working groups are self-governed while adhering to these core principles:
+All groups are self-governed while adhering to these core principles:
 
 1. Clear contribution and decision-making processes
 2. Open communication and transparent decisions
@@ -87,7 +87,7 @@ Both must:
 
 - Document their contribution process
 - Maintain transparent communication
-- Make decisions publicly (working groups must publish meeting notes and proposals)
+- Make decisions publicly (groups must publish meeting notes and proposals)
 
 Projects and working groups without specified processes default to:
 

docs/community/working-interest-groups.mdx

@@ -0,0 +1,119 @@
+---
+title: Working and Interest Groups
+description: Learn about the two forms of collaborative groups within the Model Context Protocol's governance structure: Working Groups and Interest Groups.
+---
+
+Within the MCP contributor community we maintain two types of collaboration formats - **Interest** and **Working** groups.
+
+**Interest Groups** are responsible for identifying and articulating problems that MCP should address, primarily by facilitating open discussions within the community. In contrast, **Working Groups** focus on developing concrete solutions by collaboratively producing deliverables, such as SEPs or community-owned implementations of the specification.
+
+While input from Interest Groups can help justify the formation of a Working Group, it is not a strict requirement. Similarly, contributions from either Interest Groups or Working Groups are encouraged, but not mandatory, when submitting SEPs or other community proposals.
+
+We strongly encourage all contributors interested in working on a specific SEP to first collaborate within an Interest Group. This collaborative process helps ensure that the proposed SEP aligns with community needs and is the right direction for the protocol.
+
+Long-term projects in the MCP ecosystem, such as SDKs, Inspector, or Registry are maintained by dedicated Working Groups.
+
+## Purpose
+
+These groups exist to:
+
+- **Facilitate high-signal spaces for focused discussions** - contributors who opt into notifications, expertise sharing, and regular meetings can engage with topics that are highly relevant to them, enabling meaningful contributions and opportunities to learn from others.
+- **Establish clear expectations and leadership roles** - guide collaborative efforts and ensure steady progress toward concrete deliverables that advance MCP evolution and adoption.
+
+## Mechanisms
+
+### Interest Groups (IGs)
+
+**Goal:** Facilitate discussion and knowledge-sharing among MCP contributors who share interests in a specific MCP sub-topic or context. The primary focus is on identifying and gathering problems that may be worth addressing through SEPs or other community artifacts, while encouraging open exploration of protocol issues and opportunities.
+
+**Expectations**:
+
+- Regular conversations in the Interest Group Discord channel
+- **AND/OR** a recurring live meeting regularly attended by Interest Group members
+
+**Examples**:
+
+- Security in MCP
+- Auth in MCP
+- Using MCP in enterprise settings
+- Tooling and practices surrounding hosting MCP servers
+- Tooling and practices surrounding implementing MCP clients
+
+**Lifecycle**:
+
+- Creation begins by filling out a template in the \#wg-ig-group-creation [Discord](/community/communication#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.
+  - The creation of the group can be reversed at any time (e.g., after new information surfaces). 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. A maintainer is not required for every group, but can help advocate for specific changes or initiatives.
+- IG is retired only when community moderators or Core or Lead Maintainers determine it's no longer active and/or needed
+  - Successful IGs do not have a time limit or expiration date - as long as they are active and maintained, they will remain available
+
+**Creation Template**:
+
+- Facilitator(s)
+- Maintainer(s) (optional)
+- IGs with potentially similar goals/discussions
+- How this IG differentiates itself from the related IGs
+- First topic you to discuss within the IG
+
+Participation in an Interest Group (IG) is not required to start a Working Group (WG) or to create a SEP. However, building consensus within IGs can be valuable when justifying the formation of a WG. Likewise, referencing support from IGs or WGs can strengthen a SEP and its chances of success.
+
+### Working Groups (WG)
+
+**Goal:** Facilitate collaboration within the MCP community on a SEP, a themed series of SEPs, or an otherwise officially endorsed project.
+
+**Expectations**:
+
+- Meaningful progress towards at least one SEP or spec-related implementation **OR** hold maintenance responsibilities for a project (e.g., Inspector, Registry, SDKs)
+- Facilitators are responsible for keeping track of progress and communicating status when appropriate
+
+**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.
+  - The creation of the group can be reversed at any time (e.g., after new information surfaces). 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. A maintainer is not required for every group, but can help advocate for specific changes or initiatives
+- WG is retired when either:
+  - Community moderators or Core and Lead Maintainers decide it is no longer active and/or needed
+  - The WG no longer has an active Issue/PR for a month or more, or has completed all Issues/PRs it intended to pursue.
+
+**Creation Template**:
+
+- Facilitator(s)
+- Maintainer(s) (optional)
+- Explanation of interest/use cases, ideally originating from an IG discussion; however that is not a requirement
+- First Issue/PR/SEP that the WG will work on
+
+## WG/IG Facilitators
+
+A **Facilitator** role in a WG or IG does _not_ result in a [maintainership role](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md) across the MCP organization. It is an informal role into which anyone can self-nominate.
+
+A Facilitator is responsible for helping shepherd discussions and collaboration within an Interest or Working Group.
+
+Lead and Core Maintainers reserve the right to modify the list of Facilitators and Maintainers for any WG/IG at any time.
+
+## FAQ
+
+### How do I get involved contributing to MCP?
+
+These IG and WG abstractions help provide an elegant on-ramp:
+
+1. [Join the Discord](/community/communication#discord) and follow conversations 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. Active and valuable contributors will be nominated by WG maintainers as new maintainers.
+
+### Where can I find a list of all current WGs and IGs?
+
+On the [MCP Contributor Discord](/community/communication#discord) there is a section of channels for each Working and Interest Group.

docs/docs.json

@@ -266,6 +266,7 @@
           "community/communication",
           "community/governance",
           "community/sep-guidelines",
+          "community/working-interest-groups",
           "development/roadmap",
           "clients",
           "examples"
@@ -376,6 +377,9 @@
     }
   ],
   "contextual": {
-    "options": ["copy", "view"]
+    "options": [
+      "copy",
+      "view"
+    ]
   }
-}
+}