Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions docs/community/sep-guidelines.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -34,6 +34,14 @@ There are three kinds of SEP:
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.

### Examples of SEP Types

Here are concrete examples for each SEP type:

1. **Standards Track** — Asynchronous support in MCP ([Transport-agnostic resumable streams #899](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/899))
2. **Informational** — Load balancing with MCP ([Add best practices when using load balancer #325](https://github.com/modelcontextprotocol/modelcontextprotocol/issues/325))
3. **Process** — MCP Registry ([https://github.com/modelcontextprotocol/registry](https://github.com/modelcontextprotocol/registry))

## 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.
Expand Down