A company that owns the domain example.com is publishing its first third-party MCP extension, a feature it calls audit-trail. Which extension identifier follows the MCP naming guidance?
Select an answer to reveal the explanation.
Short Explanation
You write your company's name backwards, like a Java package, and then add the feature name. The trap is borrowing the io.modelcontextprotocol prefix, which is reserved for official extensions only.
Full Explanation
Extension identifiers use the format vendor-prefix slash extension-name and follow the same rules as _meta keys, with a mandatory prefix. Official extensions use the io.modelcontextprotocol prefix. For third-party extensions, the guidance is to use a reversed domain name the organization owns as the vendor prefix, similar to Java package naming, so a company owning example.com uses com.example and an identifier such as com.example/audit-trail. Using io.modelcontextprotocol would claim official status; prefixes whose second label is modelcontextprotocol or mcp are reserved for MCP use, so a third party must not use them. example.com/audit-trail puts the domain in forward order; the _meta naming rules say implementations should use reverse DNS notation, and forward-order names collide more easily and break the convention every implementation expects. audit-trail/com.example reverses the two segments, placing the name where the prefix belongs, so it does not match the required prefix-then-name structure. Exam caveat: if a later change to the extension is unavoidably breaking, the guidance is to adopt a new identifier such as one with a -v2 suffix, while compatible changes should use capability flags or versioning inside the extension's settings object. Operational check: confirm the organization controls the domain behind the prefix and that the identifier appears identically in client capabilities and server/discover.