Re-usable views

[idosal]

Currently, the spec assumes a new view is rendered per tool call. Hosts may decide to implement variations of their own layout (e.g., a persistent side panel), but each invocation would still create a new instance under the hood. This approach was chosen to simplify the model for the MVP (#62).

Now that the spec is stable, we can examine deferred approaches, such as referencing previously rendered instances using viewSessionId (#295).

[sam-mfb]

One use case for this is a situation like a board game where the AI plays its turns via direct tool calls and the user plays turns via view interactions. A nice experience would be for the view to not reload when context opens, but just receive new state and update. There may be more serious versions of this, but the concept is the same -- both the user and the model are exchanging interactions with the view being a shared "workspace".

[carstonhernke]

Here is a use case that I am working on - a client-side map data visualization tool. This architecture is similar to Figma or Draw.io - most of the processing is done within the browser itself. Today users interact with the application (change the state) via the UI (add map layers, add filters, change the title), however in the future I envision LLMs/agents also being able to interact with the application (change the state) via postMessage().

I think a nice demo use case would be editing technical diagrams that are written in Mermaid Syntax - AI tools are very good at writing these.

Today the interaction goes one way:
Ask LLM to generate diagram → LLM writes Mermaid Syntax → Renders to show user. User must then export to draw.io/lucidchart to edit with a UI

It could look like this:
Ask LLM to generate diagram → LLM writes Mermaid Syntax → Loads MCP UI instance that renders Mermaid Syntax → User renames boxes in diagram → LLM receives updated state via postMessage() → Interaction loop continues

I think the main thing needed to accomplish this is a persisted UI instance that is loaded once, and then has an internal state and can receive & send with postMessage().

Theoretically web applications can be designed to be stateless and render a given config each time they are loaded. However, there are still significant 'setup' tasks like loading external resources and setting up the DOM that would affect the UI if they had to be repeated every turn in the conversation.

Some questions come to mind:

• How is the history of a conversation with multiple turns rendered?
• Can a user 'undo' actions? Is branching supported?
• How is state persisted between sessions? The MCP server could maintain it's own state ('save my diagram for later'), or would the embedded iframe use localStorage/OPFS, or would the AI host remember tool usage/arguments?

[petrbroz]

Thank you @idosal for submitting this. Adding another use case:

I'm building an MCP server that embeds an interactive 3D viewer for CAD designs. The intended conversation flow looks like this:

Show me building XYZ

Isolate all doors

Color-code the doors by their material

Each of these steps calls a different tool (preview_design, highlight_objects, color_objects), but all three should act on the same viewer instance. The 3D model is already loaded and initialized, re-loading it from scratch on every tool call takes several seconds and loses transient state like camera position, active selection, and visual overrides.

[psylch]

Same experience here — I built a Mermaid diagram editor as an MCP App and the state loss on each tool call is the main UX issue. Zoom, pan, selection, pending edits all gone. Looking forward to viewSessionId.