[RFC] Session Resilience & Lifecycle Management for Heavy Server-Side Rendered UIs (WebRTC/CAD)

Context / Motivation with reference to https://youtu.be/-jY2T2PiJBE?si=3q13bAwKw55OsyBd

As the MCP Apps specification matures into a global UI standard, it opens the door for heavy industrial software ecosystems—such as automated CAD configuration and cloud-native manufacturing platforms—to live directly inside the Agentic Web [00:10:12, 00:13:14].

Platforms built on modern API-first geometry kernels (like Zoo.dev/KittyCAD) utilize server-side GPU rendering streamed via WebRTC to deliver interactive 3D STEP models with ultra-low latency. Unlike standard web components or static HTML views, a WebRTC stream relies on a persistent, stateful network session (RTCPeerConnection).

Currently, the speculative nature of host clients (e.g., ChatGPT, Claude) often triggers components to unmount and re-render entirely as the chat context rolls forward or shifts focus [00:01:42, 00:05:34]. For heavy 3D WebRTC renderers, a full DOM re-render tears down the WebRTC connection, causing severe latency overhead, a broken user experience, and unnecessary server-side GPU/signaling resource pooling.

Following up on the committee’s discussions regarding "Reusable Views" for heavy renderers like Autodesk (as mentioned in the recent MCP Apps roadmap), we would like to formally propose a standardization path for session resilience and declarative view mutation [00:14:20].

The Problem Space for Heavy 3D/CAD Apps

1. Connection Lifecycle Invalidation: When a host client triggers a full re-load of an app iframe/sandbox, the underlying signaling and peer connections die instantly.

2. State Decoupling: Heavy applications need a standard way to separate Routinary Interaction (e.g., camera rotations, hover highlights via RTCDataChannel) from Business/Parameter Mutations (e.g., changing a CAD model's width parameter via an LLM tool call) [00:06:04, 00:14:51].

3. Infrastructure Waste: Re-initializing heavy 3D cloud sessions on every chat scroll strains server-side pooling, limiting the massive distribution scalability promised by MCP Apps [00:17:14]

Proposed Solutions / Feature Requests

1. Persistent Context / viewId Lifecycle GuaranteesWe need a native way for the MCP Server to pass a unique identifier (e.g., viewId or sessionId) that tells the host client: "Keep this specific sandbox instance alive in the background; do not destroy the DOM node on context update." [00:14:20]

2. Declarative UI Mutation (View Tools Expansion)
   Expand the "View Tools" concept so that the host can patch the application's underlying JSON state directly without forcing a visual reset [00:14:51]. For example, a CAD model change should follow a strict declarative pattern:
   {
   "parameters": { "dimensions": { "length": 1500 }
   }
   }
   The application should receive this mutation over the existing MCP callback channel, update the 3D canvas server-side, and push the newly rendered frames over the existing WebRTC channel seamlessly—keeping the camera view, zoom, and connection intact [00:06:04].

3. Ephemeral vs. Hardened State Tracking
   Standardize a protocol mechanism that differentiates between:
   • Ephemeral Client State: Camera vectors, mouse coordinates, and connection logs (which the LLM doesn't need to track in its context window for auditability) [00:12:33].
   • Hardened App State: The final product configuration (which must flow back into the agentic loop) [00:00:32].

We Believe This Matters for the MCP Ecosystem

Standardizing this will unlock a completely new vertical for MCP Apps, allowing heavy engineering, medical imaging, and 3D configuration tools to scale organically to hundreds of millions of weekly users without crippling server infrastructures [00:17:14].
We would love to collaborate on the spec, participate in the tri-weekly working group meetings, and share engineering benchmarks from our cloud-CAD configuration architecture [00:04:26].

The issue names no files, tests, or entry points. Start by reviewing the MCP Apps specification and the existing View Tools and session-lifecycle concepts, then determine the protocol changes needed for persistent views, declarative mutations, and ephemeral versus hardened state; done requires an agreed standardization path.