One read of Model Context Protocolmcp-20261109T133707Z
13 pages moved out of 360 read.
Pages moved
13
significant first
Pages read
360
in this capture
Captured
13:37 UTC
Corpus hash
e043b5a751cb
corpus-hash
What this read moved
1-13 of 13community/antitrust Changed · +1 / -7 lines
from line 4
44
55**Effective: September 29, 2025**
66
7> [!NOTE]
8>
9> This policy applies when participating in MCP meetings, Working Groups,
10> Interest Groups, and other collaborative forums where competitors may be
11> present. Most individual contributors working on code or documentation don't
12> need to worry about this in day-to-day work - it's primarily relevant for
13> group discussions about standards and specifications.
7This policy applies to MCP meetings, working groups, interest groups, and any other project forum where competitors may be present. See [Meetings and channels](https://modelcontextprotocol.io/community/working-interest-groups.md#meetings-and-channels) for how group meetings are run.
148
159## Introduction
1610
community/charter-template Changed · +34 / -69 lines
## Submitting a charter ## Template ## Example Mission Statements
from line 1
11# Group Charter Template
22
3> Template for MCP Working Group and Interest Group charters.
3> The charter template for MCP working groups and interest groups, and how to submit a charter.
44
5Every MCP Working Group and Interest Group must maintain a charter document following this structure. Charters are stored at `docs/community/working-groups/<group-name>.mdx` or `docs/community/interest-groups/<group-name>.mdx` in the [modelcontextprotocol repository](https://github.com/modelcontextprotocol/modelcontextprotocol) and added to `docs/docs.json`.
5This page gives the charter template that every working group and interest group must follow and explains how to submit a charter. The template was adopted by [SEP-2149](https://modelcontextprotocol.io/seps/2149.md), a Specification Enhancement Proposal (SEP), and is changed, together with the rules in [Working Groups and Interest Groups](https://modelcontextprotocol.io/community/working-interest-groups.md), by a Process SEP. Each charter lives at `docs/community/working-groups/<name>.mdx` or `docs/community/interest-groups/<name>.mdx` in the [modelcontextprotocol repository](https://github.com/modelcontextprotocol/modelcontextprotocol), records only the group's mission, scope, leadership, membership and operations, and does not restate those rules, which apply to every group. Sections marked **(WG only)** are required for working groups and optional for interest groups. To start a group, see [Forming a group](https://modelcontextprotocol.io/community/working-interest-groups.md#forming-a-group).
66
7The charter captures information specific to your group. Governance rules — leadership requirements, decision-making process, meeting requirements, escalation paths — are defined in the [Working and Interest Groups](https://modelcontextprotocol.io/community/working-interest-groups.md) documentation and apply automatically. Do not repeat them here.
7## Submitting a charter
88
9Sections marked **(WG only)** are required for Working Groups and optional for Interest Groups.
9* The group must already be sponsored under [Forming a group](https://modelcontextprotocol.io/community/working-interest-groups.md#forming-a-group).
10* Copy the template below into the charter file and replace the placeholders. Delete the `{/* */}` guidance comments or leave them as written: HTML comments break the MDX build, and `npm run format` corrupts a `{/* */}` comment that spans lines.
11* Run `npm run prep`, then push.
12* Open a pull request that adds the charter file, a navigation entry under Working Groups or Interest Groups in `docs/docs.json`, and a line under [Current groups](https://modelcontextprotocol.io/community/working-interest-groups.md#current-groups).
13* A Core Maintainer will review the pull request, as outlined in the [Amending or retiring a group](https://modelcontextprotocol.io/community/working-interest-groups.md#amending-or-retiring-a-group) requirements.
14* Later changes follow [Amending or retiring a group](https://modelcontextprotocol.io/community/working-interest-groups.md#amending-or-retiring-a-group) and add a row to the charter's Changelog.
1015
1116> [!NOTE]
1217>
13> Copy the markdown below into `docs/community/working-groups/<group-name>.mdx` (or `interest-groups/` for an IG) and replace the placeholder text.
18> [Transports](https://modelcontextprotocol.io/community/working-groups/transports.md) and
19> [Security](https://modelcontextprotocol.io/community/interest-groups/security.md) are filled-in examples, for a
20> working group and an interest group respectively.
1421
15***
22## Template
1623
17```markdown theme={null}
24```mdx theme={null}
1825---
1926title: <Group Name> Charter
2027description: Charter for the MCP <Group Name> <Working Group | Interest Group>.
from line 29
2229
2330## Group Type
2431
25<!-- State whether this is a Working Group or an Interest Group. -->
32{/* Keep one, delete the other. */}
2633
2734**Working Group** | **Interest Group**
2835
2936## Mission Statement
3037
31<!--
32A 2-3 sentence summary of the group's purpose.
33- The problem space being addressed
34- Why cross-cutting collaboration is needed
35- For WGs: what concrete deliverables the group will produce
36- For IGs: what discussions and knowledge-sharing the group will facilitate
37-->
38{/* Two or three sentences: the problem space, why it needs collaboration across groups, and the deliverables the WG will produce or the discussions the IG will host. */}
39{/* Example opening: "The <Group Name> Working Group exists to <deliverable> so that <outcome>." */}
3840
3941## Scope
4042
4143### In Scope
4244
43<!--
44For WGs:
45- Specification Work: Specific spec sections or SEPs owned
46- Reference Implementations: SDK components or reference implementations
47- Cross-Cutting Concerns: Areas requiring coordination with other groups
48- Documentation: Documentation responsibilities
45{/* WG: Specification Work (spec sections or SEPs the group owns), Reference Implementations (SDK components or reference implementations), Cross-Cutting Concerns (areas needing coordination with other groups), and Documentation responsibilities. */}
46{/* IG: topic areas for discussion, and the kinds of output (problem statements, use cases, recommendations). */}
4947
50For IGs:
51- Topic areas for discussion
52- Types of output (problem statements, use cases, recommendations)
53-->
54
5548### Out of Scope
5649
57<!-- Explicit statements of what is NOT within the group's purview to prevent mission creep. -->
50{/* Explicit statements of what is not within the group's purview, to prevent mission creep. */}
5851
5952### Related Groups
6053
61<!-- List of other WGs or IGs with intersecting work and the nature of overlap. -->
54{/* Other WGs or IGs with intersecting work and the nature of the overlap. */}
6255
6356## Leadership
6457
65<!--
66Leadership requirements and responsibilities are defined in the governance rules.
67List current Leads (WG) or Facilitators (IG).
68-->
58{/* List current Leads (WG) or Facilitators (IG). Requirements and duties are defined at /community/working-interest-groups#leadership. */}
6959
7060| Role | Name | Organization | GitHub | Term |
7161| ---- | ---- | ------------ | ------ | ---- |
from line 63
7363
7464## Authority & Decision Rights (WG only)
7565
76<!--
77The decision-making process (lazy consensus → vote → escalation) is defined in
78the governance rules. This table documents which decisions this WG can make at
79which authority level.
66{/* The progression from lazy consensus to vote to escalation is defined at /community/working-interest-groups#making-decisions, not here. */}
67{/* The rows below record the level at which this WG takes each kind of decision. They are the usual allocation and are approved with the charter. A change to any row follows /community/working-interest-groups#amending-or-retiring-a-group and gets a Changelog row. */}
68{/* IGs do not make binding decisions and omit this section. */}
8069
81IGs do not make binding decisions and do not need this section.
82-->
83
8470| Decision Type | Authority Level |
8571| ----------------------------------- | ------------------------------------------------------ |
8672| Meeting logistics & scheduling | WG Leads (autonomous) |
from line 80
9480
9581## Membership
9682
97<!--
98List current group members and their participation levels, if any.
99Leave out if no members exist yet. Participation tiers and membership
100criteria are defined in the governance rules.
101-->
83{/* List current members and their participation level. Omit this section until the group has members. */}
84{/* Participation tiers and membership criteria are defined at /community/working-interest-groups#participation-levels. */}
10285
10386| Name | Organization | GitHub | Discord | Level |
10487| ---- | ------------ | ------ | ------- | ----- |
from line 89
10689
10790## Operations
10891
109<!--
110Document the group's current meeting approach. Meeting requirements (open,
111published 7 days ahead, agendas/notes to GitHub Discussions) and communication
112channels are defined in the governance rules.
113-->
92{/* List the group's regular meetings. Meeting and channel rules are defined at /community/working-interest-groups#meetings-and-channels. */}
93{/* External repositories, proposal documents or meeting notes may be listed below the table. */}
11494
11595| Meeting | Frequency | Duration | Purpose |
11696| --------------- | --------- | -------- | ------------------------------------- |
from line 99
11999
120100## Deliverables & Success Metrics (WG only)
121101
122<!--
123Track active work items with status and ownership.
124IGs may optionally list current discussion topics or planned outputs here.
125-->
102{/* IGs may list current discussion topics or planned outputs here instead. */}
126103
127104### Active Work Items
128105
129| Item | Status | Target Date | Champion |
130| ------------- | ------------------------- | ----------- | -------- |
131| SEP-XXX: Name | Draft / Review / Approved | | |
106| Item | Status | Target Date | Champion |
107| -------------- | ---------------------------- | ----------- | -------- |
108| SEP-XXXX: Name | draft / in-review / accepted | | |
132109
133110### Success Criteria
134111
135<!-- Measurable outcomes for WG success. -->
112{/* State measurable outcomes. */}
136113
137114## Changelog
138115
from line 117
140117| ---- | ------ |
141118| | |
142119```
143
144***
145
146## Example Mission Statements
147
148**Working Group:**
149
150> The Transport Working Group exists to evolve MCP's transport mechanisms to support diverse deployment scenarios—from local subprocess communication to horizontally-scaled cloud deployments—while maintaining protocol coherence and backward compatibility.
151
152**Interest Group:**
153
154> The Enterprise IG explores the challenges of deploying MCP in enterprise environments, gathering use cases and requirements to inform future specification work.
155120
community/communication Changed · +18 / -96 lines
# Communication ## Channels ## Decision records # Contributor Communication ## Communication Channels ### Public Channels (Default) ### Private Channels (Exceptions) ## GitHub Discussions ## GitHub Issues ## Security Issues ## Decision Records
from line 1
1# Contributor Communication
1# Communication
22
3> Communication strategy and framework for the Model Context Protocol community
3> The MCP project's communication channels, when a channel may be private, and where decisions are recorded.
44
5This document explains how to communicate and collaborate within the Model Context Protocol (MCP) project.
5This page sets out the project's communication channels, when a channel may be private, and where decisions are recorded. It was adopted by [SEP-994](https://modelcontextprotocol.io/seps/994.md), a Specification Enhancement Proposal (SEP), and is changed by a Process SEP. The [Code of Conduct](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/CODE_OF_CONDUCT.md) governs every channel. If you are new to the project, start at [Contributing](https://modelcontextprotocol.io/community/contributing.md).
66
7## Communication Channels
7## Channels
88
9| Channel | Purpose | When to Use |
10| - | - | - |
11| [Discord](https://discord.gg/6CSzBmMkjX) | Real-time discussion | Quick questions, coordination, WG/IG discussions |
12| [Live calls](https://meet.modelcontextprotocol.io/) | Sync up | WG/IG presentations, progress reports |
13| [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions) | Structured discussion | Proposals, roadmap planning, longer-form debate |
14| [GitHub Issues](https://github.com/modelcontextprotocol/modelcontextprotocol/issues) | Actionable tasks | Bug reports, documentation fixes |
15| [Vulnerability reports](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/SECURITY.md) | Security issues | Vulnerabilities - **never post publicly** |
9| Channel | Use it for |
10| - | - |
11| [Discord](https://discord.gg/6CSzBmMkjX) | Real-time coordination among contributors, including working group, interest group and SDK discussion |
12| [Meeting calendar](https://meet.modelcontextprotocol.io/) | Open group and maintainer meetings. For how meetings run, see [Meetings and channels](https://modelcontextprotocol.io/community/working-interest-groups.md#meetings-and-channels) |
13| [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions) | Ideas, feature requests with rationale, questions, roadmap discussion, announcements and releases, and meeting agendas and notes (Meeting Notes category) |
14| [GitHub Issues](https://github.com/modelcontextprotocol/modelcontextprotocol/issues) | Reproducible bugs, scoped documentation tasks, and CI and release tasks, filed through the issue forms. [SEPs](https://modelcontextprotocol.io/community/sep-guidelines.md) are pull requests to `seps/`, not issues |
15| [Security advisories](https://modelcontextprotocol.io/community/policies.md#reporting-a-vulnerability) | Vulnerabilities. Never post one in a public channel |
1616
17All communication is governed by our [Code of Conduct](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/CODE_OF_CONDUCT.md). We expect respectful, professional, and inclusive interactions across all channels.
17Each SDK and project repository has its own issue tracker and Discord channel. Most have Discussions turned off and use Issues instead; this repository and the registry are the main exceptions. Vulnerability reports follow the [Security Policy](https://modelcontextprotocol.io/community/policies.md#reporting-a-vulnerability).
1818
1919## Discord
2020
21The [MCP Contributor Discord](https://discord.gg/6CSzBmMkjX) is for real-time contributor discussion and collaboration. The server is designed for **MCP contributors** and is not intended for general MCP support.
21The [MCP Contributor Discord](https://discord.gg/6CSzBmMkjX) is for people working on the protocol and its projects, and is where discussion of the protocol and its design starts. It is not a support channel: report a reproducible bug as an issue on the repository it affects, and start from the documentation for questions about using MCP. Do not market products or services on the server, and mention vendors only as examples relevant to the specification.
2222
23### Public Channels (Default)
23Channels are named `#general` for project-wide discussion, `#<name>-wg` and `#<name>-ig` for each working group and interest group, and `#<lang>-sdk-dev` for each SDK. Other projects have a channel such as `#inspector-dev`. Propose a new group in `#wg-ig-group-creation`. Responses are best-effort.
2424
25**Purpose:** Open community engagement, collaborative development, and transparent project coordination.
25Channels are public by default. Private channels are restricted to designated maintainers and Community Moderators and exist only for security incidents (CVEs and protocol vulnerabilities), people and Code of Conduct matters, and coordination that needs an immediate or focused response from a limited audience. Some maintainer decision channels are read-only. A private channel is a temporary incident room, not a place for routine development. Matters concerning an individual contributor may remain private.
2626
27**Primary use cases:**
27## Decision records
2828
29* SDK and tooling development (e.g., `#typescript-sdk-dev`, `#inspector-dev`)
30* [Working Group and Interest Group](https://modelcontextprotocol.io/community/working-interest-groups.md) discussions (e.g., `#auth-wg`, `#security-ig`)
31* Community onboarding and contribution guidance
32* Community feedback and collaborative brainstorming
33* Public office hours and maintainer availability
29Discord is not the record. A Discord discussion heading toward a technical or governance decision must move to a GitHub Discussion. Every technical or governance decision, including a Core Maintainer outcome on a SEP, is written up in a Discussion with the `notes` label, or on the SEP's pull request. Specification changes are also recorded in the [changelog](https://modelcontextprotocol.io/specification/draft/changelog.md), and process changes in these community pages.
3430
35**Avoid:**
36
37* MCP user support - Read official documentation and use GitHub Discussions for questions
38* Service or product marketing - Keep discussions vendor-neutral; mentions of brands are discouraged except as examples relevant to the specification
39
40### Private Channels (Exceptions)
41
42**Purpose:** Confidential coordination and sensitive matters. Access is restricted to designated maintainers.
43
44**Criteria for private use:**
45
46* Security incidents (CVEs, protocol vulnerabilities)
47* People matters (maintainer discussions, code of conduct issues)
48* Coordination requiring immediate or focused response with a limited audience
49* Some channels are read-only for maintainer decision-making
50
51**Transparency requirements:**
52
53* All technical and governance decisions affecting the community must be documented in GitHub Discussions and/or Issues, labeled with `notes`
54* Private channels are temporary "incident rooms," not for routine development
55* Some matters related to individual contributors may remain private when appropriate
56
57Any significant discussion on Discord that leads to a potential decision or proposal must be moved to GitHub Discussion or Issue for a persistent, searchable record.
58
59## GitHub Discussions
60
61Use for structured, long-form discussion and debate on project direction.
62
63**When to use:**
64
65* Project roadmap planning and milestone discussions
66* Announcements and release communications
67* Community polls and consensus-building
68* Feature requests with context and rationale
69* If a repository doesn't have Discussions enabled, use GitHub Issues instead
70
71## GitHub Issues
72
73Use for bug reports and actionable development tasks. Feature requests should go to [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions).
74
75**When to use:**
76
77* Bug reports with reproducible steps
78* Documentation improvements with specific scope
79* CI/CD problems and infrastructure issues
80* Release tasks and milestone tracking
81
82**Note:** SEP proposals are submitted as pull requests to the [`seps/` directory](https://github.com/modelcontextprotocol/modelcontextprotocol/tree/main/seps), not as GitHub Issues. See the [SEP Guidelines](https://modelcontextprotocol.io/community/sep-guidelines.md).
83
84## Security Issues
85
86**Do not post security issues publicly.**
87
881. Use the private security reporting process in [SECURITY.md](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/SECURITY.md)
892. Contact Lead or [Core Maintainers](https://modelcontextprotocol.io/community/governance.md#current-core-maintainers) directly
903. Follow responsible disclosure guidelines
91
92## Decision Records
93
94All MCP decisions are documented in public channels:
95
96| Type | Location |
97| - | - |
98| Technical decisions | [GitHub Issues](https://github.com/modelcontextprotocol/modelcontextprotocol/issues) and SEPs |
99| Specification changes | [Changelog](https://modelcontextprotocol.io/specification/draft/changelog.md) |
100| Process changes | [Community documentation](https://modelcontextprotocol.io/community/governance.md) |
101| Governance decisions | [GitHub Issues](https://github.com/modelcontextprotocol/modelcontextprotocol/issues) and SEPs |
102
103When documenting decisions, we retain as much context as possible:
104
105* Decision makers
106* Background context and motivation
107* Options considered
108* Rationale for chosen approach
109* Implementation steps
31A record names who decided, the context, the options considered, the rationale, and the next steps. For meeting agendas and notes, see [Meetings and channels](https://modelcontextprotocol.io/community/working-interest-groups.md#meetings-and-channels).
11032
community/contributor-ladder Changed · +86 / -305 lines
## Roles at a glance ## Leading a working or interest group ## Advancement process ## Escalation ## Inactivity, stepping down and removal ### Inactivity ### Stepping down ### Emeritus status ### Removal ## Guiding Principles ## Roles at a Glance ## Working Group and Interest Group Leadership ## Advancement Process ### Self-Nomination vs. Recognition ### Process Steps ## Decision-Making and Escalation ### Delegation as Default ### Escalation Matrix ## Contribution Pathways ## Stepping Down and Emeritus Status ## Recognition and Visibility
from line 1
11# Contributor Ladder
22
3> Roles, responsibilities, and advancement criteria for MCP contributors, from first contribution to Core Maintainer
3> The contributor roles in the MCP project, what each requires and grants, and how people move between them.
44
5The Model Context Protocol contributor ladder defines roles, responsibilities, and advancement criteria for the project. It shows community members how to grow their involvement from a first contribution to project leadership.
5This page defines the contributor roles in the MCP project, what each requires and grants, and how people move between them. It was adopted by [SEP-2148](https://modelcontextprotocol.io/seps/2148.md), a Specification Enhancement Proposal (SEP), and is changed by a Process SEP. Authority between roles is defined in [Governance](https://modelcontextprotocol.io/community/governance.md#roles), and the group-level roles (WG Member, WG Lead, IG Facilitator) in [Working Groups and Interest Groups](https://modelcontextprotocol.io/community/working-interest-groups.md).
66
7This document implements [SEP-2148](https://modelcontextprotocol.io/seps/2148-contributor-ladder.md). For Working Group and Interest Group governance, see [SEP-2149](https://modelcontextprotocol.io/seps/2149-working-group-charter-template.md).
7## Roles at a glance
88
9## Guiding Principles
10
11* **Earned Trust.** Advancement follows from demonstrated contributions, good judgment, and sustained engagement. Tenure alone is not enough.
12* **Multiple Growth Pathways.** Code, specification work, documentation, and community building all lead to advancement.
13* **Transparency.** Criteria for advancement are explicit and applied consistently.
14* **Alignment With MCP Goals.** Contributors must show commitment to MCP beyond any single employer's interests.
15
16## Roles at a Glance
17
18| Role | Summary | Key Privileges | Minimum Timeline |
9| Role | What it is | Access granted | Minimum time |
1910| - | - | - | - |
20| [**Contributor**](#contributor) | Anyone who contributes to MCP | Submit issues, PRs, participate in discussions | Immediate |
21| [**Member**](#member) | Established, active contributor | GitHub org membership, triage rights, eligible for WG/IG leadership | 2-3 months of meaningful contributions |
22| [**Maintainer**](#maintainer) | Area steward with operational responsibility | Merge rights, release participation | 6+ months as Member |
23| [**Core Maintainer**](#core-maintainer) | Technical leadership and protocol stewardship | Final decision authority, governance participation | By invitation after sustained Maintainer contribution |
24| [**Lead Maintainer**](#lead-maintainer) | Ultimate project authority (founders) | All Core Maintainer privileges, veto authority, appoints Core Maintainers | Reserved for project founders; succession only |
25| [**Community Moderator**](#community-moderator) | CoC enforcement and community health | Moderation rights on community platforms, incident handling | Parallel track: Member status + appointment |
11| [Contributor](#contributor) | Anyone who has contributed to MCP in any form | None; issues, pull requests and discussions are open to all | None |
12| [Member](#member) | Established, active contributor | GitHub organization membership, triage rights | 2-3 months of active participation |
13| [Maintainer](#maintainer) | Steward of a named area (an SDK, a tool, a docs area, a group) | Merge rights in the area, listed in [`MAINTAINERS.md`](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md) | 6 months as Member |
14| [Core Maintainer](#core-maintainer) | Project-wide technical leadership; authority in [Governance](https://modelcontextprotocol.io/community/governance.md#roles) | Administrative rights on all repositories | By invitation after sustained Maintainer contribution |
15| [Lead Maintainer](#lead-maintainer) | Founding role; authority in [Governance](https://modelcontextprotocol.io/community/governance.md#roles) | Administrative rights on all repositories and infrastructure | Founders and their successors only |
16| [Community Moderator](#community-moderator) | Code of Conduct enforcement and incident handling | Moderation tools on Discord and GitHub Discussions | Member status; parallel track |
2617
27> [!NOTE]
28>
29> Timelines are minimums, not guarantees. They protect the project from rapid
30> privilege escalation and ensure a high bar of demonstrated commitment. Actual
31> advancement is discretionary and may take longer. Exceptions require explicit
32> Core Maintainer approval with documented rationale.
18Timelines are minimums, advancement is discretionary, and an exception requires Core Maintainer approval with written rationale. Code, specification text, documentation, triage, security work, community work and moderation all count equally toward every role.
3319
34***
35
3620## Contributor
3721
38Anyone who has contributed to MCP in any form is a Contributor. This includes opening issues, submitting pull requests, participating in working group discussions, improving documentation, or helping other community members.
22A Contributor is anyone who has contributed to MCP in any form: issues, pull requests, group discussion, documentation, or help to others. There are no formal requirements. Start at [Contributing](https://modelcontextprotocol.io/community/contributing.md#where-to-start) and join the channels listed in [Communication](https://modelcontextprotocol.io/community/communication.md).
3923
40**There are no formal requirements.** We welcome all contributions that follow our contributing guidelines.
41
42**Getting started:**
43
44* Review the [Contributing Guide](https://modelcontextprotocol.io/community/contributing.md)
45* Join community channels (Discord, GitHub Discussions)
46* Look for issues tagged `good-first-issue` or `help-wanted`
47* Attend working group meetings
48
49***
50
5124## Member
5225
53Members are established contributors with a record of ongoing commitment to MCP.
26**Requirements.** Several contributions to MCP, including at least one merged pull request or accepted contribution. Ongoing engagement over 2-3 months rather than one-off contributions. Two-factor authentication enabled on GitHub. No objection from existing Members within 7 days of nomination.
5427
55**Requirements:**
28**Sponsorship and approval.** Sponsored by two Members or Maintainers from different organizations, or by one Core Maintainer or Lead Maintainer. Approved by no-objection.
5629
57* Multiple contributions to MCP (code, documentation, and/or community)
58* At least one merged PR or accepted contribution
59* Ongoing engagement with the community, not just one-off contributions
60* Two-factor authentication enabled on GitHub
61* No objections from existing Members within 7 days
30**Duties.** Respond to issues and pull requests assigned to you. Help onboard new contributors when you can. Follow the [Code of Conduct](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/CODE_OF_CONDUCT.md).
6231
63**Sponsorship:**
32**Privileges.** GitHub organization membership with triage rights. Can be assigned issues and pull requests and use review commands such as `/lgtm`. Pull request creation on the specification repository follows [Contributing](https://modelcontextprotocol.io/community/contributing.md#change-the-specification-or-docs). Eligible to serve as WG Lead or IG Facilitator. The member lists in the [access repository](https://github.com/modelcontextprotocol/access) are the roster. No separate list is published.
6433
65* Sponsored by two existing Members or Maintainers from different organizations, **or**
66* Sponsored by one Core Maintainer or Lead Maintainer
34**Minimum time.** 2-3 months of active participation.
6735
68**Minimum timeline:** 2-3 months of active participation
69
70**Responsibilities:**
71
72* Continue contributing in good faith
73* Respond to assigned issues and PRs
74* Follow community guidelines and the code of conduct
75* Help onboard new contributors when possible
76
77**Privileges:**
78
79* GitHub organization membership with triage rights
80* Can be assigned to issues and PRs
81* Can use shortcut approval or review commands on PRs, such as `/lgtm`
82* Listed in the community membership roster
83* Can create PRs in restricted repositories
84* Eligible for Working Group Lead or Interest Group Facilitator roles
85
86**Inactivity:** Members with no contributions for 3 months may be moved to emeritus status. Re-engagement follows a simplified re-familiarization process.
87
88***
89
9036## Maintainer
9137
92Maintainers are trusted stewards who take operational responsibility for specific areas.
38**Requirements.** Six or more months as a Member with sustained contributions. Leadership or ownership of something concrete: an SDK, a tool, a documentation area, a working or interest group, or a significant initiative. Acting for the project over the interests of any employer. Knowledge of the [roadmap](https://modelcontextprotocol.io/development/roadmap.md), the [design principles](https://modelcontextprotocol.io/community/design-principles.md) and how the area is used in practice. Completed security and governance onboarding.
9339
94**Requirements:**
40**Sponsorship and approval.** Sponsored by one Maintainer or Core Maintainer. Approved by Core Maintainers.
9541
96* Member for at least 6 months with sustained, high-quality contributions
97* Demonstrated leadership in working groups or significant initiatives
98* Ability to represent MCP's interests above those of any single employer or organization
99* Deep understanding of the MCP vision, roadmap, and design principles
100* Understanding of how the area impacts real-world AI integration and model interaction patterns
101* Completed security and governance onboarding
42**Duties.**
10243
103**Sponsorship and Approval:**
44* Own the operational health of the area, including test stability, documentation currency, the release process and milestone planning.
45* Review escalated decisions within the timelines under [Escalation](#escalation), and make sure proposals that reach Core Maintainers are refined and account for ecosystem-wide impact.
46* Mentor Members and sponsor future Maintainers.
47* Speak for the area's users, represent MCP externally when asked, and take part in roadmap and governance discussions and in the project's GitHub and Discord channels.
10448
105* Sponsored by an existing Maintainer or Core Maintainer
106* Approved by Core Maintainers
49**Privileges.** Merge rights in owned areas. May sponsor Members, Maintainers and SEPs (see [SEP Guidelines](https://modelcontextprotocol.io/community/sep-guidelines.md#sponsors)). Included in roadmap and prioritization discussions. Listed in [`MAINTAINERS.md`](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md).
10750
108**Responsibilities:**
51**Minimum time.** 6 months as Member.
10952
110* Own the operational health of the area (test stability, documentation currency)
111* Run release processes and milestone planning for the scope
112* Provide timely review of escalated decisions
113* Participate actively in governance discussions
114* Mentor Members and develop future Maintainers
115* Represent MCP in external contexts when appropriate
116* Engage with the area ecosystem and stakeholders; understand real-world usage and represent community needs
117* Ensure proposals reaching Core Maintainers are refined, well-considered, and account for ecosystem-wide impact
118* Participate actively in discussions on communication channels (GitHub issues, Discord)
119
120**Privileges:**
121
122* Merge privileges for owned areas
123* Can sponsor new Maintainers
124* Participate in roadmap and prioritization discussions
125* Listed in `MAINTAINERS.md`
126
127**Inactivity:** Maintainers with no contributions for 6 months may be moved to emeritus status following review by Core Maintainers. Merge rights are revoked upon emeritus transition. Re-engagement requires completing security and governance onboarding again.
128
129All contribution pathways can lead to Maintainer. The specific scope will align with the contribution type.
130
131***
132
13353## Core Maintainer
13454
135Core Maintainers hold final decision-making authority for MCP's technical direction. This is the highest level of trust in the community.
55**Requirements.** Six or more months as a Maintainer or in equivalent standing. Demonstrated judgment on project-wide decisions. Trusted across organizations.
13656
137> [!NOTE]
138>
139> The Core Maintainer role is intentionally limited. This ensures a coherent
140> technical vision while the project scales. Bandwidth concerns are addressed
141> through delegation to Maintainers, Working Group Leads, and Interest Group
142> Facilitators, not by expanding Core Maintainer numbers.
57**Sponsorship and approval.** Nominated by a majority of Core Maintainers and approved by Lead Maintainers, or appointed directly by Lead Maintainers. Removal is by Lead Maintainers (see [Governance](https://modelcontextprotocol.io/community/governance.md#roles)).
14358
144**Requirements:**
59**Duties.** Steward the design principles and the roadmap, and hold to long-term restraint in protocol evolution. Decide contested and cross-cutting technical questions and governance matters under the [decision process](https://modelcontextprotocol.io/community/governance.md#decision-process). Represent the project externally, plan succession, and watch community health. Attend the Core Maintainer meeting every two weeks and [Steering Group](https://modelcontextprotocol.io/community/governance.md#roles) meetups.
14560
146* Sustained contribution as Maintainer or similar role over at least 6 months
147* Demonstrated judgment on complex, project-wide decisions
148* Trust and respect across organizational boundaries
149* Deep commitment to MCP's long-term success
61**Privileges.** Vote on SEPs and governance matters. Approve Maintainers, breaking changes and major specification revisions. Administrative rights on all MCP repositories. Listed in [`MAINTAINERS.md`](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md).
15062
151**Appointment:**
63**Minimum time.** By invitation after sustained Maintainer contribution.
15264
153* Nominated by a majority of Core Maintainers and approved by Lead Maintainers, **or**
154* Direct appointment by Lead Maintainers
65The group is kept small and delegates to Maintainers, WG Leads and IG Facilitators rather than growing. When evaluating candidates, Core Maintainers consider whether it reflects the breadth of MCP adoption, including enterprise adopters running MCP in production.
15566
156When evaluating candidates, Core Maintainers should consider whether the current composition adequately represents the breadth of the MCP ecosystem. This includes enterprise adopters deploying MCP in production.
157
158**Responsibilities:**
159
160* Final technical decision authority for contested or cross-cutting issues
161* Stewardship of project vision and design principles
162* Governance and policy decisions
163* External representation of MCP
164* Succession planning and community health
165* Ensure restraint and sustainability in protocol evolution
166* Attend Core Maintainer meetings and meetups
167
168**Privileges:**
169
170* Final approval on breaking changes and major spec revisions
171* Voting rights on [SEPs](https://modelcontextprotocol.io/community/sep-guidelines.md)
172* Approval of Maintainers
173* Governance voting rights and expectation of governance participation
174* Administrative rights to all MCP GitHub repositories
175* Listed in `MAINTAINERS.md` as Core Maintainer
176
177**Inactivity:** Core Maintainers with no participation in governance or technical decisions for 6 months may be moved to emeritus status following review by Lead Maintainers. Given the visibility of this role, Core Maintainers should proactively communicate reduced availability.
178
179***
180
18167## Lead Maintainer
18268
183Lead Maintainers hold ultimate authority over MCP's direction and governance. This is a lifetime appointment reserved for project founders. There is no advancement path to this role. It is only assumed through succession (see [Succession](#succession)).
69Lead Maintainer is the founding role, held for life, with no advancement path into it. A Lead Maintainer holds every Core Maintainer duty and privilege plus the powers listed in [Governance](https://modelcontextprotocol.io/community/governance.md#roles) (veto, appointment and removal of Core Maintainers, acting alone).
18470
185**Responsibilities:**
186
187* All Core Maintainer responsibilities
188* Appoint and remove Core Maintainers
189* Final authority on contested governance decisions
190* Project-wide strategic direction
191
192**Privileges:**
193
194* Can act alone where Core Maintainers require multiple approvals
195* Veto authority over any decision
196* Appoints successor
197
19871### Succession
19972
200If a Lead Maintainer leaves the role for any reason, succession begins upon their written notice. If they cannot give notice, the remaining Lead Maintainers or Core Maintainers may determine that the Lead Maintainer is unable to continue serving.
73If a Lead Maintainer leaves the role for any reason, succession begins on their written notice or, if they cannot give notice, when the remaining Lead Maintainers or the Core Maintainers determine that the Lead Maintainer is unable to continue serving.
20174
202If one or more Lead Maintainers remain, they appoint a successor. If more than one remains, they decide by majority vote. The remaining Lead Maintainers continue to govern until a successor is appointed.
75While one or more Lead Maintainers remain, they appoint the successor, by majority vote if more than one remains, and continue to govern until the successor is appointed. If no Lead Maintainers remain, the Core Maintainers appoint a successor by majority vote within 30 days, and the project operates by two-thirds vote of Core Maintainers until a new Lead Maintainer is appointed.
20376
204If no Lead Maintainers remain, the Core Maintainers appoint a successor by majority vote within 30 days. Until a new Lead Maintainer is appointed, the project operates by two-thirds vote of Core Maintainers.
205
206***
207
20877## Community Moderator
20978
210Community Moderators help keep the MCP community healthy, safe, and welcoming. This role focuses on moderation and Code of Conduct enforcement rather than technical contribution.
79**Requirements.** Member status. Composure and good judgment in community interactions. Working knowledge of the [Code of Conduct](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/CODE_OF_CONDUCT.md). Discretion and fairness in sensitive situations.
21180
212**Requirements:**
81**Sponsorship and approval.** Sponsored and approved by one Core Maintainer or Lead Maintainer. Core Maintainers may remove a moderator for failure to uphold moderation standards or for Code of Conduct violations. A moderator may step down at any time.
21382
214* Member status minimum
215* Demonstrated good judgment and composure in community interactions
216* Understanding of the MCP Code of Conduct and community guidelines
217* Ability to handle sensitive situations with discretion and fairness
83**Duties.**
21884
219**Sponsorship:**
85* Watch community channels, including Discord and GitHub Discussions, for Code of Conduct violations.
86* Triage and respond to Code of Conduct reports, and escalate serious or complex incidents to Core Maintainers.
87* Coordinate with other moderators so that enforcement is consistent.
88* Record moderation actions and keep incident details confidential.
89* Recuse from any incident you are party to. Those incidents go directly to Core Maintainers.
22090
221* Sponsored by a Core Maintainer or Lead Maintainer
91**Privileges.** Moderation rights and tools on Discord and GitHub Discussions, and access to private moderator channels. May warn, mute or temporarily ban users for Code of Conduct violations. Listed in [`MAINTAINERS.md`](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md#community-moderators).
22292
223**Responsibilities:**
93**Minimum time.** None beyond Member status.
22494
225* Monitor community channels (Discord, GitHub Discussions, etc.) for Code of Conduct adherence
226* Handle Code of Conduct incident reports, including initial triage and response
227* Escalate serious or complex incidents to Core Maintainers
228* Help maintain a welcoming and inclusive environment
229* Coordinate with other moderators to ensure consistent enforcement
230* Document moderation actions and maintain confidentiality of incident details
231* Recuse from any incident involving them personally; such incidents go directly to Core Maintainers
95Community Moderator is a parallel track that may be held alongside any other role and is not a prerequisite for technical advancement. Moderation work counts toward every role.
23296
233**Privileges:**
97## Leading a working or interest group
23498
235* Moderation rights on community platforms (Discord, GitHub Discussions)
236* Access to moderation tools and private moderation channels
237* Authority to issue warnings, mute, or temporarily ban users for Code of Conduct violations
238* Listed in the community moderator roster
99WG Lead and IG Facilitator require Member status, not Maintainer status, and the work counts toward advancement to Maintainer. Their requirements, sponsorship and duties are defined in [Working Groups and Interest Groups](https://modelcontextprotocol.io/community/working-interest-groups.md#leadership).
239100
240**Relationship to Contributor Ladder:** Community Moderator is a parallel track, not a prerequisite for technical advancement. Moderator experience counts toward any role, especially where community judgment matters. Moderators may hold other roles at the same time (Member, Maintainer, etc.).
101## Advancement process
241102
242**Removal:** Core Maintainers may remove Community Moderators for failure to uphold moderation standards or for Code of Conduct violations. Moderators may step down voluntarily at any time.
103You may nominate yourself or be nominated by a sponsor. Self-nominees still need the sponsors listed below.
243104
244***
1051. The nominee or a sponsor opens an issue in the [specification repository](https://github.com/modelcontextprotocol/modelcontextprotocol) using the nomination template, with links to the contributions that meet the role's requirements.
1062. Sponsors confirm their support in the thread.
1073. A 7-day community comment period runs.
1084. The approving body decides and records the outcome in the thread.
1095. Access is provisioned through the [access repository](https://github.com/modelcontextprotocol/access) and the new role-holder completes onboarding.
245110
246## Working Group and Interest Group Leadership
111| Role | Sponsors | Approved by |
112| - | - | - |
113| Member | 2 Members or Maintainers from different organizations, or 1 Core or Lead Maintainer | No objection from existing Members within 7 days |
114| Maintainer | 1 Maintainer or Core Maintainer | Core Maintainers |
115| Core Maintainer | Nominated by a majority of Core Maintainers | Lead Maintainers, who may instead appoint directly |
116| Community Moderator | 1 Core or Lead Maintainer | The sponsoring Core or Lead Maintainer |
247117
248Working Group (WG) Leads and Interest Group (IG) Facilitators are a form of community leadership that does not require Maintainer status. WG and IG leadership centers on facilitation and coordination rather than merge authority.
118## Escalation
249119
250The full governance rules for WGs and IGs are defined in [SEP-2149: MCP Group Governance and Charter Template](https://modelcontextprotocol.io/seps/2149-working-group-charter-template.md). These include participation tiers, decision-making process, meeting requirements, and lifecycle.
120Decisions are made at the lowest level that owns the matter and are recorded in writing. Maintainers, WG Leads and IG Facilitators handle day-to-day decisions within their scope. Core Maintainers act on escalation, on cross-cutting questions, and where a process requires them, such as specification changes and Maintainer approval. Lead Maintainers act only on contested governance decisions or when Core Maintainers cannot reach a decision. Escalate only when you are blocked, when the decision has project-wide effect, or when a process on these pages requires it.
251121
252**Requirements:**
253
254* Member status minimum
255* Demonstrated sustained engagement with the group's scope
256* Good facilitation and communication skills
257* Ability to represent multiple perspectives fairly
258* Group and its leadership sponsored by at least two Core Maintainers or one Lead Maintainer
259
260**Relationship to Contributor Ladder:**
261
262* WG Lead and IG Facilitator experience is valuable for advancement to Maintainer
263* Leads and Facilitators without Maintainer status work with Maintainers for merge decisions
264* Leads and Facilitators have authority over group operations but not spec approval
265* WG Leads and Maintainers may sponsor SEPs
266* WG Leads may triage SEPs in their scope area. This includes closing SEPs that do not fit the roadmap. Closures require documented rationale, and authors may appeal to Core Maintainers.
267
268***
269
270## Advancement Process
271
272### Self-Nomination vs. Recognition
273
274Contributors may either:
275
2761. **Self-nominate** when they believe they meet the requirements
2772. **Be nominated** by a sponsor who has observed their contributions
278
279Both paths are equally valid. Self-nomination is encouraged. It shows initiative and self-awareness of one's contribution scope.
280
281### Process Steps
282
2831. **Nomination.** The nominee or sponsor opens an issue using the nomination template. It must include links to contributions that demonstrate the requirements, plus sponsor confirmations.
2842. **Community Review.** A 7-day period follows for community input.
2853. **Decision.** The approving authority reviews and decides.
2864. **Onboarding.** The new role-holder receives appropriate access and onboarding.
287
288| Advancement To | Approved By |
289| - | - |
290| Member | 2 existing Members+ from different organizations, **or** 1 Core/Lead Maintainer |
291| Maintainer | 1 Maintainer or Core Maintainer sponsor + Core Maintainer approval |
292| Core Maintainer | Lead Maintainers |
293| Community Moderator | 1 Core Maintainer or Lead Maintainer |
294
295Nominees who self-nominate must still secure the required sponsorship. Sponsors confirm support in the nomination issue.
296
297***
298
299## Decision-Making and Escalation
300
301### Delegation as Default
302
303MCP operates on a principle of delegation. Decisions should be made at the lowest appropriate level. This lets the project move quickly while preserving Core Maintainer bandwidth for cross-cutting concerns.
304
305* **Maintainers, WG Leads, and IG Facilitators** handle day-to-day decisions within scope.
306* **Core Maintainers** intervene on escalation, cross-cutting issues, or when required by process (spec changes, Maintainer approval).
307* **Lead Maintainers** intervene only on contested governance decisions or when Core Maintainers cannot reach consensus.
308
309When in doubt, make the decision at your level and document it. Escalate only when blocked, when the decision has project-wide implications, or when process explicitly requires it.
310
311The detailed escalation procedure for Working Group and Interest Group disputes is defined in [SEP-2149 §1.5](https://modelcontextprotocol.io/seps/2149-working-group-charter-template.md). It includes the designation of a Core Maintainer without shared organizational affiliation to resolve the issue.
312
313### Escalation Matrix
314
315| Issue Type | First Escalation | Second Escalation | Timeline |
122| Issue type | First escalation | Second escalation | Response time |
316123| - | - | - | - |
317| Technical disagreement in PR | Maintainer in scope | Core Maintainer | 5 business days |
318| Technical disagreement in WG | WG Lead | Core Maintainer | 5 business days |
319| Technical disagreement in IG | IG Facilitator | Core Maintainer | 5 business days |
320| Disagreement with WG Lead / IG Facilitator | Core Maintainer | Lead Maintainer | 7 business days |
321| Disagreement with Maintainer decision | Core Maintainer | Lead Maintainer | 7 business days |
322| Core Maintainer disagreement | Lead Maintainer | N/A | 10 business days |
124| Technical disagreement in a pull request | Maintainer in scope | Core Maintainer | 5 business days |
125| Technical disagreement in a working group | WG Lead | Core Maintainer | 5 business days |
126| Technical disagreement in an interest group | IG Facilitator | Core Maintainer | 5 business days |
127| Disagreement with a WG Lead or IG Facilitator | Core Maintainer | Lead Maintainer | 7 business days |
128| Disagreement with a Maintainer decision | Core Maintainer | Lead Maintainer | 7 business days |
129| Disagreement among Core Maintainers | Lead Maintainer | None | 10 business days |
323130| Code of Conduct violation | Community Moderator | Core Maintainer | Immediate |
324131| Security issue | Core Maintainer | Lead Maintainer | Immediate |
325132
326**Escalation process:**
133A vulnerability is reported through a private advisory first (see [Reporting a vulnerability](https://modelcontextprotocol.io/community/policies.md#reporting-a-vulnerability)). The security row is the maintainer-internal escalation once a report exists.
327134
3281. Document the decision, the options considered, and the points of disagreement
3292. Present to the escalation authority with a clear ask
3303. The escalation authority either (a) provides binding guidance, (b) requests more information, or (c) escalates further if needed
135To escalate:
331136
332***
1371. Document the decision, the options considered and the points of disagreement.
1382. Present it to the escalation authority with a clear ask.
1393. The escalation authority gives binding guidance, asks for more information, or escalates further.
333140
334## Contribution Pathways
141Disputes inside a working or interest group follow [Working Groups and Interest Groups](https://modelcontextprotocol.io/community/working-interest-groups.md#escalation), which lists the disputes that go straight to Core Maintainers and requires that the Core Maintainer designated to resolve a group dispute share no organizational affiliation with the parties.
335142
336MCP values diverse contributions. All of these pathways can lead to advancement.
143## Inactivity, stepping down and removal
337144
338**Code Contributions.** SDK development (TypeScript, Python, etc.), testing infrastructure, tooling and developer experience.
145### Inactivity
339146
340**Specification Work.** Drafting or refining spec text, [SEP](https://modelcontextprotocol.io/community/sep-guidelines.md) authorship or co-authorship, protocol design participation, compatibility analysis.
147Members with no contributions for 3 months may be moved to emeritus status. Returning Members go through a simplified re-familiarization. Maintainers with no contributions for 6 months may be moved to emeritus status after Core Maintainer review, and the move revokes their merge rights. Returning Maintainers repeat the security and governance onboarding. Lead Maintainers review a Core Maintainer after 6 months without participation in governance or technical decisions and may move them to emeritus status. Core Maintainers should say early when their availability drops.
341148
342**Documentation.** User guides and tutorials, API documentation, architecture documentation, keeping content current.
149### Stepping down
343150
344**Community Building.** Onboarding new contributors, working group facilitation, community support (Discord, GitHub discussions), event organization or representation.
151You may step down from any role for any reason. Tell the WG Lead, IG Facilitator, Maintainer or Core Maintainer you work with, hand over open work, and move to emeritus status.
345152
346**Quality and Security.** Bug triage and reproduction, security review and analysis, test coverage improvement, release validation.
153### Emeritus status
347154
348***
155Emeritus role-holders keep their recognition in [`MAINTAINERS.md`](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md) and release notes and hold no duties or privileges.
349156
350## Stepping Down and Emeritus Status
157### Removal
351158
352Contributors may step down from roles for any reason. This is normal and healthy.
353
354**Process:**
355
3561. Notify relevant leadership (WG Lead, IG Facilitator, Maintainer, or Core Maintainer as appropriate)
3572. Help transition any ongoing work
3583. Move to emeritus status
359
360**Emeritus status:**
361
362* Recognized for past contributions
363* May return to active status with abbreviated re-onboarding
364* No ongoing responsibilities or privileges
365
366**Involuntary Removal.** Roles may be revoked for code of conduct violations or sustained non-participation. Removal follows appropriate review processes.
367
368***
369
370## Recognition and Visibility
371
372The community recognizes contributors through:
373
374* **Contributor lists** such as `MAINTAINERS.md`
375* **GitHub teams** for appropriate access
376* **Public acknowledgment** in release notes
377* **Speaking opportunities** at community events
378* **Badges** (if implemented) on community platforms
159A role may be revoked for Code of Conduct violations or sustained non-participation, following appropriate review.
379160
community/design-principles Changed · +7 / -13 lines
from line 2
22
33> The core design principles that guide the development of the Model Context Protocol.
44
5These principles guide how we evaluate protocol proposals, weigh tradeoffs, and evolve MCP. They reflect lessons from building and maintaining the project. They are meant as guidance by and for the community when developing [Spec Enhancement Proposals](https://modelcontextprotocol.io/community/sep-guidelines.md) (SEPs) and [extensions](https://modelcontextprotocol.io/extensions/overview.md).
5These principles guide how we evaluate protocol proposals, weigh tradeoffs, and evolve MCP. They apply to [Specification Enhancement Proposals](https://modelcontextprotocol.io/community/sep-guidelines.md) (SEPs) and [extensions](https://modelcontextprotocol.io/extensions/overview.md), and are distinct from the specification's [architectural design principles](https://modelcontextprotocol.io/specification/latest/architecture.md#design-principles), which describe how servers and clients are built. Core Maintainers cite them when accepting or rejecting SEPs. A proposal that cuts against a principle should say so and argue why. When two principles conflict, they are weighed against each other, not ranked.
66
77## Convergence over choice
88
9There should be one way to solve a problem in MCP. Rather than supporting multiple approaches that fragment the ecosystem, we choose a single well-designed path — accepting harder decisions upfront to deliver a more cohesive protocol.
9There should be one way to solve a problem in MCP. Rather than supporting multiple approaches that fragment the ecosystem, we choose a single well-designed path, accepting harder decisions upfront to deliver a more cohesive protocol.
1010
1111[Extensions](https://modelcontextprotocol.io/extensions/overview.md) are where convergence gets tested; the specification is where it gets committed.
1212
1313## Composability over specificity
1414
15MCP provides foundational primitives: resources, tools, and prompts. We don't add protocol features for use cases that can be constructed from these existing building blocks. This keeps the surface area small and implementations simple.
15MCP provides foundational primitives: resources, tools, and prompts. We don't add protocol features for use cases that can be constructed from these existing building blocks. This keeps the surface area small and implementations simple. Extensions like [MCP Apps](https://modelcontextprotocol.io/extensions/apps/overview.md) and [Tasks](https://modelcontextprotocol.io/extensions/tasks/overview.md) capture the patterns that emerge.
1616
17When someone asks why MCP doesn't support a feature directly, the answer is usually that it can be built from what MCP already provides. Extensions like [MCP Apps](https://modelcontextprotocol.io/extensions/apps/overview.md) and [Tasks](https://modelcontextprotocol.io/extensions/tasks/overview.md) capture the patterns that emerge.
18
1917## Interoperability over optimization
2018
2119MCP runs across clients, servers, and models of widely varying sophistication. We favor features that degrade gracefully over those that only work when every participant is equally capable. Capability negotiation makes this concrete: participants declare what they support, and the protocol adapts rather than assumes.
from line 20
2220
2321## Stability over velocity
2422
25Adding to a protocol as widely adopted as MCP is easy. Removing from it is nearly impossible. Every addition is a permanent commitment and a cost for client implementers to support. We move deliberately, knowing that "no" today leaves the door open while "yes" closes it forever.
23Adding to a protocol as widely adopted as MCP is easy. Removing from it is nearly impossible. Every addition is a permanent commitment and a cost for client implementers to support. We move deliberately, knowing that "no" today leaves the door open while "yes" closes it forever. We optimize for decades, not quarters. Removal, when it happens, follows [Feature Lifecycle and Deprecation](https://modelcontextprotocol.io/community/feature-lifecycle.md).
2624
27Contributors accustomed to rapid shipping may find this pace frustrating, but sustainable standards require sustainable decision-making. We optimize for decades, not quarters.
28
2925## Capability over compensation
3026
31Models improve faster than protocols evolve. We avoid adding permanent structure to work around limitations that are likely temporary — the limitation fades, but the complexity remains.
27Models improve faster than protocols evolve. We avoid adding permanent structure to work around limitations that are likely temporary: the limitation fades, but the complexity remains.
3228
3329This is not license to ignore today's reality. Optional context that weaker models lean on and stronger ones ignore costs nothing. But when a proposal exists primarily because current models struggle without it, we ask whether they will outgrow the need before we can shed the weight.
3430
3531## Demonstration over deliberation
3632
37MCP values working implementations over theoretical debates. When evaluating proposals, we prioritize evidence from real usage over hypothetical arguments. We encourage contributors to prototype, experiment, and demonstrate rather than design by committee. Implementation reveals what discussion cannot.
33MCP values working implementations over theoretical debates, and evidence from real usage over hypothetical arguments. We encourage contributors to prototype rather than design by committee. A SEP needs a working [prototype](https://modelcontextprotocol.io/community/sep-guidelines.md#prototype-requirements) before it can be accepted.
3834
3935## Pragmatism over purity
4036
from line 38
4238
4339## Standardization over innovation
4440
45MCP standardizes patterns that have already proven valuable. We look for conventions that work across multiple implementations and codify them, rather than inventing new paradigms and hoping they'll be adopted.
46
47We encourage the use of [MCP extensions](https://modelcontextprotocol.io/extensions/overview.md) as a way to experiment with new patterns that may eventually lead to standardization.
41MCP standardizes patterns that have already proven valuable. We look for conventions that work across multiple implementations and codify them, rather than inventing new paradigms and hoping they'll be adopted. New patterns are best tried in [extensions](https://modelcontextprotocol.io/extensions/overview.md) first.
4842
community/feature-lifecycle Changed · +61 / -71 lines
# Feature Lifecycle and Deprecation # Feature Lifecycle and Deprecation Policy
from line 1
1# Feature Lifecycle and Deprecation Policy
1# Feature Lifecycle and Deprecation
22
33> How individual MCP specification features move through Active, Deprecated, and Removed states, and the timeline implementers can plan against.
44
5This policy defines a lifecycle for individual features within the Model
6Context Protocol specification. It defines three feature states (Active,
7Deprecated, Removed), the criteria and procedure for moving between them, a
8minimum window between deprecation and removal, and the documentation required
9at each transition.
5This page defines how a feature of the MCP specification is deprecated and
6later removed, and the obligations that follow for SDKs. It was adopted by
7[SEP-2596](https://modelcontextprotocol.io/seps/2596.md), a Specification Enhancement Proposal (SEP), and is
8changed by a Process SEP. Features
9currently Deprecated or scheduled for removal are listed in the
10[Deprecated registry](https://modelcontextprotocol.io/specification/draft/deprecated.md).
1011
11This policy was adopted via
12[SEP-2596](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2596).
13
1412## Scope
1513
1614This policy governs **features** of the MCP core specification: protocol
from line 26
2826| **Deprecated** | The feature remains in the specification but is scheduled for removal. A migration path is documented (see below). | New implementations should not adopt the feature. Existing implementations should migrate before the earliest removal date. |
2927| **Removed** | The feature has been deleted from `draft` and will be absent from the next Current revision. It remains documented in the Final revision it last appeared in. | Implementations targeting that next Current revision must not depend on the feature. |
3028
31A Deprecated feature MAY be restored to Active by a SEP that supersedes the
29A Deprecated feature may be restored to Active by a SEP that supersedes the
3230deprecation SEP and documents the changed circumstances. Restoration follows
3331the same approval path as deprecation. If the feature is later deprecated
3432again, the minimum deprecation window in
35[Deprecating a feature](#deprecating-a-feature) is measured afresh from the
33[Deprecating a Feature](#deprecating-a-feature) is measured afresh from the
3634revision in which the new deprecation takes effect.
3735
3836### SDKs
from line 47
4947 mitigated in place,
5048* ecosystem telemetry or SDK maintainer consensus indicates negligible adoption
5149 relative to its maintenance cost,
52* or any other reasons the Core Maintainers deem appropriate.
50* the Core Maintainers deem it appropriate for any other reason.
5351
54Deprecation is a specification change and therefore requires a SEP per the
55[SEP guidelines](https://modelcontextprotocol.io/community/sep-guidelines.md). The deprecation SEP must:
52Deprecation requires a SEP (see [SEP Guidelines](https://modelcontextprotocol.io/community/sep-guidelines.md)).
53The deprecation SEP must:
5654
57551. Identify the feature by name and link to its definition in `schema.ts`
5856 (where applicable) and the specification prose.
from line 60
6260 in the revision in which the deprecation takes effect; the replacement and
6361 the deprecation may land in the same revision.
64624. Specify the **minimum deprecation window**: the number of months, at least
65 twelve, that the feature must remain Deprecated before it is eligible for
66 removal. The window is measured from the release of the specification
67 revision in which the feature is first marked Deprecated, not from the date
68 the SEP reaches Final. The feature becomes eligible for removal in the first
69 specification revision released as Current on or after the window elapses;
70 that point is the feature's **earliest removal**.
63 twelve, that the feature must remain Deprecated. The feature's **earliest
64 removal** is the first specification revision released as Current on or
65 after the window elapses.
7166
72When the deprecation SEP is accepted and reaches Final, the deprecation is scheduled.
67When the deprecation SEP is accepted, its author makes the following changes
68to the draft specification in the SEP's pull request, and the sponsor verifies
69them before setting `final` (see
70[SEP Guidelines](https://modelcontextprotocol.io/community/sep-guidelines.md#workflow)):
7371
74* The feature's entry in `schema.ts` gains a `@deprecated` JSDoc tag
72* Add a `@deprecated` JSDoc tag to the feature's entry in `schema.ts`,
7573 referencing the deprecation SEP and the revision in which the deprecation
7674 takes effect.
77* The specification prose for the feature gains a deprecation notice with the
78 same information.
79* The `changelog.mdx` for that revision gains an entry under a "Deprecated"
80 heading. "Deprecated" and "Removed" are standing changelog headings alongside
81 the existing Major/Minor/Other groupings.
82* The feature is added to the
83 [deprecated registry](#the-deprecated-registry) with its deprecation SEP, the
84 revision in which it became Deprecated, its migration path, and its earliest
85 removal.
75* Add a deprecation notice with the same information to the feature's
76 specification prose.
77* Record the deprecation in that revision's `changelog.mdx` under a
78 "Deprecated" heading. "Deprecated" and "Removed" are standing changelog
79 headings alongside Major/Minor/Other.
80* List the feature in the [deprecated registry](#the-deprecated-registry) with
81 its deprecation SEP, the revision in which it became Deprecated, its
82 migration path, and its earliest removal.
8683
87The feature becomes Deprecated when the revision carrying these changes is released
88and becomes the new Current revision (see [versioning guide](https://modelcontextprotocol.io/docs/learn/versioning.md)).
89The minimum deprecation window is counted from that release.
84The feature becomes Deprecated when the revision carrying these edits is
85released as Current (see [versioning guide](https://modelcontextprotocol.io/docs/learn/versioning.md)), and the
86minimum deprecation window is counted from that release, not from the date the
87SEP reaches Final.
88[SEP-2577](https://modelcontextprotocol.io/seps/2577.md) is a worked example of a deprecation SEP.
9089
9190## The Deprecated Registry
9291
9392[`docs/specification/draft/deprecated.mdx`](https://modelcontextprotocol.io/specification/draft/deprecated) is
94a single page listing every feature in a Deprecated or Removed state. It is
95the canonical answer to "what is on its way out, and by when," so that an
96implementer does not have to reconstruct that picture from deprecation entries
97spread across revision changelogs.
93the single list of every feature in a Deprecated or Removed state.
9894
9995## Tier 1 SDK Obligations
10096
101Once the revision in which a feature becomes Deprecated is
102released as Current, Tier 1 SDKs:
97Once the revision in which a feature becomes Deprecated is released as Current,
98Tier 1 SDKs:
10399
104100* Must mark the corresponding API surface deprecated using the language's
105101 native mechanism (for example `@Deprecated` in Java, `[Obsolete]` in .NET,
from line 107
111107 `DeprecationWarning`, Node.js's `process.emitWarning`, or a configurable
112108 logger).
113109
114A Tier 1 SDK that consistently fails to surface a Deprecated feature is subject to the
115[Tier Relegation Process](https://modelcontextprotocol.io/community/sdk-tiers.md#tier-relegation).
110A Tier 1 SDK that consistently fails to surface a Deprecated feature is subject
111to [tier relegation](https://modelcontextprotocol.io/community/sdk-tiers.md#tier-relegation).
116112
117113## Removing a Feature
118114
1191. Once a feature is set for removal, the removal is executed at the discretion
120 of the Core Maintainers after the minimum deprecation window has elapsed.
1212. The removal needs to be documented in the `changelog.mdx` and [registry](#the-deprecated-registry).
1223. A SEP is required for any change to the original deprecation or removal SEP, for
123 example extending or shortening the timeline
124 ([Expedited removal](#expedited-removal)) or restoring the feature to Active
125 ([Feature states](#feature-states)).
115After the minimum deprecation window has elapsed, Core Maintainers may remove
116the feature when preparing a release. The removal is recorded in
117`changelog.mdx` under the "Removed" heading and in the
118[registry](#the-deprecated-registry). Any change to the original deprecation or
119removal, such as extending or shortening the timeline
120([Expedited removal](#expedited-removal)) or restoring the feature to Active
121([Feature states](#feature-states)), requires a SEP. A feature may remain
122Deprecated indefinitely.
126123
127Features may remain Deprecated, without removal, for much longer than the minimum deprecation window.
128
129124## Expedited Removal
130125
131The twelve-month floor may be shortened when the feature presents an active
132security risk, meaning a vulnerability with a published security advisory or
133documented in-the-wild exploitation for which no in-place mitigation exists.
134Shortening the window requires Core Maintainer approval under the
135[governance decision process](https://modelcontextprotocol.io/community/governance.md#decision-process), recorded
136in the deprecation SEP or, where the risk surfaces after that SEP is already
137Final, in a short expedited-removal SEP that references it. The shortened
138window must still provide at least ninety days between the feature becoming
139Deprecated and its earliest removal.
126The twelve-month minimum window may be shortened when the feature presents an
127active security risk, meaning a vulnerability with a published security
128advisory or documented in-the-wild exploitation for which no in-place
129mitigation exists. Shortening the window requires Core Maintainer approval
130under the [governance decision process](https://modelcontextprotocol.io/community/governance.md#decision-process),
131recorded in the deprecation SEP or, where the risk surfaces after that SEP is
132already Final, in a short expedited-removal SEP that references it. The
133shortened window must still provide at least ninety days between the feature
134becoming Deprecated and its earliest removal.
140135
141136## Roles
142137
143| Action | Who |
144| - | - |
145| Propose deprecation, extension, or restoration | Any contributor, per the SEP process |
146| Sponsor | A Maintainer or Core Maintainer, per the SEP process |
147| Approve a deprecation SEP | Core Maintainers, per the [governance decision process](https://modelcontextprotocol.io/community/governance.md#decision-process) |
148| Decide a removal during release preparation | Core Maintainers, per the [governance decision process](https://modelcontextprotocol.io/community/governance.md#decision-process) |
149| Approve an extension or restoration SEP | Core Maintainers, per the [governance decision process](https://modelcontextprotocol.io/community/governance.md#decision-process) |
150| Approve expedited removal | Core Maintainers, per the [governance decision process](https://modelcontextprotocol.io/community/governance.md#decision-process) |
151
152Lead Maintainers retain veto authority over each of the approvals
153above, per the [governance roles](https://modelcontextprotocol.io/community/governance.md#roles) definition.
138Any contributor may propose a deprecation, extension, or restoration through
139a SEP with a sponsor (see [SEP Guidelines](https://modelcontextprotocol.io/community/sep-guidelines.md#sponsors)).
140Core Maintainers approve deprecations, removal timing, extensions,
141restorations, and expedited removals under the
142[governance decision process](https://modelcontextprotocol.io/community/governance.md#decision-process), subject
143to Lead Maintainer veto (see [Governance](https://modelcontextprotocol.io/community/governance.md#roles)).
154144
community/policies New page · 35 lines, new page
# Project Policies ## Code of Conduct ## Antitrust ## Licensing and intellectual property ## AI-assisted contributions ## Reporting a vulnerability ## Communication and records
A whole new page. There's nothing to diff it against, so here is what it says.
# Project Policies > The standing policies that apply to everyone who takes part in the MCP project, and where each one is defined. This page lists the policies that apply to everyone who takes part in the MCP project: in meetings, on Discord, and in every repository under the [`modelcontextprotocol`](https://github.com/modelcontextprotocol) organization. Group Leads and Facilitators link it from meeting agendas. ## Code of Conduct The [Code of Conduct](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/CODE_OF_CONDUCT.md) governs every channel, repository and meeting. Send reports to [[email protected]](mailto:[email protected]). The [Community Moderators](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md#community-moderators) handle them under the [Contributor Ladder](https://modelcontextprotocol.io/community/contributor-ladder.md#community-moderator) and escalate to Core Maintainers when needed. ## Antitrust Participants often work for competing organizations. MCP is organized as Model Context Protocol a Series of LF Projects, LLC, so the [LF Projects policies](https://www.lfprojects.org/policies/), including its antitrust policy, apply to all participants. The project's own [Antitrust Policy](https://modelcontextprotocol.io/community/antitrust.md) sets out how meetings and standard-setting discussions are conducted. ## Licensing and intellectual property Code and specification contributions are made under the Apache License 2.0 and other documentation under CC-BY-4.0, with no copyright assignment. The governing text is [General Project Policies](https://modelcontextprotocol.io/community/governance.md#general-project-policies). ## AI-assisted contributions Any AI assistance used for a contribution must be disclosed in the pull request or issue, together with its extent. This includes AI-written review responses and comments; trivial spacing or typo fixes are the only exception. The full policy is [AI\_POLICY.md](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/AI_POLICY.md), which applies to every repository in the organization. ## Reporting a vulnerability > [!WARNING] > > Do not report security issues in public issues, discussions or pull requests. Open a private advisory on the affected repository at `github.com/modelcontextprotocol/<repo>/security/advisories/new`. Private vulnerability reporting is enabled on the specification repository and on every official SDK and project repository. Before filing, read [SECURITY.md](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/SECURITY.md): it says [what to include](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/SECURITY.md#what-to-include), describes the [trust model and the behaviors that are intentional rather than vulnerabilities](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/SECURITY.md#intended-behaviors-and-trust-model) (stdio command execution, denial of service by a stdio peer, server side effects, LLM-driven tool invocation), and lists [what remains in scope](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/SECURITY.md#what-remains-in-scope). The maintainers who receive a report coordinate the fix and advisory across every affected SDK so that advisories are released together, and raise it with the specification maintainers when the root cause is in the specification (see [SDK Vulnerability Disclosure](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/SECURITY.md#sdk-vulnerability-disclosure)). CVEs are assigned through GitHub's CNA. Questions that are not themselves a report, including which repository to file against, go to the [Security Interest Group](https://modelcontextprotocol.io/community/interest-groups/security.md) in `#security-ig`. ## Communication and records [Communication](https://modelcontextprotocol.io/community/communication.md) sets out which channel is for what, when a channel may be private, and where decisions are recorded.
community/sdk-tiers Changed · +34 / -71 lines
# SDK Tiers ## Tier requirements ## Conformance testing ## Tier advancement ## Tier relegation ## Issue triage labels # SDK Tiering System ## Overview ## Tier Requirements ## Conformance Testing ## Tier Advancement ## Tier Relegation ## Issue Triage Labels
from line 1
1# SDK Tiering System
1# SDK Tiers
22
3> Feature completeness, protocol support, and maintenance commitment levels for Model Context Protocol SDKs
3> What each SDK tier requires, how conformance is measured, how an SDK moves between tiers, and the issue labels SDK repositories must use.
44
5The MCP SDK Tiering System establishes clear expectations for feature completeness, protocol support, and maintenance commitments across official and community-driven SDKs. This helps developers choose the right SDK for their needs and provides SDK maintainers with a clear path to improving adoption expectations.
5This page defines the three SDK tiers, what each requires, how an SDK moves between them, and the issue labels SDK repositories must use. The tiers were adopted by [SEP-1730](https://modelcontextprotocol.io/seps/1730.md), a Specification Enhancement Proposal (SEP), and are changed by a Process SEP. The [SDK Working Group](https://modelcontextprotocol.io/community/working-groups/sdk.md) operates them, and each SDK's current tier is shown on the [SDKs page](https://modelcontextprotocol.io/docs/sdk.md).
66
7> [!NOTE]
8>
9> **Key dates:**
10>
11> * **January 23, 2026**: Conformance tests available
12> * **February 23, 2026**: Official SDK tiering published
13>
14> Between January 23 and February 23, SDK maintainers can work with the
15> Conformance Testing working group to adopt the tests and set up GitHub issue
16> tracking with the standardized labels defined below.
7## Tier requirements
178
18## Overview
9Tier 1 SDKs are fully supported and implement every non-experimental feature, including optional capabilities such as sampling and elicitation. SDKs in Tier 2 are actively maintained and working toward full specification support, and those in Tier 3 are experimental, partially implemented, or specialized. Experimental features and protocol extensions (such as Tasks and MCP Apps) are not required for any tier.
1910
20SDKs are classified into three tiers based on feature completeness, maintenance commitments, and documentation quality:
21
22* **Tier 1**: Fully supported SDKs with complete protocol implementation, including all
23 non-experimental features and optional capabilities like sampling and elicitation
24* **Tier 2**: Actively-maintained SDKs working toward full protocol specification support
25* **Tier 3**: Experimental, partially implemented, or specialized SDKs
26
27Experimental features and protocol extensions (such as Tasks and MCP Apps) are not required
28for any tier.
29
30## Tier Requirements
31
3211| Requirement | Tier 1: Fully Supported | Tier 2: Commitment to Full Support | Tier 3: Experimental |
3312| - | - | - | - |
3413| **Conformance Tests** | 100% pass rate | 80% pass rate | No minimum |
from line 19
4019| **Dependency Policy** | Published update policy | Published update policy | Not required |
4120| **Roadmap** | Published roadmap | Published plan toward Tier 1 or explanation for remaining Tier 2 | Not required |
4221
43**Issue Triage** means labeling and determining whether an issue is valid, not resolving the issue.
22**Issue Triage** means labeling an issue and determining whether it is valid, not resolving it.
4423
45**Critical Bug** refers to P0 issues (see [Priority labels](#priority-only-if-actionable) for
46detailed criteria).
24**Critical Bug** means a `P0` issue as defined under [Priority labels](#priority-only-if-actionable).
4725
48**Stable Release** is a published version explicitly marked as production-ready (e.g., version `1.0.0`
49or higher without pre-release identifiers like `-alpha`, `-beta`, or `-rc`).
26**Stable Release** means a published version explicitly marked as production-ready, for example version `1.0.0` or higher without a pre-release identifier such as `-alpha`, `-beta`, or `-rc`.
5027
51**Clear Versioning** means following idiomatic versioning patterns with documented
52breaking change policies, so users can understand compatibility expectations when upgrading.
28**Clear Versioning** means following idiomatic versioning patterns with a documented breaking-change policy.
5329
54**Roadmap** outlines concrete steps and work items that track implementation of required MCP
55specification components (non-experimental features and optional capabilities as described in
56[Conformance Testing](#conformance-testing)), giving users visibility into upcoming feature support.
30**Roadmap** means a published set of concrete steps and work items tracking implementation of the required specification components (non-experimental features and optional capabilities, as scoped under [Conformance testing](#conformance-testing)).
5731
58## Conformance Testing
32## Conformance testing
5933
60All SDKs are evaluated using [automated conformance tests](https://github.com/modelcontextprotocol/conformance)
61that validate protocol support against the published specifications. SDKs receive a conformance score
62based on test results:
34Conformance is measured with the [conformance test suite](https://github.com/modelcontextprotocol/conformance). Each official SDK runs the suite against its default branch and publishes the results.
6335
64* **Tier 1**: 100% conformance required
65* **Tier 2**: 80% conformance required
66* **Tier 3**: No minimum requirement
36The pass rates in the matrix are calculated against applicable required tests only:
6737
68Conformance scores are calculated against **applicable required tests** only:
69
7038* Tests for the specification version the SDK targets
7139* Excluding tests marked as pending or skipped
7240* Excluding tests for experimental features
from line 41
7341* Excluding legacy backward-compatibility tests (unless the SDK claims legacy support)
7442* Excluding tests labeled `disputed` in the conformance repository, until the dispute is resolved
7543
76Conformance testing validates that SDKs correctly implement the protocol by running standardized test
77scenarios and checking protocol message exchanges. See [Tier Relegation](#tier-relegation) for how
78temporary test failures are handled.
44Sustained test failures are handled under [Tier relegation](#tier-relegation).
7945
80## Tier Advancement
46## Tier advancement
8147
82SDK maintainers can request tier advancement by:
48To request a higher tier, an SDK's maintainers:
8349
841. Self-assessing against tier requirements
852. Opening an issue in the [modelcontextprotocol/modelcontextprotocol](https://github.com/modelcontextprotocol/modelcontextprotocol) repository with supporting evidence
863. Passing automated conformance testing
874. Receiving approval from SDK Working Group maintainers
501. Self-assess the SDK against the [tier requirements](#tier-requirements).
512. Open an issue in the [modelcontextprotocol/modelcontextprotocol](https://github.com/modelcontextprotocol/modelcontextprotocol) repository with the supporting evidence.
523. Pass the conformance threshold for the requested tier on the latest stable release.
534. Obtain approval from the SDK Working Group.
8854
89The SDK Working Group reviews advancement requests and makes final tier assignments.
55The SDK Working Group makes the final tier assignment and records the decision and rationale as set out in its [charter](https://modelcontextprotocol.io/community/working-groups/sdk.md).
9056
91## Tier Relegation
57## Tier relegation
9258
93An SDK may be moved to a lower tier if existing conformance tests on the latest stable release fail
94continuously for 4 weeks:
59An SDK may be moved to a lower tier if existing conformance tests on its latest stable release fail continuously for 4 weeks:
9560
96* **Tier 1 → Tier 2**: Any conformance test fails
97* **Tier 2 → Tier 3**: More than 20% of conformance tests fail
61* **Tier 1 to Tier 2**: any conformance test fails.
62* **Tier 2 to Tier 3**: more than 20% of conformance tests fail.
9863
9964An SDK may also be relegated if issues remain unaddressed for two months.
10065
101## Issue Triage Labels
66The SDK Working Group may likewise relegate a Tier 1 SDK that consistently fails to surface specification deprecations as required by [Tier 1 SDK Obligations](https://modelcontextprotocol.io/community/feature-lifecycle.md#tier-1-sdk-obligations). The group decides each relegation and records it with its rationale.
10267
103SDK repositories must use consistent labels to enable automated reporting on issue handling metrics.
104Tier calculations use these metrics to measure triage response times (time from issue creation to
105first label) and critical bug resolution times (time from P0 label to issue close).
68## Issue triage labels
10669
70SDK repositories must use the labels below. Two tier metrics are computed from them: triage response time (issue creation to first label) and critical bug resolution time (`P0` label to close).
71
10772### Type (pick one)
10873
10974| Label | Description |
from line 77
11277| `enhancement` | Request for new feature |
11378| `question` | Further information requested |
11479
115Repositories using [GitHub's native issue types](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/managing-issue-types-in-an-organization)
116satisfy this requirement without needing type labels.
80Repositories using [GitHub's native issue types](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/managing-issue-types-in-an-organization) satisfy this requirement without type labels.
11781
11882### Status (pick one)
11983
120Use these exact label names across all repositories to enable consistent reporting and analysis.
84Use these exact label names in every repository.
12185
12286| Label | Description |
12387| - | - |
from line 100
136100| `P2` | Moderate issues, valuable feature requests |
137101| `P3` | Nice to haves, rare edge cases |
138102
139**P0 (Critical)** issues are:
103A `P0` issue is either:
140104
141* **Security vulnerabilities** with CVSS score ≥ 7.0 (High or Critical severity)
142* **Core functionality failures** that prevent basic MCP operations: connection establishment,
143 message exchange, or use of core primitives (tools, resources, prompts)
105* A security vulnerability with a CVSS score of 7.0 or higher (High or Critical severity)
106* A core functionality failure that prevents basic MCP operations: connection establishment, message exchange, or use of the core primitives (tools, resources, prompts)
144107
community/security Page removed · 66 lines, page removed
# Security Policy ## Reporting a vulnerability ## SDK disclosure and cross-SDK coordination ## Scope ### Stdio transport trust boundary ## Security Interest Group
The page is gone upstream. What it last said is kept here.
community/sep-guidelines Changed · +83 / -224 lines
## When you need a SEP ## SEP types ## Before you write ## Workflow ## Sponsors ## Review and acceptance ## After the decision ## Template and tooling ## What is a SEP? ## When to Write a SEP ## SEP Types ## SEP Workflow ### Step-by-Step Process ### SEP Statuses ## SEP Format ### 1. Preamble ### 2. Abstract ### 3. Motivation ### 4. Specification ### 5. Rationale ### 6. Backward Compatibility ### 7. Reference Implementation ### 8. Security Implications ## The Sponsor Role ## Status Management ## SEP Review & Resolution ## After Rejection ## Reporting SEP Bugs or Updates ## Transferring SEP Ownership ## Copyright
from line 1
11# SEP Guidelines
22
3> Specification Enhancement Proposal (SEP) guidelines for proposing changes to the Model Context Protocol
3> When a Specification Enhancement Proposal is required and the procedure a proposal follows from pull request to Final.
44
5## What is a SEP?
5This page describes when a Specification Enhancement Proposal (SEP) is required and the procedure from pull request to Final. A SEP is a design document that gives a concise technical specification of a feature or process and its rationale. Its author is responsible for building consensus and recording dissenting opinions. [SEP-1850](https://modelcontextprotocol.io/seps/1850.md) adopted the process and [SEP-2484](https://modelcontextprotocol.io/seps/2484.md) the conformance gate. Changing either requires a Process SEP.
66
7SEP stands for Specification Enhancement Proposal. A SEP is a design document providing information to the MCP community, or describing a new feature for the Model Context Protocol or its processes. The SEP should provide a concise technical specification of the feature and a rationale for the feature.
7## When you need a SEP
88
9SEPs are the primary mechanism for proposing major new features, collecting community input on an issue, and documenting the design decisions that have gone into MCP. The SEP author is responsible for building consensus within the community and documenting dissenting opinions.
9Write a SEP for:
1010
11When drafting a SEP, authors should review the [MCP design principles](https://modelcontextprotocol.io/community/design-principles.md), which outline the core values and tradeoffs that guide the protocol's evolution.
11* A new, changed or removed protocol feature or method (a new RPC method such as `tools/execute`, a new capability negotiation field, a change to a transport)
12* Any change that is not backward compatible
13* A change to message formats or schema structure
14* An interoperability convention supported outside the core specification
15* A governance or process change
16* Anything controversial or with several plausible designs, such as a change to how authorization works
1217
13SEPs are maintained as markdown files in the [`seps/` directory](https://github.com/modelcontextprotocol/modelcontextprotocol/tree/main/seps) of the specification repository. Their revision history serves as the historical record of the feature proposal.
18Bug fixes, clarifications, editorial changes, new examples for existing features, schema fixes that do not change behavior, and tests go in an ordinary pull request. Amendments to the governance document itself follow the procedure in [SEP-2085](https://modelcontextprotocol.io/seps/2085.md), not this process. If unsure, ask in [Discord](https://modelcontextprotocol.io/community/communication.md#discord) first.
1419
15## When to Write a SEP
20## SEP types
1621
17The SEP process is reserved for changes that are substantial enough to require broad community discussion, a formal design document, and a historical record. A regular GitHub pull request is often more appropriate for smaller changes.
22* Standards Track: a new protocol feature or implementation, or an interoperability standard supported outside the core specification.
23* Informational: a design issue or guidance for the community, with no new feature.
24* Process: a process surrounding MCP, or a change to one.
25* Extensions Track: a protocol extension. It receives the same review and acceptance as Standards Track. An accepted Extensions Track SEP moves the extension to Beta, and a second one moves it to Stable (see [Extension Lifecycle](https://modelcontextprotocol.io/extensions/overview.md#extension-lifecycle) for the stages).
1826
19**Write a SEP if your change involves:**
27## Before you write
2028
21* **A new feature or protocol change** - Adding, modifying, or removing features in the protocol (new API methods, message format changes, interoperability standards)
22* **A breaking change** - Any change that is not backwards-compatible
23* **A governance or process change** - Altering decision-making or contribution guidelines
24* **A complex or controversial topic** - Changes likely to have multiple valid solutions or generate significant debate
29Bring the idea to the working or interest group that covers the area first (see [Joining a group](https://modelcontextprotocol.io/community/working-interest-groups.md#joining-a-group)). If no group fits, start a thread in [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions) or in `#general` on Discord, and if interest is sustained consider [forming a group](https://modelcontextprotocol.io/community/working-interest-groups.md#forming-a-group). Check which [roadmap](https://modelcontextprotocol.io/development/roadmap.md) priority area the idea serves, read the [design principles](https://modelcontextprotocol.io/community/design-principles.md), and try the idea as an [extension](https://modelcontextprotocol.io/extensions/overview.md) first where its shape allows. Build a prototype that meets the [Prototype Requirements](#prototype-requirements), then write the SEP.
2530
26**Skip the SEP process for:**
31Prior discussion is required, and the pull request description must link to it: a Discord thread, meeting notes or a GitHub Discussion. A SEP without a linked prior discussion is not accepted. Specification changes are slow by design (see [Stability over velocity](https://modelcontextprotocol.io/community/design-principles.md#stability-over-velocity)).
2732
28* Bug fixes and typo corrections
29* Documentation clarifications
30* Adding examples to existing features
31* Minor schema fixes that don't change behavior
33## Workflow
3234
33Not sure? Ask in [Discord](https://modelcontextprotocol.io/community/communication.md#discord) before starting significant work.
34
35## SEP Types
36
37There are four kinds of SEP:
38
391. **Standards Track** - Describes a new feature or implementation for the Model Context Protocol, or an interoperability standard supported outside the core specification.
402. **Informational** - Describes a design issue or provides guidelines/information to the community without proposing a new feature.
413. **Process** - Describes a process surrounding MCP or proposes a change to a process (like this document).
424. **Extensions Track** - Describes a protocol extension. Follows the same review and acceptance process as Standards Track SEPs, but indicates that the proposal is for an extension rather than a protocol addition. An accepted Extensions Track SEP moves an extension to Beta, and a second one moves it to Stable. See [Extension Lifecycle](https://modelcontextprotocol.io/extensions/overview.md#extension-lifecycle) for the stages.
43
44## SEP Workflow
45
4635```mermaid theme={null}
4736flowchart TD
4837 Idea["Idea"]
49 AwaitingSponsor{"Awaiting Sponsor<br/>(up to 6 months)"}
50 Draft["Draft"]
51 Dormant["Dormant<br/>(no sponsor)"]
52 Withdrawn["Withdrawn<br/>(by author)"]
53 InReview["In-Review"]
38 Awaiting{"Awaiting sponsor<br/>(PR label: proposal)"}
39 Draft["draft"]
40 Dormant["dormant"]
41 Withdrawn["withdrawn"]
42 InReview["in-review"]
5443 Decision{"Core Maintainers decide"}
55 Accepted["Accepted"]
56 Rejected["Rejected"]
57 Final["Final"]
44 Accepted["accepted"]
45 Rejected["rejected"]
46 Final["final"]
47 Superseded["superseded"]
5848
59 Idea -->|"Submit PR with SEP file"| AwaitingSponsor
60 AwaitingSponsor --> Draft
61 AwaitingSponsor --> Dormant
62 AwaitingSponsor --> Withdrawn
63 Draft -->|"Sponsor reviews"| InReview
49 Idea -->|"Open PR adding the SEP file"| Awaiting
50 Awaiting -->|"Sponsor self-assigns"| Draft
51 Awaiting -->|"180 days without a sponsor"| Dormant
52 Dormant -->|"Sponsor found, PR reopened"| Draft
53 Awaiting --> Withdrawn
54 Draft --> Withdrawn
55 Draft -->|"Sponsor sets in-review"| InReview
6456 InReview --> Decision
6557 Decision --> Accepted
6658 Decision --> Rejected
67 Accepted -->|"Reference implementation +<br/>conformance test complete"| Final
59 Decision -->|"Returned with feedback"| Draft
60 Accepted -->|"Specification text, reference implementation<br/>and conformance test complete"| Final
61 Final -->|"Replaced by a newer SEP"| Superseded
6862```
6963
70### Step-by-Step Process
641. Copy [`seps/TEMPLATE.md`](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/TEMPLATE.md) to `seps/0000-<slug>.md` and fill it in.
652. Open a pull request against the [specification repository](https://github.com/modelcontextprotocol/modelcontextprotocol), titled `sep: <description>` as in `sep: propose task cancellation`, following the [pull request title guidelines](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/CONTRIBUTING.md#pull-request-titles). The repository accepts pull requests from collaborators only; if you are not one, find a [sponsor](#sponsors) first and ask them to open it and name you as the author.
663. The SEP number is the PR number. Rename the file (PR #1850 becomes `seps/1850-<slug>.md`), update the header, and run `npm run generate:seps`, or the `check:seps` CI job fails. Rename the pull request to `sep(SEP-1850): <description>`; a follow-up commit is enough, with no amend or force-push. Later pull requests about this SEP keep `SEP-1850` as their scope and link to it in the description.
674. The PR is labeled `proposal`, meaning awaiting sponsor. `proposal` is a PR label only; the `Status` header in the SEP stays unset.
685. A [sponsor](#sponsors) assigns themselves to the PR and sets `draft`. Review takes place in PR comments.
696. When the SEP is ready, the sponsor confirms that the prior discussion happened and is linked in the pull request description, sets `in-review`, and puts it on the Core Maintainer meeting agenda. The author and sponsor may present it.
707. Core Maintainers decide under [Review and acceptance](#review-and-acceptance). The sponsor records the outcome, `accepted` or `rejected`, on the PR and in the SEP header.
718. For an accepted SEP, the author adds to the same PR: the specification prose, the `schema.ts` changes with regenerated output (see [CONTRIBUTING.md](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/CONTRIBUTING.md#schema-changes)), a changelog entry, and any required documentation edits (for a deprecation, the four edits under [Deprecating a Feature](https://modelcontextprotocol.io/community/feature-lifecycle.md#deprecating-a-feature)). The reference implementation is completed where it lives: an SDK branch, a fork or a standalone repository (see [Prototype Requirements](#prototype-requirements)). For a Standards Track SEP with observable protocol behavior, the conformance scenario and `sep-NNNN.yaml` are merged (see [Conformance Test Requirement](#conformance-test-requirement)). SDK implementations are not required for Final.
729. The sponsor verifies these artifacts and sets `final`. The PR is then merged.
7173
72**Prior discussion is required.** SEP authors must discuss the idea with the relevant [working or interest group](https://modelcontextprotocol.io/community/working-interest-groups.md) in [Discord](https://modelcontextprotocol.io/community/communication.md#discord) before opening the SEP pull request, and the PR description must link to that discussion (a Discord thread, WG/IG meeting notes, or a GitHub Discussion). A SEP without a linked prior discussion is not accepted. If no relevant group exists, start a conversation in [GitHub Discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions) or the `#general` channel in [Discord](https://modelcontextprotocol.io/community/communication.md#discord) instead. If there is enough interest, it may be worth [creating a new IG or WG](https://modelcontextprotocol.io/community/working-interest-groups.md#creating-an-interest-group). The effort involved in finding sponsors and facilitators is a good signal of whether the idea has sufficient traction.
74The eight `Status` values, also defined on the [SEP index](https://modelcontextprotocol.io/seps.md):
7375
74> [!NOTE]
75>
76> To improve your chances of a SEP being accepted, check alignment with [Core
77> Maintainer](https://modelcontextprotocol.io/community/governance.md#roles) priorities and [design
78> principles](https://modelcontextprotocol.io/community/design-principles.md). Priorities are generally reflected
79> in the [project roadmap](https://modelcontextprotocol.io/development/roadmap.md). Proposals outside current
80> priorities or that conflict with design principles are more likely to face
81> delays or additional friction in the review process.
76| Status | Meaning | Set by |
77| - | - | - |
78| `draft` | Has a sponsor, under informal review in PR comments | Sponsor |
79| `in-review` | On the Core Maintainer agenda for formal review | Sponsor |
80| `accepted` | Approved, awaiting specification text, reference implementation and conformance | Sponsor, after the Core Maintainer decision |
81| `rejected` | Declined by Core Maintainers | Sponsor, after the Core Maintainer decision |
82| `withdrawn` | Withdrawn by the author | Author or sponsor |
83| `final` | All artifacts complete and the PR merged | Sponsor |
84| `superseded` | Replaced by a newer SEP | Sponsor |
85| `dormant` | No sponsor after 180 days, PR closed, may be revived | Core Maintainers |
8286
831. **Discuss with the relevant group**: Bring your idea to the matching [working or interest group](https://modelcontextprotocol.io/community/working-interest-groups.md) and refine it there. Keep a link to the discussion (a Discord thread, meeting notes, or a GitHub Discussion) so you can include it in the PR description.
87A SEP that has no sponsor after 180 days is marked `dormant` and its PR is closed. Dormant is not rejected: a dormant SEP is revived by finding a sponsor and reopening the PR, which returns it to `draft`.
8488
852. **Draft your SEP** as a markdown file named `0000-your-feature-title.md`, using `0000` as a placeholder. Follow the [SEP format](#sep-format) below.
89## Sponsors
8690
873. **Create a pull request** adding your SEP file to the `seps/` directory in the [specification repository](https://github.com/modelcontextprotocol/modelcontextprotocol). Use a title such as `sep: propose task cancellation`, following the [PR title guidelines](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/CONTRIBUTING.md#pull-request-titles). The repository accepts pull requests from collaborators only.
91A sponsor is a Core Maintainer, a Maintainer, or a WG Lead for a SEP within that working group's scope.
8892
894. **Update the SEP number**: Once your PR is created, rename the file using the PR number (e.g., PR #1850 becomes `1850-your-feature-title.md`) and update the SEP header. Rename the PR title to `sep(SEP-1850): describe the proposal`. A follow-up commit is sufficient; you do not need to amend or force-push. Follow-up PRs about this SEP retain `SEP-1850` as their scope and link to the original SEP in the description.
93To find one, look up the Maintainers for your area in [MAINTAINERS.md](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md), then ask in the group's Discord channel.
9094
915. **Find a Sponsor**: Tag a Core Maintainer or Maintainer from [the maintainer list](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/MAINTAINERS.md). Choose someone whose area relates to your proposal. Tips:
92 * Tag 1-2 relevant maintainers, not everyone
93 * Share your PR in the relevant Discord channel
94 * If no response after 2 weeks, ask in `#general`
95If you can open pull requests on the repository, post the pull request with its prototype in that channel and tag at most two Maintainers on it. If you cannot, post the draft SEP and its prototype instead, and ask a Maintainer to sponsor it and open the pull request naming you as the author; the SEP is numbered from that pull request as usual. Either way, after two weeks with no response, ask in `#general`.
9596
966. **Sponsor assigns themselves**: When a sponsor agrees, they assign themselves to the PR and update the SEP status to `draft`.
97The sponsor reviews the proposal and requests changes, presents it with the author, verifies the Final artifacts, and makes every status change in the [Workflow](#workflow). That covers the `Status` field in the SEP file, which is canonical, and the matching PR label, which is for filtering. A sponsor without write access to the branch sets the field through the author. Authors do not edit `Status` or labels themselves; they ask their sponsor.
9798
987. **Informal review**: The sponsor reviews the proposal and may request changes. Discussion happens in PR comments.
99A WG Lead may also triage and close in-scope SEPs under [Leadership](https://modelcontextprotocol.io/community/working-interest-groups.md#leadership), subject to appeal to Core Maintainers.
99100
1008. **Formal review**: When ready, the sponsor updates the status to `in-review`. Before doing so, the sponsor confirms that the group discussion happened and is linked in the PR description. The SEP enters formal review by Core Maintainers (meetings every two weeks).
101
1029. **Resolution**: The SEP may be `accepted`, `rejected`, or returned for revision. The sponsor updates the status.
103
10410. **Finalization**: Once accepted, the reference implementation must be completed. For Standards Track SEPs with observable protocol behavior, a [conformance test](#conformance-test-requirement) must also be merged. The author adds the specification changes (schema changes, specification text, and a changelog entry) to the SEP's pull request. SDK implementations are not required for a SEP to become `final`. When this work is complete, the sponsor updates the status to `final` and the SEP's PR can be merged. Merged SEPs are published in the [SEP index](https://modelcontextprotocol.io/seps/index.md), and each one is reachable by number at `modelcontextprotocol.io/seps/<number>` (for example, [/seps/1850](https://modelcontextprotocol.io/seps/1850.md)).
105
106### SEP Statuses
107
108| Status | Meaning |
109| - | - |
110| `draft` | Has a sponsor, undergoing informal review |
111| `in-review` | Ready for formal Core Maintainer review |
112| `accepted` | Approved, awaiting implementation + conformance |
113| `rejected` | Declined by Core Maintainers |
114| `withdrawn` | Author withdrew the proposal |
115| `final` | Complete with implementation and conformance |
116| `superseded` | Replaced by a newer SEP |
117| `dormant` | No sponsor found within 6 months; can be revived |
118
119**Important distinction**: `dormant` is not the same as `rejected`. A dormant SEP simply didn't find a sponsor - the idea may still be valid. If circumstances change (new community interest, new use cases), a dormant SEP can be revived by finding a sponsor and reopening the PR.
120
121## SEP Format
122
123Each SEP should have the following parts:
124
125### 1. Preamble
126
127A short descriptive title, author names/contact info, current status, SEP type, and PR number.
128
129### 2. Abstract
130
131A short (\~200 word) description of the technical issue being addressed.
132
133### 3. Motivation
134
135Why the existing protocol specification is inadequate. This is critical - SEPs without sufficient motivation may be rejected outright.
136
137### 4. Specification
138
139The technical specification describing syntax and semantics of the new feature. Must be detailed enough for competing, interoperable implementations.
140
141### 5. Rationale
142
143Why particular design decisions were made, alternate designs considered, and related work. Should provide evidence of community consensus and address objections raised during discussion.
144
145### 6. Backward Compatibility
146
147All SEPs introducing backward incompatibilities must describe these incompatibilities, their severity, and how to deal with them.
148
149### 7. Reference Implementation
150
151Must be completed before the SEP reaches "Final" status, but need not be complete before acceptance.
152
153### 8. Security Implications
154
155Any security concerns related to the SEP should be explicitly documented.
156
157See the [SEP template](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/README.md#sep-file-structure) for the complete file structure.
158
159101## Prototype Requirements
160102
161Before a SEP can be accepted, you need "a prototype implementation demonstrating the proposal." Here's what qualifies:
103A SEP needs a working prototype before it can be accepted: an implementation in an official SDK as a branch or fork, a standalone proof of concept of the key mechanics, integration tests that exercise the proposed behavior, or a reference server or client. The prototype should show that the core functionality works as described and that the API design is practical and ergonomic, surface edge cases and implementation problems, and be runnable by reviewers from included setup instructions. Pseudocode alone, or a design document without code, is not sufficient. Production quality is not required.
162104
163**Acceptable prototypes:**
105## Review and acceptance
164106
165* A working implementation in one of the official SDKs (as a branch/fork)
166* A standalone proof-of-concept demonstrating the key mechanics
167* Integration tests showing the proposed behavior
168* A reference server or client implementing the feature
107Core Maintainers review `in-review` SEPs at their meeting every two weeks under the [decision process](https://modelcontextprotocol.io/community/governance.md#decision-process). The criteria are a working prototype, clear benefit to the MCP ecosystem, community support and consensus, and fit with the roadmap and the design principles. The outcome is `accepted`, `rejected`, or a return to `draft` with specific feedback recorded on the PR.
169108
170**The prototype should:**
171
172* Demonstrate the core functionality works as described
173* Show the API design is practical and ergonomic
174* Reveal any edge cases or implementation challenges
175* Be runnable by reviewers (include setup instructions)
176
177**Not sufficient:**
178
179* Pseudocode alone
180* A design document without code
181* "Trust me, it works" - reviewers need to see it
182
183The prototype doesn't need to be production-ready. It exists to prove feasibility and surface issues early.
184
185## The Sponsor Role
186
187A Sponsor is a Core Maintainer or Maintainer who champions the SEP through the review process. The sponsor's responsibilities include:
188
189* Reviewing the proposal and providing constructive feedback
190* Requesting changes based on community input
191* **Updating the SEP status** as the proposal progresses
192* Initiating formal review when the SEP is ready
193* Presenting and discussing the proposal at Core Maintainer meetings
194* Ensuring the proposal meets quality standards
195
196Authors should request status changes through their sponsor rather than modifying the status field themselves.
197
198## Status Management
199
200**The Sponsor is responsible for updating the SEP status.** This ensures status transitions are made by someone with the authority and context to do so appropriately.
201
202The sponsor:
203
2041. Updates the `Status` field directly in the SEP markdown file (or, if they do not have access to the source repo, work with the author to set the right status)
2052. Applies matching labels to the pull request (e.g., `draft`, `in-review`, `accepted`)
206
207Both the markdown status field and PR labels should be kept in sync. The markdown file is the canonical record (versioned with the proposal), while PR labels make it easy to filter and search.
208
209## SEP Review & Resolution
210
211SEPs are reviewed by the MCP Core Maintainers team every two weeks.
212
213For a SEP to be accepted it must meet these criteria:
214
215* A prototype implementation demonstrating the proposal
216* Clear benefit to the MCP ecosystem
217* Community support and consensus
218
219Once a SEP has been accepted, the author adds the specification changes (schema changes, specification text, and a changelog entry) to the SEP's pull request. The reference implementation must be completed, along with any required [conformance test](#conformance-test-requirement). SDK implementations are not required. When this work is complete, the status changes to "Final" and the PR can be merged.
220
221109## Conformance Test Requirement
222110
223For **Standards Track SEPs** that introduce or modify observable protocol behavior, a conformance scenario must be merged into the [conformance repository](https://github.com/modelcontextprotocol/conformance) before the SEP can reach `Final` status.
111A Standards Track SEP that introduces or modifies observable protocol behavior cannot reach `final` until the [conformance repository](https://github.com/modelcontextprotocol/conformance) has:
224112
225**What's required:**
113* A scenario tagged with the SEP number, targeting the repository's draft spec-version tag.
114* A traceability file, `sep-NNNN.yaml`, mapping every MUST, MUST NOT, SHOULD and SHOULD NOT in the SEP's Specification section to a check ID or to a documented exclusion, with a tracking issue where the exclusion is a framework gap.
115* The scenario passing against the SEP's reference implementation.
226116
227* A conformance scenario tagged with the SEP number, targeting the conformance repository's draft spec-version tag
228* A structured traceability file (`sep-NNNN.yaml`) mapping each MUST/MUST NOT and SHOULD/SHOULD NOT in the SEP's Specification section to either a check ID or a documented exclusion (with a tracking issue if it's a framework gap)
229* The scenario passes against the SEP's reference implementation
117Process SEPs, Informational SEPs, and Standards Track SEPs with no observable protocol behavior (documentation clarifications, schema annotations that do not change validation, implementation-hardening recommendations) are exempt.
230118
231**What's exempt:**
119Anyone may write the scenario: the SEP author, an SDK maintainer, or any other contributor. The sponsor confirms that it exists and that `sep-NNNN.yaml` covers every normative statement, and the conformance repository's maintainers review the scenario PR for technical correctness. Writing the scenario before Core Maintainer review is encouraged, not required. [SEP-2484](https://modelcontextprotocol.io/seps/2484.md) defines the traceability format and the dispute process.
232120
233* Process and Informational SEPs
234* Standards Track SEPs with no observable protocol behavior (documentation clarifications, non-validating schema annotations, implementation-hardening recommendations)
121## After the decision
235122
236**Who does what:**
123A rejected SEP may be revised against the recorded feedback and resubmitted, or answered with a competing SEP.
237124
238* The **sponsor** ensures a conformance scenario is written and verifies the traceability file covers every MUST/MUST NOT and SHOULD/SHOULD NOT in the SEP
239* The **conformance repository maintainers** review the scenario PR for technical correctness
240* The test **author** can be anyone: the SEP author, an SDK maintainer, a community contributor
125Before Final, raise problems on the SEP's PR. A Final SEP is a frozen record of the design as accepted. Where the specification has since diverged, the specification governs: report problems as issues against it, not as edits to the SEP.
241126
242Writing a conformance scenario during SEP drafting (before Core Maintainer review) is encouraged but not required, since it often surfaces ambiguities in normative language that are cheaper to fix early.
127A SEP is withdrawn at the author's request. The author or the sponsor sets `withdrawn`. A SEP that replaces an earlier one carries a `Supersedes:` line in its header, and the earlier SEP is set `superseded`.
243128
244See [SEP-2484](https://modelcontextprotocol.io/seps/2484-conformance-tests-required-for-final-seps.md) for the full specification including the traceability file format and dispute process.
129Ownership of a SEP may pass to a new author when the original author no longer has time for it or cannot be reached. The original author stays on as co-author if they wish. Disagreement with the author's direction is not grounds for transfer. Write a competing SEP instead.
245130
246## After Rejection
131## Template and tooling
247132
248Rejection is not permanent. You can:
133SEP files live in [`seps/`](https://github.com/modelcontextprotocol/modelcontextprotocol/tree/main/seps), and each file's git history is the record of the proposal. [`seps/TEMPLATE.md`](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/seps/TEMPLATE.md) gives the structure: a preamble, then Abstract, Motivation, Specification, Rationale, Backward Compatibility, Security Implications and Reference Implementation. The Abstract is about 200 words. Insufficient Motivation is by itself grounds for rejection. The Specification must be detailed enough for independent, interoperable implementations. In the Rationale, record the alternatives considered, the objections raised and the evidence of consensus. Backward Compatibility is mandatory whenever the SEP introduces an incompatibility, and states its severity and the migration path. Security Implications are stated explicitly, including when there are none.
249134
2501. **Address the feedback** - If specific concerns were raised, address them and resubmit
2512. **Discuss the rejection** - Ask in Discord to understand the reasoning
2523. **Submit a competing SEP** - Sometimes a different approach works better
2534. **Wait for the right time** - Community needs evolve; what's rejected today may be welcomed later
254
255## Reporting SEP Bugs or Updates
256
257For SEPs not yet reaching `final` state, comment directly on the SEP's pull request.
258
259Final SEPs are preserved as historical records of the design as accepted. They are not updated after finalization. If the specification changes after a SEP reaches Final status, the current specification is authoritative. Each Final SEP page displays a notice to this effect.
260
261## Transferring SEP Ownership
262
263It occasionally becomes necessary to transfer ownership of SEPs to a new author. In general, we'd like to retain the original author as a co-author, but that's up to the original author.
264
265Good reasons to transfer ownership:
266
267* Original author no longer has time or interest
268* Original author is unreachable
269
270Bad reasons:
271
272* You disagree with the direction (submit a competing SEP instead)
273
274## Copyright
275
276This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.
135`npm run generate:seps` renders the files into `docs/seps/`, and `npm run check:seps` verifies that the rendered pages are current. For a worked example, see [SEP-2567](https://modelcontextprotocol.io/seps/2567.md), a recent Final Standards Track SEP.
277136
community/working-groups/apps New page · 123 lines, new page
# MCP Apps Working Group Charter ## Group Type ## Mission Statement ## Scope ### In Scope ### Out of Scope ### Related Groups ## Leadership ## Authority & Decision Rights ## Membership ## Operations ## Resources ## Deliverables & Success Metrics ### Active Work Items ### Success Criteria ## Changelog
A whole new page. There's nothing to diff it against, so here is what it says.
# MCP Apps Working Group Charter > Charter for the MCP Apps Working Group. ## Group Type **Working Group** ## Mission Statement The MCP Apps Working Group defines, evolves, and maintains the official extension for interactive user interfaces over MCP. The working group oversees the extension specification, SDK, reference implementations, security model, conformance work, and guidance so that apps can run safely and consistently across independent MCP hosts. ## Scope ### In Scope * **Specification Work**: The [MCP Apps extension specification](https://github.com/modelcontextprotocol/ext-apps/tree/main/specification) and related SEPs, covering the areas below under the `io.modelcontextprotocol/ui` namespace. * **App Lifecycle**: How apps are declared, initialized, persisted, and torn down, including UI resource declaration and tool metadata. * **App Interaction Model**: The interaction protocol between user, app, and host, such as bi-directional messaging, app tools, etc. * **Content Types and Rendering Targets**: Support for different content types and methodologies like generative UI, with interoperability with external protocols such as [A2UI](https://a2ui.org/) and [AG-UI](https://ag-ui.com/). * **Security Model**: The threat model, sandboxing, security policy, permissions, and auditability of UI-initiated actions. * **SDKs and Reference Implementations**: The [`@modelcontextprotocol/ext-apps`](https://github.com/modelcontextprotocol/ext-apps) SDK, reference host, example servers, and host integration examples. * **Conformance**: Compatibility tests, app validation, and the definition of conformance requirements for apps and hosts. * **Cross-Cutting Coordination**: App discovery and metadata (with the Registry WG), UI in agentic flows (with the Agents IG), and per-language SDK support (with the SDK WG). * **Documentation**: API references, authoring guidance, host integration guidance, starter resources, and examples. ### Out of Scope * **Core protocol ownership**: Changes to base MCP semantics, transports, or lifecycle are proposed through the [SEP process](https://modelcontextprotocol.io/community/sep-guidelines.md) and owned by the relevant group or Core Maintainers. * **Host-specific product and design decisions**: Hosts control their user experience and visual design. The WG standardizes the interoperability and security contract. * **Individual app implementations**: Apps built on the extension remain the responsibility of their authors. * **General agent orchestration**: Agent loops and sub-agent coordination belong to the Agents IG, and task management belongs to the Tasks and Events WG. This WG covers only the interactive UI surface and its integration points. ### Related Groups * **Agents IG**: Interactive UI within agentic flows and task lifecycles. * **[Registry WG](https://modelcontextprotocol.io/community/working-groups/registry.md)**: App discovery, distribution, and metadata. * **[Security IG](https://modelcontextprotocol.io/community/interest-groups/security.md)**: Sandboxing, permissions, and review of UI-initiated actions. * **[SDK WG](https://modelcontextprotocol.io/community/working-groups/sdk.md)**: SDK consistency and support outside the TypeScript reference implementation. ## Leadership | Role | Name | Organization | GitHub | Term | | - | - | - | - | - | | Lead | Ido Salomon | MCP-UI | [@idosal](https://github.com/idosal) | Initial | | Lead | Liad Yosef | MCP-UI / Ora | [@liady](https://github.com/liady) | Initial | | Lead | Olivier Chafik | Anthropic | [@ochafik](https://github.com/ochafik) | Initial | ## Authority & Decision Rights | Decision Type | Authority Level | | - | - | | Meeting logistics & scheduling | WG Leads (autonomous) | | Proposal prioritization within WG | WG Leads (autonomous) | | SEP triage & closure (in scope) | WG Leads (autonomous, with documented rationale) | | Technical design within scope | WG consensus | | Spec changes (additive) | WG consensus → Core Maintainer approval | | Spec changes (breaking/fundamental) | WG consensus → Core Maintainer approval + wider review | | Scope expansion | Core Maintainer approval required | | WG Member approval | WG Member sponsors | ## Membership | Name | Organization | GitHub | Discord | Level | | - | - | - | - | - | | Ido Salomon | MCP-UI | [@idosal](https://github.com/idosal) | | Lead | | Liad Yosef | MCP-UI / Ora | [@liady](https://github.com/liady) | | Lead | | Olivier Chafik | Anthropic | [@ochafik](https://github.com/ochafik) | | Lead | | Anton Pidkuiko | Anthropic | [@antonpk1](https://github.com/antonpk1) | | WG Member | | Max Stoiber | OpenAI | [@mstoiber-oai](https://github.com/mstoiber-oai) | | WG Member | | Dominic Farolino | Google | [@domfarolino](https://github.com/domfarolino) | | WG Member | ## Operations | Meeting | Frequency | Duration | Purpose | | - | - | - | - | | Working Session | Tri-weekly (Wednesday, 08:00 Pacific) | 60 minutes | Specification review, roadmap discussion, and app/host feedback | Meetings are published on the [MCP community calendar](https://meet.modelcontextprotocol.io/tag/mcp-apps-wg) under the `#mcp-apps-wg` tag. Agendas and notes are maintained in the public [MCP Apps Working Group agenda](https://docs.google.com/document/d/103S6IjN9D80ntbPIcK3mP_ZWdeFom2Mq8qpkpIsXRVI/edit) and linked from calendar entries. Discord: `#mcp-apps-wg` ## Resources * Specification and SDK: [modelcontextprotocol/ext-apps](https://github.com/modelcontextprotocol/ext-apps) (`@modelcontextprotocol/ext-apps`) * Foundational proposal: [SEP-1865](https://modelcontextprotocol.io/seps/1865-mcp-apps-interactive-user-interfaces-for-mcp.md) * Guides: [MCP Apps overview](https://modelcontextprotocol.io/extensions/apps/overview.md) and [Build an MCP App](https://modelcontextprotocol.io/extensions/apps/build.md) * API documentation: [apps.extensions.modelcontextprotocol.io](https://apps.extensions.modelcontextprotocol.io/) * Work tracking: [ext-apps issues](https://github.com/modelcontextprotocol/ext-apps/issues) and [pull requests](https://github.com/modelcontextprotocol/ext-apps/pulls) ## Deliverables & Success Metrics ### Active Work Items Live work is tracked in the ext-apps [issue tracker](https://github.com/modelcontextprotocol/ext-apps/issues) and [pull requests](https://github.com/modelcontextprotocol/ext-apps/pulls). Headline workstreams are: | Item | Status | Target Date | Champion | | - | - | - | - | | Specification and SDK evolution: protocol alignment, capability negotiation, versioning, and maintenance of `@modelcontextprotocol/ext-apps` | In Progress | | [@idosal](https://github.com/idosal), [@liady](https://github.com/liady), [@ochafik](https://github.com/ochafik) | | Address view sprawl across tools and servers (reusable and independent views) | In Progress | | [@mstoiber-oai](https://github.com/mstoiber-oai), [@idosal](https://github.com/idosal), [@liady](https://github.com/liady) | | Formalize security model and extend sandboxing and permissions | In Progress | | [@idosal](https://github.com/idosal) | | Experiment with the app tools interaction model (WebMCP approach) | In Progress | | [@ochafik](https://github.com/ochafik) | | Address dynamic resource content and non-HTML hosts | Draft | | [@liady](https://github.com/liady), [@idosal](https://github.com/idosal) | | Conformance and cross-host interoperability: official validator, public platform tests, and compatibility reporting | In Progress | | [@idosal](https://github.com/idosal) | | Developer experience and ecosystem adoption: reference host, authoring tools, examples, documentation, accessibility, and discovery coordination | Maintained | | [@idosal](https://github.com/idosal) | ### Success Criteria * The extension specification, SDK, reference host, and examples are actively maintained, with responsive triage of specification and SDK issues. * MCP Apps can run unmodified across multiple major hosts. * Conforming hosts implement the documented sandboxing, permissions, content security policy, and auditability requirements, verified by the conformance suite. * Breaking changes are rare, documented, and preceded by an appropriate deprecation and migration path. * MCP Apps is the standard UI layer of the agentic web. ## Changelog | Date | Change | | - | - | | 2025-11-21 | SEP-1865 proposed, unifying the MCP-UI and OpenAI Apps SDK approaches | | 2025-12-17 | First MCP Apps Working Group meeting | | 2026-01-26 | Initial stable MCP Apps extension specification published | | 2026-01-28 | SEP-1865 marked Final | | 2026-05-21 | Initial charter |
community/working-interest-groups Changed · +97 / -239 lines
# 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?
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
registry/about Changed · +1 / -1 lines
from line 24
2424
2525The MCP Registry is part of an ecosystem that looks something like:
2626
27
27
2828
2929### Relationship with Package Registries
3030