I want users to work in an MCP App and talk to the assistant at the same time, with both visible.
For example, the app shows a document with charts and editable criteria. The user asks about a chart in chat, selects results in the app, and clicks "Compare." The assistant responds in the same conversation and updates the document beside it.
That side-by-side interaction is the experience we're trying to build. Users need to see what they're discussing while they discuss it.
MCP Apps has useful pieces for this already. I'd like to understand how far the current protocol takes us, what depends on the host, and where there are gaps.
1. Keep the app and conversation visible
The user says "open the analysis app." It opens beside the conversation.
From there:
- Typing in chat keeps the app visible.
- Interacting with the app keeps the conversation visible.
- Scrolling the conversation doesn't scroll the app away.
- Later tool calls update the existing view.
- Navigation within the app preserves its association with the conversation.
- The user can resize, close, and reopen the pane.
An inline widget can disappear as the conversation grows. Fullscreen requires switching away from chat. Neither gives us this workflow.
The split display mode proposal looks relevant. How would it work with reusable views so later actions keep updating the same pane?
Can the host advertise support for this experience so the app can offer a fallback when it isn't available?
2. Keep app actions associated with the right conversation
The user opens the app from conversation A, briefly switches to conversation B, then clicks "Compare selected results" in the app.
That action should go to A. If A is no longer available, the app should know.
The user shouldn't need to copy conversation IDs, reconnect after every navigation, or return to chat and type "I've finished connecting."
What association can an app rely on? Does it survive a reload or reopening the view? An opaque host-managed association would be enough.
3. Let users answer in chat or in the app
The assistant asks which regions to include. The user can type "France and Germany" or select those countries in the app.
Either path should save the answer and let the workflow continue. If the user already answered in chat, an older form shouldn't overwrite that answer.
Sometimes the app is answering a question the assistant is waiting on. Other times, a button requests new work. The app-rendered elicitation proposal seems relevant to the first case.
What's the intended pattern for supporting both without asking the user twice?
4. Show saved changes as the assistant works
The assistant saves a title, adds criteria, and later adds analysis results. Each saved change should appear in the document the user is already looking at.
Some updates may come from background work after the original tool call has returned. The user shouldn't need to refresh the page or ask the assistant to reopen it.
The application can own persistence. How should the open view learn that its data changed, including after a disconnect? Should it subscribe through the host, connect to its backend, or support both?
The subscription discussion appears to cover part of this.
5. Separate editing from requesting assistant work
A user changes three filters, then clicks "Recalculate."
The edits should save without starting three assistant turns. The button should request work against the final selection.
If the user changes the filters again while the assistant is working, the application needs to distinguish those newer edits from the version the assistant used.
ui/update-model-context and ui/message seem to provide the basic separation. Is there recommended guidance for associating a request with a saved revision? I'd expect the application to own revision checks.
6. Make button outcomes observable
After the user clicks "Compare selected results," several things can happen:
- The host starts a turn.
- The host queues it because the assistant is busy.
- The host asks for consent.
- The host rejects the request.
- The connection drops before the app receives an answer.
The app needs enough information to show a useful status. If it offers a retry, that shouldn't accidentally start the same work twice.
I understand from the discussion on automatic prompting that ui/message already supports prompting and the host controls scheduling and consent.
What can the app observe after submission? Can it correlate the request with execution, distinguish acceptance from completion, and recover its status after reconnecting?
7. Reopen without losing or repeating work
The user closes the pane while analysis is running and opens it later.
They should get the saved document and current progress. Reopening shouldn't rerun the original operation.
Keeping an iframe alive and restoring a saved document are different requirements. What should the host retain, what should the application restore, and how does the reopened view associate with the conversation?
What I'm asking for
Could we document a reference flow for this side-by-side experience and build a small example to test across hosts?
A document with a chart, editable filters, and a "Compare selected" button would exercise most of these cases.
I'd like to establish:
- What works with the current protocol.
- Which behaviors depend on the host and how an app discovers support.
- Which gaps need protocol changes.
- What the application should implement itself.
One scope question matters too. Does this require a host-rendered MCP App, or is there a supported way for an existing web app opened beside the conversation to participate?
The goal is a complete interaction: open the app beside chat, work through either interface, see changes as they happen, and resume later without repeating setup.
I'm happy to help build the example app, test this across hosts, or contribute to a proposal if there are gaps we need to address.
I want users to work in an MCP App and talk to the assistant at the same time, with both visible.
For example, the app shows a document with charts and editable criteria. The user asks about a chart in chat, selects results in the app, and clicks "Compare." The assistant responds in the same conversation and updates the document beside it.
That side-by-side interaction is the experience we're trying to build. Users need to see what they're discussing while they discuss it.
MCP Apps has useful pieces for this already. I'd like to understand how far the current protocol takes us, what depends on the host, and where there are gaps.
1. Keep the app and conversation visible
The user says "open the analysis app." It opens beside the conversation.
From there:
An inline widget can disappear as the conversation grows. Fullscreen requires switching away from chat. Neither gives us this workflow.
The split display mode proposal looks relevant. How would it work with reusable views so later actions keep updating the same pane?
Can the host advertise support for this experience so the app can offer a fallback when it isn't available?
2. Keep app actions associated with the right conversation
The user opens the app from conversation A, briefly switches to conversation B, then clicks "Compare selected results" in the app.
That action should go to A. If A is no longer available, the app should know.
The user shouldn't need to copy conversation IDs, reconnect after every navigation, or return to chat and type "I've finished connecting."
What association can an app rely on? Does it survive a reload or reopening the view? An opaque host-managed association would be enough.
3. Let users answer in chat or in the app
The assistant asks which regions to include. The user can type "France and Germany" or select those countries in the app.
Either path should save the answer and let the workflow continue. If the user already answered in chat, an older form shouldn't overwrite that answer.
Sometimes the app is answering a question the assistant is waiting on. Other times, a button requests new work. The app-rendered elicitation proposal seems relevant to the first case.
What's the intended pattern for supporting both without asking the user twice?
4. Show saved changes as the assistant works
The assistant saves a title, adds criteria, and later adds analysis results. Each saved change should appear in the document the user is already looking at.
Some updates may come from background work after the original tool call has returned. The user shouldn't need to refresh the page or ask the assistant to reopen it.
The application can own persistence. How should the open view learn that its data changed, including after a disconnect? Should it subscribe through the host, connect to its backend, or support both?
The subscription discussion appears to cover part of this.
5. Separate editing from requesting assistant work
A user changes three filters, then clicks "Recalculate."
The edits should save without starting three assistant turns. The button should request work against the final selection.
If the user changes the filters again while the assistant is working, the application needs to distinguish those newer edits from the version the assistant used.
ui/update-model-contextandui/messageseem to provide the basic separation. Is there recommended guidance for associating a request with a saved revision? I'd expect the application to own revision checks.6. Make button outcomes observable
After the user clicks "Compare selected results," several things can happen:
The app needs enough information to show a useful status. If it offers a retry, that shouldn't accidentally start the same work twice.
I understand from the discussion on automatic prompting that
ui/messagealready supports prompting and the host controls scheduling and consent.What can the app observe after submission? Can it correlate the request with execution, distinguish acceptance from completion, and recover its status after reconnecting?
7. Reopen without losing or repeating work
The user closes the pane while analysis is running and opens it later.
They should get the saved document and current progress. Reopening shouldn't rerun the original operation.
Keeping an iframe alive and restoring a saved document are different requirements. What should the host retain, what should the application restore, and how does the reopened view associate with the conversation?
What I'm asking for
Could we document a reference flow for this side-by-side experience and build a small example to test across hosts?
A document with a chart, editable filters, and a "Compare selected" button would exercise most of these cases.
I'd like to establish:
One scope question matters too. Does this require a host-rendered MCP App, or is there a supported way for an existing web app opened beside the conversation to participate?
The goal is a complete interaction: open the app beside chat, work through either interface, see changes as they happen, and resume later without repeating setup.
I'm happy to help build the example app, test this across hosts, or contribute to a proposal if there are gaps we need to address.