Is there a reason the _meta fields are not prefixed?

[mkouba]

Pre-submission Checklist

• I have checked that this question would not be more appropriate as an issue in a specific repository
• I have searched existing discussions and documentation for answers

Question Category

• Protocol Specification
• SDK Usage
• Server Implementation
• General Implementation
• Documentation
• Other

Your Question

If I understand it correctly, a tool _meta may contain a key ui (with no prefix, see https://modelcontextprotocol.io/specification/2025-11-25/basic/index#_meta) and the value is an object that contains for example property resourceUri.

Is there a reason a reserved prefix (e.g. mcp) is not used? That would help to resolve ambiguities and collisions. So instead of _meta["ui"].resourceUri the apps would use _meta["mcp/ui"].resourceUri.

[Michael-WhiteCapData]

The namespace is the ui object itself. MCP Apps owns the shape of _meta.ui, and all of the extension's fields live below it (resourceUri, visibility, csp, permissions, and so on). That gives one collision boundary instead of repeating a prefix on every leaf key.

Using mcp/ui would also be slightly misleading: Apps is an MCP extension, not a core-protocol field. The extension is identified by the reserved label io.modelcontextprotocol/ui, and the Apps specification separately reserves the ui:// resource scheme. Hosts negotiate support for that extension and then interpret _meta.ui according to its schema.

So the intended convention is:

{
  "_meta": {
    "ui": {
      "resourceUri": "ui://example/view",
      "visibility": ["model", "app"]
    },
    "com.example.myExtension": {
      "customField": true
    }
  }
}

A vendor adding unrelated metadata should use a domain-qualified namespace it controls rather than adding arbitrary children to ui. That is where collision avoidance matters.

The specification's design notes explicitly say the nested _meta.ui structure was chosen to group UI metadata cleanly, and it reserves io.modelcontextprotocol/ui: Apps specification. The older flat _meta["ui/resourceUri"] spelling is deprecated in favor of this nested namespace.

[mkouba]

I do understand that io.modelcontextprotocol/ui is the id of the MCP Apps extension. However, from what I know, the spec does not allow an extension to reserve a bare name in the _meta. Even the built-in keys, like io.modelcontextprotocol/protocolVersion , are always prefixed. The only unprefixed keys in the spec are ones the base spec grants itself as explicit exceptions - progressToken, and the OpenTelemetry keys.

Moreover, the spec states: "Official extensions define additional _meta keys under the io.modelcontextprotocol/ prefix, and third-party extensions use their own vendor prefix. In both cases the keys are specified in the extension’s documentation." See also https://modelcontextprotocol.io/specification/2026-07-28/basic#_meta.

So IIUIC, the MCP Apps extension should use the io.modelcontextprotocol/ui prefix instead, i.e. _meta.ui.resourceUri should become _meta["io.modelcontextprotocol/ui"].resourceUri.

Now, _meta["io.modelcontextprotocol/ui"].resourceUri is obviously not very convenient, which is why I originally proposed something shorter like mcp/ui. But that particular form doesn't help either - the reservation rule is worded as "any prefix where the second label is modelcontextprotocol or mcp", and a single-label prefix like mcp/ has no second label, so it isn't reserved for MCP at all.

[Michael-WhiteCapData]

You are right. My earlier reply confused the extension identifier with reservation of the ui key. Grouping fields under ui does not establish that the key is reserved.

The base specification assigns official extensions the io.modelcontextprotocol/ prefix, while the Apps draft still specifies _meta.ui.resourceUri. This appears to be a specification mismatch that needs maintainer clarification.

Your point about mcp/ is also correct: it has no second label, so that reservation rule does not cover it. My vendor example would be clearer as _meta["com.example/myExtension"].

For now, I would follow the documented Apps format rather than assume a replacement key is supported. Thank you for the correction.