A vendor adds a _meta key named dev.mcp/trace to carry its own tracing data in requests. A reviewer flags the key during code review. What is wrong with it?
Select an answer to reveal the explanation.
Short Explanation
Look at the second label in the prefix. If it's mcp or modelcontextprotocol, that namespace belongs to MCP, not to you. dev.mcp/ trips that wire, while something like com.example/ is all yours.
Full Explanation
The _meta key format allows an optional prefix made of dot-separated labels followed by a slash, and implementations SHOULD use reverse DNS notation such as com.example/. The specification reserves for MCP any prefix in which the second label is modelcontextprotocol or mcp, and it gives io.modelcontextprotocol/, dev.mcp/, org.modelcontextprotocol.api/ and com.mcp.tools/ as reserved examples, while noting that com.example.mcp/ is not reserved because its second label is example. A vendor using dev.mcp/trace is therefore squatting in the protocol's namespace and should move the key under its own reverse-DNS prefix. Saying vendors may not use _meta at all is wrong; _meta exists so clients and servers can attach additional metadata, and third-party extensions define keys under their own vendor prefix. Requiring forward DNS order inverts the guidance, which recommends reverse DNS. Claiming only io.modelcontextprotocol/ is reserved ignores the second-label rule, which covers far more than that single prefix. Exam caveat: traceparent, tracestate and baggage are reserved without a prefix for OpenTelemetry trace context, which may be what this vendor actually needs. Operational check: list every custom _meta key the vendor emits and confirm none has mcp or modelcontextprotocol as its second label.