# Source: https://modelcontextprotocol.io/community/governance.md

> ## Documentation Index
> Fetch the complete documentation index at: https://modelcontextprotocol.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Governance and Stewardship

> Learn about the Model Context Protocol's governance structure and how to participate in the community

The Model Context Protocol (MCP) follows a formal governance model to ensure transparent decision-making and community participation. This document outlines how the project is organized and how decisions are made.

## General Project Policies

Model Context Protocol has been established as **Model Context Protocol a Series of LF Projects, LLC**. Policies applicable to Model Context Protocol and participants in Model Context Protocol, including guidelines on the usage of trademarks, are located at [https://www.lfprojects.org/policies/](https://www.lfprojects.org/policies/). Governance changes approved as per the provisions of this governance document must also be approved by LF Projects, LLC.

Model Context Protocol participants acknowledge that the copyright in all new contributions will be retained by the copyright holder as independent works of authorship and that no contributor or copyright holder will be required to assign copyrights to the project.

Except as described below, all code and specification contributions to the project must be made using the Apache License, Version 2.0 (available here: [https://www.apache.org/licenses/LICENSE-2.0](https://www.apache.org/licenses/LICENSE-2.0)) (the "Project License").

All outbound code and specifications will be made available under the Project License. The Core Maintainers may approve the use of an alternative open license or licenses for inbound or outbound contributions on an exception basis.

All documentation (excluding specifications) will be made available under Creative Commons Attribution 4.0 International license, available at: [https://creativecommons.org/licenses/by/4.0](https://creativecommons.org/licenses/by/4.0).

## Technical Governance

The MCP project adopts a hierarchical structure, similar to Python, PyTorch, and other open source projects:

```
┌─────────────────────────────────────────────┐
│           Lead Maintainers (BDFL)           │
│         Final decision authority            │
├─────────────────────────────────────────────┤
│            Core Maintainers                 │
│      Overall project direction              │
├─────────────────────────────────────────────┤
│              Maintainers                    │
│    Working Groups, SDKs, components         │
├─────────────────────────────────────────────┤
│             Contributors                    │
│      Issues, PRs, discussions               │
└─────────────────────────────────────────────┘
```

* **Contributors** file issues, make pull requests, and contribute to the project.
* **Maintainers** drive components within the MCP project, such as SDKs, documentation, and Working Groups.
* **Core Maintainers** drive the overall project direction and oversee contributors and maintainers.
* **Lead Maintainers** are the final decision makers (also known as BDFL - Benevolent Dictator for Life).

Together, Maintainers, Core Maintainers, and Lead Maintainers form the **MCP Steering Group**.

All maintainers are expected to have a strong bias towards MCP's design philosophy. Membership in the technical governance process is for individuals, not companies. That is, there are no seats reserved for specific companies, and membership is associated with the person rather than the company employing that person.

### Communication Channels

Technical governance is facilitated through a shared [Discord server](https://discord.gg/6CSzBmMkjX) for all maintainers. Each maintainer group can choose additional communication channels, but all decisions and their supporting discussions must be recorded and made transparently available on the Discord server.

### Maintainers

Maintainers are responsible for [Working Groups 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. They are expected to make decisions for their respective projects independently, but can defer or escalate to the Core Maintainers when needed.

**Maintainer responsibilities:**

* Thoughtful and productive engagement with community contributors
* Maintaining and improving their respective area of the MCP project
* Supporting documentation, roadmaps, and other adjacent parts of the MCP project
* Presenting ideas from the community to Core Maintainers

Maintainers are encouraged to propose additional maintainers when needed. Maintainers can only be appointed and removed by Core Maintainers or Lead Maintainers at any time and without reason.

Maintainers have write and/or admin access to their respective repositories.

### Core Maintainers

The Core Maintainers are expected to have a deep understanding of the Model Context Protocol and its specification. Their responsibilities include:

* Designing, reviewing, and steering the evolution of the MCP specification, as well as all other parts of the MCP project
* Articulating a cohesive long-term vision for the project
* Mediating and resolving contentious issues with fairness and transparency, seeking consensus where possible while making decisive choices when necessary
* Appointing or removing Maintainers
* Stewardship of the MCP project in the best interest of MCP

The Core Maintainers as a group have the power to veto any decisions made by Maintainers by majority vote. The Core Maintainers have power to resolve disputes as they see fit. The Core Maintainers should publicly articulate their decision-making. The core group is responsible for adopting their own procedures for making decisions.

Core Maintainers generally have write and admin access to all MCP repositories, but should use the same contribution (usually pull-request) mechanism as outside contributors. Exceptions can be made based on security considerations.

### Lead Maintainers (BDFL)

MCP has two Lead Maintainers: Justin Spahr-Summers and David Soria Parra. Lead Maintainers can veto any decision by Core Maintainers or Maintainers. This model is also commonly known as Benevolent Dictator for Life (BDFL) in the open source community.

The Lead Maintainers should publicly articulate their decision-making and give clear reasoning for their decisions. Lead Maintainers are part of the Core Maintainer group.

The Lead Maintainers are responsible for confirming or removing Core Maintainers.

Lead Maintainers are administrators on all infrastructure for the MCP project where possible. This includes but is not restricted to all communication channels, GitHub organizations, and repositories.

### Decision Process

The Core Maintainer group meets every two weeks to discuss and vote on proposals, as well as discuss any topics needed. The shared Discord server can be used to discuss and vote on smaller proposals if needed.

The Lead Maintainer, Core Maintainer, and Maintainer group should attempt to meet in person every three to six months.

## Processes

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

### Working Groups and Interest Groups

MCP collaboration and contributions are organized around two structures: [Working Groups and Interest Groups](/community/working-interest-groups).

* **Interest Groups** identify and articulate problems that MCP should address through open discussions
* **Working Groups** develop concrete solutions by producing deliverables like SEPs or implementations

For details on how to create, participate in, and facilitate these groups, see the [Working and Interest Groups](/community/working-interest-groups) documentation.

### Specification Enhancement Proposals (SEPs)

Proposed changes to the specification must be submitted as [Specification Enhancement Proposals (SEPs)](/community/sep-guidelines). SEPs are the primary mechanism for proposing major new features, collecting community input, and documenting design decisions.

For the complete SEP process, format requirements, and status workflow, see the [SEP Guidelines](/community/sep-guidelines).

### Maintenance Responsibilities

Components without dedicated maintainers (such as documentation) fall under Core Maintainer responsibility. These follow standard contribution guidelines through pull requests, with maintainers handling reviews and escalating to Core Maintainer review for any significant changes.

Core Maintainers and Maintainers are encouraged to improve any part of the MCP project, regardless of formal maintenance assignments.

## Communication

### Core Maintainer Meetings

The Core Maintainer group meets on a bi-weekly basis to discuss proposals and the project. Notes on proposals should be made public. The Core Maintainer group will strive to meet in person every 3-6 months.

### Public Chat

The MCP project maintains a [public Discord server](https://discord.gg/6CSzBmMkjX) with open chats for interest groups. The MCP project may have private channels for certain communications.

## Nominating, Confirming, and Removing Maintainers

### Principles

* Membership in maintainer groups is given to **individuals** on merit basis after they demonstrated strong expertise of their area of work through contributions, reviews, and discussions and are aligned with the overall MCP direction.
* For membership in the **Maintainer** group, the individual has to demonstrate strong and continued alignment with the overall MCP principles.
* No term limits for Maintainers or Core Maintainers.
* Light criteria of moving Working Group or sub-project maintenance to 'emeritus' status if they don't actively participate over long periods of time. Each maintainer group may define the inactive period that's appropriate for their area.
* The membership is for an individual, not a company.

### Nomination and Removal

* The Lead Maintainers are responsible for adding and removing Core Maintainers.
* Core Maintainers are responsible for adding and removing Maintainers. They will take the consideration of existing Maintainers into account.
* If a Working Group or Interest Group with 2+ existing Maintainers unanimously agrees to add additional Maintainers (up to a maximum of 5), they may do so without Core Maintainer review.

### Nomination Process

If a Maintainer (or Core/Lead Maintainer) wishes to propose a nomination for the Core/Lead Maintainers' consideration, they should follow this process:

1. Collect evidence for the nomination. This will generally come in the form of a history of merged PRs on the repositories for which maintainership is being considered.
2. Discuss among Maintainers of the relevant group(s) as to whether they would be supportive of approving the nomination.
3. DM a Community Moderator or Core Maintainer to create a private channel in Discord, in the format `nomination-{name}-{group}`. Add all Core Maintainers, Lead Maintainers, and co-Maintainers on the relevant group.
4. Provide context for the individual under nomination. See below for suggestions on what to include.
5. Create a Discord Poll and ask Core/Lead Maintainers to vote Yes/No on the nomination. Reaching consensus is encouraged though not required.
6. After Core/Lead Maintainers discuss and/or vote, if the nomination is favorable, relevant members with permissions to update GitHub and Discord roles will add the nominee to the appropriate groups. The nominator should announce the new maintainership in the relevant Discord channel.
7. The temporary Discord channel will be deleted a week later.

**Suggestions for nomination context:**

* GitHub profile link, LinkedIn profile link, Discord username
* For what group(s) are you nominating the individual for maintainership
* Whether the group(s) agree that this person should be elevated to maintainership
* Description of their contributions to date (including links to most substantial contributions)
* Description of expected contributions moving forward (e.g., Are they eager to be a Maintainer? Will they have capacity to do so?)
* Other context about the individual (e.g., current employer, motivations behind MCP involvement)
* Anything else you think may be relevant to consider for the nomination

## Current Core Maintainers

* Peter Alexander
* Caitie McCaffrey
* Kurtis Van Gent
* Paul Carleton
* Nick Cooper
* Nick Aldridge
* Che Liu
* Den Delimarsky

## Current Maintainers and Working Groups

Refer to [the maintainer list](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md).