A contributor wants the MCP specification to add a new capability that every client and server could negotiate. How are proposed changes to the specification submitted?
Select an answer to reveal the explanation.
Short Explanation
The spec has a front door for change, and it's called a SEP. You write the proposal, the community weighs in, and the design decision gets recorded. Shipping it in one SDK first or listing it in the registry doesn't change the spec at all.
Full Explanation
MCP's governance document states that proposed changes to the specification must be submitted as Specification Enhancement Proposals. SEPs are the primary mechanism for proposing major new features, collecting community input and documenting design decisions, and the SEP guidelines define their format, sponsorship and status workflow. Core Maintainers steer the specification and approve proposals through the governance decision process, with Lead Maintainers holding final authority. A pull request to an SDK changes that SDK's code; SDKs implement the specification, they do not define it, and an SDK feature is not adopted into the spec simply by shipping. Interest Groups identify and articulate problems through open discussion; Working Groups produce deliverables such as SEPs, and neither amends the specification by majority vote. The MCP Registry catalogs published servers using server.json metadata and reverse-DNS names; declaring something there has no effect on the protocol. Exam caveat: deprecating a feature is also a specification change and therefore also requires a SEP, which must document the migration path and the minimum deprecation window. Operational check: before proposing, search existing SEPs and Working Group discussions for overlapping work, then draft the SEP using the published guidelines and find a Maintainer or Core Maintainer sponsor.