Principle
Separate user-visible UI state from model-visible context
What the user can see and what the model must receive are different design decisions.
When it fits
- An interactive AI tool shows rich application state but the model does not need every displayed field to continue the task.
When to avoid it
- Client implementations and protocol features differ. Verify the actual host's context-sharing behavior rather than assuming a privacy boundary exists.
Why it matters
Define which UI changes must return to the model, which can stay local to the interactive component and which require explicit user action before sharing. This can reduce context noise and unnecessary exposure while keeping the interface useful.
An example
A planning widget can display all editable form fields to the user while sending only the changed date and selected option back to the model.
Check your result
Every model-visible UI update has a task reason; rich display state is not copied into context by default.
Keep this limit in mind
- Client implementations and protocol features differ. Verify the actual host's context-sharing behavior rather than assuming a privacy boundary exists.
Evidence and sources
Interactive agent applications can separate information displayed to the user from information sent back into the model context.
Exact MCP App capabilities vary by client and protocol revision; privacy still depends on the host and tool implementation honoring the boundary.
MCP Apps: Primitives, Discovery, and the Future of Software · 10:01-16:36, application messages, streamed inputs and separation of user-visible state from model-visible context