Preamble

• Title: Improve SEP Workflow for Early Feedback
• Authors: @pwwpche with the help of @kurtisvg
• Status: draft
• Type: Process
• Created: 2025-08-01

Abstract

This SEP proposes an evolution of the SEP process to provide earlier feedback and clearer contributor guidance. It introduces new states (Provisional, Prototyping, Deferred) and refines the workflow to be more interactive and predictable.

The goal is to make the contribution process more transparent and motivating, ensuring that at any point, an author knows the status of their SEP, the next steps, and the expectations for moving forward.

Motivation

The initial SEP process has successfully provided a structure for proposing changes. In the past month after SEP guidelines went public, over 20 SEPs were submitted by the community. As the community and the number of proposals grow, we have an opportunity to address several observed challenges:

1. Unclear Expectations: New authors may be unsure what to do after submitting a proposal or finding a sponsor, leading to stalled efforts.
2. Delayed Feedback: Without a formal stage for early review or early feedbacks, proposals can stay quiet without maintainer input. This can be discouraging and lead to authors abandoning potentially valuable ideas.
3. Wasted Effort: Authors may invest significant time writing a detailed specification for a proposal that is misaligned with the project's direction or duplicates other work, only to face rejection late in the process. This is a major source of contributor friction.
4. Bandwidth Bottlenecks: Maintainer attention naturally gravitates towards a few high-profile SEPs, leaving many smaller but still valuable proposals unreviewed.

To solve these problems, this proposal takes inspiration from mature governance models like the Kubernetes Gateway Enhancement Proposal (GEP) process. The guiding principle for this change is:

At any stage of the process, a SEP author should have a clear understanding of their proposal's status, a clear action item, and clear expectations for advancing to the next stage.

Specification

Updated SEP States

• proposal: SEP proposal without a sponsor.
• draft: SEP proposal with a sponsor.
• provisional (New): SEP with accepted goals and motivation, pending detailed specification.
• prototyping (New, Optional): A provisional SEP with optionally a working prototype for discussion and experimentation.
• in-review: A complete SEP ready for final review and acceptance.
• deferred (New, Optional): An in-review SEP with its final decision postponed by Core Maintainers.
• accepted: SEP formally accepted by Core Maintainers.

All other states remain unchanged.

Updated SEP Workflow

1. Discuss with the Community

Before writing a formal proposal, it is highly recommended to share your high-level idea with the MCP community. This is an informal step to test the waters and gather early feedback. Good places for this include a new GitHub Discussion or the MCP CWG Discord channels.

This initial discussion helps you quickly find out if others in the community have a similar need, if a similar idea has been discussed before, and if the idea generally aligns with the goal of MCP.

2. Create a SEP Proposal

Once your idea has received positive informal feedback, the first formal step is to create a SEP. Submit a new GitHub Issue using the SEP template. At this stage, you do not need to have every detail figured out. Your primary goal is to clearly explain the Abstract and Motivation. This allows Maintainers to understand the problem you are solving and the value your SEP brings.

Your SEP will be in the Proposal state. To advance to Draft state, 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. You can tag relevant maintainers from the maintainer list in your proposal.

3. Agree on the Goals

When a Maintainer agrees to sponsor your SEP, its status changes to Draft. Now, your goal is to work with your sponsor to go over the high-level direction of the proposal approved with other Maintainers and Core Maintainers. Refine the Motivation and the high-level parts of the Specification so that the core idea is clear.

This step is critical because it validates your idea before you invest significant time in technical details. Your sponsor will bring the SEP to the Maintainers and Core Maintainers for a high-level review. If the goals are accepted, the SEP moves to the Provisional state. This is a strong signal that the project wants this feature and you should proceed with confidence. If the idea is not a good fit, it will be changed to the Rejected state with clear feedback.

4. Detail the Specification and Prototype

With your SEP in the Provisional state, your goal is to develop the full technical details. Follow SEP Format and complete all remaining sections of the SEP document.

For many SEPs, especially those with complex changes, a working prototype is the best way to demonstrate the idea and gather concrete technical feedback. If you create one, your sponsor can change the state to Prototyping. This signals to the community that there is working code they can try.

Once the SEP document is complete and has been reviewed by your sponsor, it will be modified by your sponsor to the in-review state once it is in a good shape.

5. Undergo Formal Review

Now that the SEP is in-review, it is ready for a final, detailed review by the Core Maintainers. The focus of this review is on the technical soundness, completeness, and long-term implications of the specification. Your role is to be available to answer questions and clarify details.

After the review, the Core Maintainers will make a final decision. The SEP will be moved to one of three states:

• accepted: The proposal is fully approved.
• rejected: The proposal will not be implemented. A final rationale will be provided.
• deferred: The proposal is sound, but the team has decided to postpone a final decision, perhaps due to other priorities or dependencies. The SEP will be revisited in the future.

6. Complete the Reference Implementation

Once your SEP is accepted, the final step is to complete the work. This typically involves finishing the reference implementation, writing documentation, and getting the final pull requests merged. After all the associated work is merged into the main branch, the SEP is considered complete and its status will be changed to final.

Rationale

Annotations based on confidentiality and integrity provide a lightweight yet powerful mechanism to control data flows across tools in a standardized way. This is essential in environments with varied data sensitivity levels and risk profiles, such as enterprises managing both internal and public-facing workflows. The use of lattice models ensures policies can be formally verified and uniformly applied.

Unlike traditional data labeling or data classification systems as mentioned in this issue which often requires fine-grained, domain-specific expertise and extensive integrations, our annotations focus on a coarse-grained, fundamental set of attributes. This simplicity lowers the barrier for tool developers and enterprises to adopt security enforcement early, without the overhead of complex classification frameworks.

It is also important to acknowledge that data classification whether generated by tools, users, or automated systems cannot be fully relied upon as infallible. Classification errors, inconsistencies, or outdated labels are common in real-world deployments, which limits the effectiveness of fine-grained labeling alone as a security mechanism.

The current proposal does not include a mechanism for label declassification, which is the controlled downgrading of confidentiality or integrity levels to enable legitimate data flows from higher to lower security domains. Without declassification, the system enforces strict barriers that prevent any data labeled as "high" confidentiality from flowing to "low" confidentiality sinks.

While this strictness enhances security by preventing unauthorized disclosures, it also limits practical workflows where data must be intentionally and safely downgraded such as publishing reviewed content from internal systems to public platforms. The absence of declassification may lead to overly restrictive policies that block legitimate flows, forcing enterprises to rely on manual exceptions or external controls outside the annotation framework. Future enhancements could incorporate declassification as an explicit, policy-governed step with audibility, enabling secure and flexible information flows without compromising data protection.

Rationale

• The provisional state de-risks contribution. It provides an official, early checkpoint. Authors receive a clear signal on whether their idea is viable before they invest heavily in writing a detailed specification and implementation. This prevents the most painful kind of rejection and respects the contributor's time.
• The prototyping state improves technical review. For significant changes, abstract specifications can hide complexity. A prototype makes the proposal concrete, allowing the community and maintainers to provide much more specific and valuable feedback on the real-world impact.
• The deferred state improves transparency. It is an honest acknowledgement of maintainer bandwidth and project priorities. It's far better for an author to know their SEP is "on hold" than to hear nothing at all. This maintains trust and keeps the proposal in the official backlog.

Backward Compatibility

n/a