Skip to main content

​
What is a SEP?

SEP 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 or environment. The SEP should provide a concise technical specification of the feature and a rationale for the feature. We intend SEPs to be the primary mechanisms for proposing major new features, for collecting community input on an issue, and for documenting the design decisions that have gone into MCP. The SEP author is responsible for building consensus within the community and documenting dissenting opinions. SEPs are maintained as markdown files in the seps/ directory of the specification repository. Their revision history serves as the historical record of the feature proposal.

​
What qualifies as a SEP?

The goal is to reserve the SEP process for changes that are substantial enough to require broad community discussion, a formal design document, and a historical record of the decision-making process. A regular GitHub pull request is often more appropriate for smaller, more direct changes. Consider proposing a SEP if your change involves any of the following:
  • A New Feature or Protocol Change: Any change that adds, modifies, or removes features in the Model Context Protocol. This includes:
    • Adding new API endpoints or methods.
    • Changing the syntax or semantics of existing data structures or messages.
    • Introducing a new standard for interoperability between different MCP-compatible tools.
    • Significant changes to how the specification itself is defined, presented, or validated.
  • A Breaking Change: Any change that is not backwards-compatible.
  • A Change to Governance or Process: Any proposal that alters the project’s decision-making, contribution guidelines (like this document itself).
  • A Complex or Controversial Topic: If a change is likely to have multiple valid solutions or generate significant debate, the SEP process provides the necessary framework to explore alternatives, document the rationale, and build community consensus before implementation begins.

​
SEP Types

There are three kinds of SEP:
  1. Standards Track SEP describes a new feature or implementation for the Model Context Protocol. It may also describe an interoperability standard that will be supported outside the core protocol specification.
  2. Informational SEP describes a Model Context Protocol design issue, or provides general guidelines or information to the MCP community, but does not propose a new feature. Informational SEPs do not necessarily represent an MCP community consensus or recommendation.
  3. Process SEP describes a process surrounding MCP, or proposes a change to (or an event in) a process. Process SEPs are like Standards Track SEPs but apply to areas other than the MCP protocol itself.

​
Submitting a SEP

The SEP process begins with a new idea for the Model Context Protocol. It is highly recommended that a single SEP contain a single key proposal or new idea. Small enhancements or patches often don’t need a SEP and can be injected into the MCP development workflow with a pull request to the MCP repo. The more focused the SEP, the more successful it tends to be. Each SEP must have an SEP author — someone who writes the SEP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The SEP author should first attempt to ascertain whether the idea is SEP-able. Posting to the MCP community forums (Discord, GitHub Discussions) is the best way to go about this.

​
SEP Workflow

SEPs are submitted as pull requests to the seps/ directory in the specification repository. The standard SEP workflow is:
  1. Draft your SEP as a markdown file named 0000-your-feature-title.md, using 0000 as a placeholder for the SEP number. Follow the SEP format described below.
  2. Create a pull request adding your SEP file to the seps/ directory in the specification repository.
  3. Update the SEP number: Once your PR is created, amend your commit to rename the file using the PR number (e.g., PR #1850 becomes 1850-your-feature-title.md) and update the SEP header to reference the correct number.
  4. Find a Sponsor: Tag a Core Maintainer or Maintainer from the maintainer list in your PR to request sponsorship. Maintainers regularly review open proposals to determine which to sponsor.
  5. Sponsor assigns themselves: Once a sponsor agrees, they will assign themselves to the PR and update the SEP status to draft in the markdown file.
  6. Informal review: The sponsor reviews the proposal and may request changes based on community feedback. Discussion happens in the PR comments.
  7. Formal review: When the SEP is ready, the sponsor updates the status to in-review. The SEP enters formal review by the Core Maintainers team.
  8. Resolution: The SEP may be accepted, rejected, or returned for revision. The sponsor updates the status accordingly.
  9. Finalization: Once accepted, the reference implementation must be completed. When complete and incorporated into the specification, the sponsor updates the status to final.
If a SEP has not found a sponsor within six months, Core Maintainers may close the PR and mark the SEP as dormant.

​
SEP Format

Each SEP should have the following parts:
  1. Preamble — A short descriptive title, the names and contact info for each author, the current status, SEP type, and PR number.
  2. Abstract — A short (~200 word) description of the technical issue being addressed.
  3. Motivation — The motivation should clearly explain why the existing protocol specification is inadequate to address the problem that the SEP solves. The motivation is critical for SEPs that want to change the Model Context Protocol. SEP submissions without sufficient motivation may be rejected outright.
  4. Specification — The technical specification should describe the syntax and semantics of any new protocol feature. The specification should be detailed enough to allow competing, interoperable implementations.
  5. Rationale — The rationale explains why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.
  6. Backward Compatibility — All SEPs that introduce backward incompatibilities must include a section describing these incompatibilities and their severity. The SEP must explain how the author proposes to deal with these incompatibilities.
  7. Reference Implementation — The reference implementation must be completed before any SEP is given status “Final”, but it need not be completed before the SEP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of “rough consensus and running code” is still useful when it comes to resolving many discussions of protocol details.
  8. Security Implications — If there are security concerns in relation to the SEP, those concerns should be explicitly written out to make sure reviewers of the SEP are aware of them.
See the SEP template for the complete file structure.

​
SEP States

SEPs can be in one of the following states:
  • draft: SEP proposal with a sponsor, undergoing informal review.
  • in-review: SEP proposal ready for formal review by Core Maintainers.
  • accepted: SEP accepted by Core Maintainers, but still requires final wording and reference implementation.
  • rejected: SEP rejected by Core Maintainers.
  • withdrawn: SEP withdrawn by the author.
  • final: SEP finalized with reference implementation complete.
  • superseded: SEP has been replaced by a newer SEP.
  • dormant: SEP that has not found a sponsor and was subsequently closed.

​
Status Management

The Sponsor is responsible for updating the SEP status. This ensures that status transitions are made by someone with the authority and context to do so appropriately. The sponsor:
  1. Updates the Status field directly in the SEP markdown file
  2. Applies matching labels to the pull request (e.g., draft, in-review, accepted)
Both the markdown status field and PR labels should be kept in sync. The markdown file serves as the canonical record (versioned with the proposal), while PR labels make it easy to filter and search for SEPs by status. Authors should request status changes through their sponsor rather than modifying the status field or labels themselves.

​
SEP Review & Resolution

SEPs are reviewed by the MCP Core Maintainers team on a bi-weekly basis. For a SEP to be accepted it must meet certain minimum criteria:
  • A prototype implementation demonstrating the proposal
  • Clear benefit to the MCP ecosystem
  • Community support and consensus
Once a SEP has been accepted, the reference implementation must be completed. When the reference implementation is complete and incorporated into the main source code repository, the status will be changed to “Final”. A SEP can also be “Rejected” or “Withdrawn”. A SEP that is “Withdrawn” may be re-submitted at a later date.

​
The Sponsor Role

A Sponsor is a Core Maintainer or Maintainer who champions the SEP through the review process. The sponsor’s responsibilities include:
  • Reviewing the proposal and providing constructive feedback
  • Requesting changes based on community input
  • Updating the SEP status as the proposal progresses through the workflow
  • Initiating formal review when the SEP is ready
  • Presenting and discussing the proposal at Core Maintainer meetings
  • Ensuring the proposal meets quality standards

​
Reporting SEP Bugs, or Submitting SEP Updates

How you report a bug, or submit a SEP update depends on several factors, such as the maturity of the SEP, the preferences of the SEP author, and the nature of your comments. For SEPs not yet reaching final state, it’s probably best to comment directly on the SEP’s pull request. Once a SEP is finalized and merged, you may submit updates by creating a new pull request that modifies the SEP file.

​
Transferring SEP Ownership

It occasionally becomes necessary to transfer ownership of SEPs to a new SEP author. In general, we’d like to retain the original author as a co-author of the transferred SEP, but that’s really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the SEP process, or has fallen off the face of the ‘net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don’t agree with the direction of the SEP. We try to build consensus around a SEP, but if that’s not possible, you can always submit a competing SEP. This document is placed in the public domain or under the CC0-1.0-Universal license, whichever is more permissive.