Mechanism to defer UIResource rendering for intermediate tool calls #402

Activity

1. idosal

   self-assigned this

   on Jan 29, 2026
2. idosal commented on Jan 29, 2026

   

   idosal

   on Jan 29, 2026

   Contributor

   More actions

   Thanks @JorisAndrade ! Currently, the spec implicitly assumes a new instance per invocation. 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 (please see #62).

   Now that the spec is stable, we can examine deferred approaches, such as referencing previously rendered instances using viewSessionId. We'd love to hear your thoughts and use cases to shape this part of the spec.

   MCP Apps doesn't assign any special meaning or behavior to priority.
3. JorisAndrade commented on Jan 30, 2026

   

   JorisAndrade

   on Jan 30, 2026

   Author

   More actions

   Yeah, my question is mostly about scenarios where MCP Apps is broadly adopted and the model chains or parallelizes multiple tool calls - e.g., "Look at GH issue X and draft an email."

   If GH returns a UIResource for the issue, it doesn't necessarily make sense for the Host to render it, since the model is only using the output as intermediate data - the user's intent is to see the email, not the issue.

   Should there be guidance (or a signal) for Hosts to distinguish between "UIResource as final output for the user" vs. "UIResource as intermediate data the model consumed"?
4. idosal commented on Jan 30, 2026

   

   idosal

   on Jan 30, 2026

   Contributor

   More actions

   Yeah, my question is mostly about scenarios where MCP Apps is broadly adopted and the model chains or parallelizes multiple tool calls - e.g., "Look at GH issue X and draft an email."

   If GH returns a UIResource for the issue, it doesn't necessarily make sense for the Host to render it, since the model is only using the output as intermediate data - the user's intent is to see the email, not the issue.

   Should there be guidance (or a signal) for Hosts to distinguish between "UIResource as final output for the user" vs. "UIResource as intermediate data the model consumed"?

   Thanks for the clarification!

   As far as the spec is concerned, if a tool with UI is called, the expectation is that it'll be rendered. The host/model can decide if that tool should be called, or if the UI should be terminated after it was rendered (ui/terminate-resource), as it has the context to make that decision (particularly across different apps).
   Having said that, views will soon have a way to request to be closed, and we may add the option for the server to request termination in the tool response metadata (if there's demand for it). I'm not sure that'll answer your use case, as apps are decoupled and don't know the order or intent behind their invocation.

   Servers can build around this. For example, this hypothetical GitHub MCP server may choose to have a tool to return the GitHub issue content and a different tool to display a GitHub issue view.

   Note that it quickly gets tricky. The model may actually want to display 2 different views, either inline in close proximity or even in a dedicated layout (e.g., the GitHub issue will be rendered in a sidepanel and the email would be rendered inline).

   I'd love to hear thoughts on this, and if there's anything you think we should change or clarify further.
5. JorisAndrade commented on Jan 30, 2026

   

   JorisAndrade

   on Jan 30, 2026

   Last edited by JorisAndrade

   Author

   More actions

   Right, but that would mean doubling the tool surface area (like get_issue vs show_issue for every tool with UI). Tool selection quality degrades as lists grow, and this pushes complexity to every server author.

   The core gap I see is:

   • The model knows whether a tool invocation is intermediate (data for further processing) or user-facing (the actual deliverable)
   • But the MCP Server returns _meta.ui regardless - it has no visibility into why the model called the tool
   • The Host renders based on _meta.ui presence, but also doesn't know the model's intent

   So there's no current mechanism for the model to signal "this tool call is just a step in my workflow, don't render the UI."

   Using ui/terminate-resource after the fact doesn't really help - the Host still fetches the resource and renders the iframe just to immediately tear it down. That's wasted work when we know upfront the result is intermediate.

   (Updated the issue title to better reflect where this discussion landed)
6. JorisAndrade

   changed the title [-]Clarify expected Host behavior when multiple tool calls return UIResources[/-] [+]Mechanism to defer UIResource rendering for intermediate tool calls[/+] on Jan 30, 2026
7. JorisAndrade

   changed the title [-]Mechanism to defer UIResource rendering for intermediate tool calls[/-] [+]Mechanism to defer `UIResource` rendering for intermediate tool calls[/+] on Jan 30, 2026