​
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.

Because the SEPs are maintained as text files in a versioned repository (GitHub Issues), their revision history is the historical record of the feature proposal.

​
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 a 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.

​
SEP Workflow

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.

​
SEP Author

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.

​
Submitting a SEP

SEPs should be submitted as a GitHub Issue in the specification repository. The draft must be written in the style of this SEP and must include:

  • A clear and concise title
  • A written motivation and rationale for the change
  • A pull request with the changes to the specification
  • Example code and usage patterns
  • Backwards compatibility analysis
  • Security analysis
  • At least one reference implementation

The standard SEP workflow is:

  1. You, the SEP author, create a well-formatted GitHub Issue with the proposal and SEP tags
  2. Find a Core Maintainer or Maintainer to sponsor your proposal. Core Maintainers and Maintainers will regularly go over the list of open proposals to determine which proposals to sponsor. Once a sponsor is found, the sponsor is “assigned” to the issue and a milestone is assigned. The tag draft is added. At this point a unique SEP number is assigned.
  3. The sponsor will review and may request changes before formal review, based on community feedback. Once ready for review, the tag in-review is added.
  4. Once sponsored, the SEP enters formal review by the core team
  5. The SEP may be accepted, rejected, or returned for revision.
  6. If the SEP has not found a sponsor within three months, core-maintainers are free to close the SEP as dormant.

​
SEP States

SEPs can be one one of the following states

  • proposal: SEP proposal without a sponsor.
  • draft : SEP proposal with a sponsor.
  • in-review: SEP proposal ready for review.
  • accepted: SEP accepted by core maintainers, but still requires final wording and reference implementation.
  • rejected: SEP rejected by core maintainers.
  • withdrawn: SEP withdrawn.
  • final: SEP finalized.
  • superseded: SEP has been replaced by a newer SEP.
  • dormant: SEP that has not found sponsors and was subsequently closed.

​
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.

​
What belongs in a successful SEP?

Each SEP should have the following parts:

  1. Preamble — A short descriptive title, the names and contact info for each author, the current status.
  2. Abstract — a short (~200 word) description of the technical issue being addressed.
  3. Motivation — The motivation is critical for SEPs that want to change the Model Context Protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the SEP solves. SEP submissions without sufficient motivation may be rejected outright.
  4. Rationale — The rationale fleshes out the specification by describing what motivated the design and 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.
  5. 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. A PR with the changes to the specification should be provided.
  6. Backwards Compatibility — All SEPs that introduce backwards 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.

​
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 send your comments and changes directly to the SEP author. Once SEP is finalized, you may want to submit corrections as a GitHub comment on the issue or pull request to the reference implementation.

​
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.