2026-01-26 protocol does not define a general state restoration API; it lists persistence and restoration as future work. updateModelContext() shares context with the model on later turns, but it is not a durable store for the View.
Choose a state owner
Keep account data and saved work on the server. Store a stable record ID in the tool input or result, then use that ID for later reads and writes. A fresh random ID on every tool call cannot identify the same record after a reload.
Restore durable state through tools
Register app-only tools for loading and saving state, with_meta.ui.visibility: ["app"]. The View calls them through the host with callServerTool():
documentId on every call. Tool visibility controls whether the model or View can call a tool; it does not authorize access to records. See Tool _meta and the MCP Apps Security Model.
Keep the ui:// HTML resource independent of the user’s saved state. Hosts may cache the resource; return user data from tool calls instead.
Share only model-relevant state
After a selection changes, callupdateModelContext() when the model needs to understand it on the next turn:
useAppState() pairs React state with this context update; it does not reload state after the View is destroyed.
Use browser storage only as a fallback
Browser storage can remember a harmless UI preference within the same sandbox origin. Check that it is available, handle storage errors, and use a stable key such as a document ID. Do not put tokens, drafts, or other sensitive data there. Host-specific sandbox origins and storage policies mean a value saved in one host may not exist in another. For a View that must work across hosts or devices, restore from server tools and treat browser storage as an optional convenience.Primary reference
The MCP Apps2026-01-26 specification defines ui/update-model-context and lists state persistence and restoration as future work.