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.
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.