Description

Update sep-guidelines.mdx to require reference implementation prior to formal review.

Motivation and Context

This PR arises from a discussion in the maintainers' channel of the MCP Contributors' Discord.

From the current SEP Guidelines:

Finalization: Once accepted, the reference implementation must be completed. When complete and incorporated into the specification, the sponsor updates the status to final.

It would be beneficial to require reference implementations prior to SEP acceptance. Very simple ones might be safe to evaluate without it, but SEPs that have a lot of impact to the spec (e.g., Tasks, MCP Apps) should have a reference built and worked with / evaluated by the maintainer community prior to acceptance.

In the case of MCP Apps, Goose and MCPJam have independently built support for the proposed spec prior to adoption. This will provide a a feedback mechanism so that perhaps when it is adopted, it will be in its best shape.

Of course, all SEPs will not attract unprompted community implementations prior to the spec's acceptance. By requiring the reference first, at least the proposer will have a chance to work through their ideas and optimize the SEP for real world use. And the core maintainers can see what the actual implementation implications will be prior voting on it.

For instance, the Server Variants SEP seems like a good idea, and promises a reference implementation upon acceptance. But it is sufficiently complex that some actual testing should be done to see if it will actually work, and if it is optimal.

Otherwise, we end up with spec changes based upon a proposal alone and when real world issues show up in implementation, there's no easy / clean way to undo it or modify it toward its optimal shape.

How Has This Been Tested?

Served docs locally, and proofread.

Breaking Changes

Nope.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context