Support for non-HTML View mimetypes
The current spec locks the View mimetype to text/html;profile=mcp-app. This was a deliberate MVP choice but the longer-term goal has always been to broaden this.
Filing this issue to start the conversation on what comes next and track the design discussion in one place.
Possible use cases:
- Generative UI use cases
- Non-HTML surfaces
The MVP currently leaves out some cases - most notably generative UI, where the server returns a JSON description and the host renders it with its own components. Remote DOM lands in similar territory, and native (non-web) hosts that might not be able to rely on HTML at all.
Currently mimeTypes is an array in capability negotiation, _meta.ui is mimetype-agnostic, and most ui/* methods (lifecycle, tool-input/result, host-context, display modes) don't depend on HTML.
Suggestion
We might want a path for adding new profiles (MIME naming convention, interactivity considerations, etc.)
Opening for discussion
- Should we support additional mime types, if so should the list be pre-defined or open?
- For generative UI purposes - should we rely on existing standards / specs with capabilities negotiation?
- Should we separate the generative UI discussion from the non-html surfaces discussion?
(also see #169)
Support for non-HTML View mimetypes
The current spec locks the View
mimetypetotext/html;profile=mcp-app. This was a deliberate MVP choice but the longer-term goal has always been to broaden this.Filing this issue to start the conversation on what comes next and track the design discussion in one place.
Possible use cases:
The MVP currently leaves out some cases - most notably generative UI, where the server returns a JSON description and the host renders it with its own components. Remote DOM lands in similar territory, and native (non-web) hosts that might not be able to rely on HTML at all.
Currently
mimeTypesis an array in capability negotiation,_meta.uiis mimetype-agnostic, and mostui/*methods (lifecycle, tool-input/result, host-context, display modes) don't depend on HTML.Suggestion
We might want a path for adding new profiles (MIME naming convention, interactivity considerations, etc.)
Opening for discussion
(also see #169)