SEP Guidelines changedcommunity/sep-guidelines
Nearest release: v2.1.321, published 5 hours after upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Upstream edited this page at 9 Nov 2026 13:29 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 9 Nov 2026 13:37 UTC.
Upstream edited
Recorded here
Lines+83added
Lines−224removed
From line
1
where the diff opens
First seen
14 Aug 2026
this site's first read of the page
Recorded edits10to this page, all time
## 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
The whole hunk
from line 1, old and new numbered
/
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
No line in this hunk matches that.