A company has built a useful MCP extension and wants it to become an official extension under the io.modelcontextprotocol prefix. Which sequence does the MCP project define?
Select an answer to reveal the explanation.
Short Explanation
Think of it like getting a bill passed: you file a formal proposal, prove it works, and the right committee signs off. The trap is thinking popularity or a registry listing makes an extension official.
Full Explanation
Official MCP extensions follow a SEP-based lifecycle. First, the proposer creates a Specification Enhancement Proposal in the main MCP repository using the standard SEP guidelines with the type Extensions Track. Second, at least one reference implementation in an official SDK is required before the SEP can be reviewed. Third, Core Maintainers review the SEP and hold final authority over inclusion. Fourth, once approved, a pull request adds the extension to the extension repository, after which other clients, servers and SDKs adopt it. The MCP Registry hosts server metadata, not extensions, and its maintainers have no role in promoting proposals. Extensions are deliberately kept out of the core specification, so merging the feature into a core revision is the wrong track; they live in ext- repositories and evolve independently. A Working Group can incubate an idea and produce deliverables such as SEPs, but it does not declare an extension official, and renaming a vendor identifier to the reserved io.modelcontextprotocol prefix without approval would violate the naming rules. Exam caveat: extension specifications must use RFC 2119 language and have an associated working or interest group. Operational check: confirm the SEP is labelled Extensions Track, links its SDK reference implementation, and records Core Maintainer approval.