Explore UI views that are not tied to specific tool calls

[liady]

Hypothesis: the core "attach a widget to a tool call" architecture is the part that doesn't hold up.

Who builds the UI - third-party, first-party, or model-generated - matters less than two things: the model choosing which UI to show and when, and a feedback loop that gives it signal on whether that choice was good.
Today an MCP App view is meant as a template for a tool response. But we increasingly see use cases where a company wants to define UI for data the model produces, regardless of where that data originated. The data/visualization split — companies shipping two tool sets, one for data and one for rendering - keeps coming up, and we should probably recommend it as best practice.

A model where MCP Apps expose views with an input schema, not bound to a specific tool call, could work much better if the feedback loop exists. We tried to approximate this by recommending dedicated render* tools, but conventions don't get followed.

[hydrosquall]

I like the pattern of used by the Jupyter ecosystem (computational notebooks), which allows the user to register custom MimeTypes https://docs.jupyter.org/en/latest/reference/mimetype.html. Under the hood these are configuring some HTML (example) . The data in the JSON payload is interpolated into the HTML safely to create a custom viewer.

Example use cases

• General purpose: letting people create custom renderers for common data formats like CSV or JSON (view as collapsible tree, table).
• Company specific: letting partners provide custom renders for proprietary formats, like a product listing, chart widget, scientific data format

Prior work:

The Vega graphing library (link) was able to a custom extension to the Jupyter ecosystem for rendering graphs in a notebook . There are many other popular extensions

https://jupyterlab.readthedocs.io/en/stable/api/variables/vega5-extension.VEGA_MIME_TYPE.html

Related issues

This topic could potentially be merged with #654 if the proposed surfaces (such as video, image) are available within HTML/web browsers, but we wanted to let the model have a simpler API (return a URL instead of generating a throwaway HTML page containing a URL) to provide rich/media/interactive data content.

[Chipagosfinest]

Farcaster Mini Apps and Telegram Mini Apps are useful evidence that an app-level entrypoint should be independent of the operation that produced its data.

• A Farcaster Mini App manifest declares a homeUrl, while embeds, universal links, catalog launches, and notifications can open other paths with typed launch context.
• Telegram Mini Apps can launch from profiles, menu/keyboard/inline buttons, direct links with start_param, and attachment menus. The same app can therefore start in several contexts without inventing a synthetic “render this UI” backend operation for each one.

That suggests a clean separation for MCP Apps:

1. App entrypoint/view declaration: logical ID, input schema, display constraints, and required/optional host capabilities.
2. Launch binding: tool result, direct user launch, deep link, notification, host surface, or model selection supplies input and launch context.
3. Data operations: server tools/resources remain callable by the app/model but are not required to masquerade as render tools.
4. Feedback: the host can record whether a proposed view was shown, dismissed, interacted with, or replaced without treating engagement as proof that the model's choice was correct.

I would avoid binding the portable identity to an HTML resource URI. A logical entrypoint should be able to change resource versions, and one entrypoint may have degraded or host-specific renderers later. Likewise, launch parameters should be typed but untrusted by default; authenticated or authorization-bearing context needs a separate integrity/audience/expiry contract.

A narrow first slice could be a view declaration with an inputSchema, a stable logical entrypoint ID, and an optional association from existing tool metadata. That keeps current tool-linked behavior backward compatible while allowing a host/model to discover and instantiate the view directly. The broader descriptor and pre-connect discovery questions belong in #670.

[fredericbarthelet]

I'd even make the case that the need extend even further. Some host already rely on conventioned names for specific UI display, like the 3 OpenAI use cases for restaurant reservation, get quote and product checkout. All 3 are tied to no-op tools that reference views dedicated to be host-controlled (the host can open the UI from its own rather than from a model-chosen tool result).

I understand the need for an inputSchema on those tool-less views in order for the model to craft the correct props for rendering. But how would you expose the intent of each view to the model?