Host support for persistent (pip/pinned) app views: clinical use case where inline rendering breaks the core loop

Open
#754 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
api, frontend

Research direction

Start by reviewing the persistent/pinned direction in the spec and the existing requestDisplayMode("fullscreen") behavior. Define host behavior that keeps an app view visible while the transcript scrolls, preserves the conversation, and avoids duplicate views on repeated tool calls.

Written by the indexing model from the issue text.

Description

We build an OCD treatment program (Conicia) and ship an MCP app: swipeable lesson cards patients work through inside the chat, with a conversational layer around them (the assistant discusses the material, and a guardrail routes compulsive reassurance-seeking to in-the-moment tools).

Inline rendering breaks the core loop. The patient reads a card, asks the assistant a question, and after two exchanges the deck has scrolled off-screen. Re-invoking the tool stacks duplicate decks. Clinically, the conversation around the material is the entire reason to host lessons in chat, so "either chat or view the app, not both" defeats the point.

What we have tried:

  • Stable view identity: returning a constant viewUUID in _meta on repeat tool calls, hoping hosts route the result to the existing view rather than instantiating a new one. Host behavior appears to be per-call instantiation regardless.
  • `requestDisplayMode("fullscreen")": works where supported, but fullscreen suspends the conversation, which is the opposite of the goal.

The ask: host support for the persistent/pinned direction the spec already gestures at (pip), or letting app views open in the persistent side panel some hosts already have for their own artifacts. A view that stays put while the transcript scrolls would fix this class of problem completely, for us and for any app whose view is a workspace rather than a one-shot result (maps, dashboards, documents).

Happy to be a design partner or demo the clinical use case.

Conicia (https://conicia.com)

Dominant language
TypeScript
Stars
2.9k
Forks
387
Avg merge
3h 21m
Merged PRs (30d)
6

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from modelcontextprotocol/ext-apps

All issues in modelcontextprotocol/ext-apps

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.