Minimal preferred size

Aperta
#688 2 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
typescript
Ambito
api, frontend

Direzione di ricerca

Non sono indicati file o test. Inizia esaminando le modalità di visualizzazione, le dimensioni minime, i metadati e il comportamento della CTA proposti in questa issue, quindi confrontali con la specifica MCP Apps esistente e con i punti di ingresso dell’SDK. Il lavoro sarà considerato completato quando sarà stato deciso un approccio e saranno stati concordati i comportamenti del client e dell’app.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

MCP Apps add expressiveness to the agentic experience, but current constraints and design choices made by clients make it challenging to deliver enterprise-grade experiences. Below is an overview of the available display modes and container dimensions across popular clients. Notice that both Cursor and VS Code in editor modes constrain maxHeight to less than the viewport height and offer limited width (depending on how wide the user makes the side panel). If an MCP app were to present a complex, interactive report or dashboard, it would require heavy adaptations, almost like writing two separate frontends. And in some cases no adaptation would be enough (for example, dense tables with many rows and columns).

Here is an initial stab at guiding principles:

  1. Provide the app with the maximum usable canvas
  2. Keep the user in control
  3. Strive for consistent interaction patterns
  4. Keep new concepts to a minimum

So what are some of the options for addressing this?
Reusing fullscreen mode
If all clients supported fullscreen mode, the MCP app could render a call-to-action in the initial inline mode to open the fullscreen view. Opening fullscreen is disruptive, though, and the actual experience is inconsistent across clients (Claude shows chat as an overlay in fullscreen mode, Goose doesn't show chat at all, and Quick opens it in a modal).

Image

Introducing new display mode 'side-by-side'
We could make the experience less disruptive and more predictable by introducing a dedicated "side-by-side" display mode, where chat and the current MCP app are shown next to each other. The user can continue interacting with chat while viewing the MCP app UI. However, each MCP app would have its own visual affordance for triggering side-by-side, which is not ideal, as users might not realize what will happen when they use it. There is also the question of what happens to the inline version of the MCP app when the user opens the bigger one.

Image

Using inline mode with preferred minimal area
Alternatively, we could offload the triggering of a bigger canvas to the clients by allowing apps to declare in their metadata the minimal area they need in inline mode to ensure a quality experience. The expectation is that if the client can provide a canvas that large within chat, it renders the app there. If not, it shows a CTA that opens the app in artifact view. The tool result could return additional information to enhance the CTA (for example, text and/or a description to display there).

This approach is similar to MCP-UI's preferred-frame-size, except it would define minimal dimensions rather than preferred ones, and the spec would take an opinionated view on what happens when they cannot be met.

Image

FAQs

1. Why is PiP mode insufficient?
Among the clients I've reviewed, only Goose supports PiP mode, and it does so by displaying a 400x300 floating window. Using PiP would therefore give the MCP app even less canvas, not more.

2. What if the client cannot provide a big enough canvas (for example, on mobile)?

The client is expected to provide the biggest canvas it can, and the app has to adapt. While some additional frontend work would still be required, the proposal would improve the experience in most cases.

Clients overview

Cursor (editor mode):
maxHeight: 800, width: 430
available display mode: inline

Cursor (agents mode):
maxHeight: 800, width: 748

VSCode with Github copilot (editor mode):
maxHeight: 600, width: 440
available display mode: inline

Goose:
maxHeight: undefined, width: 1200
available display modes: inline, fullscreen, pip

Claude (desktop):
maxHeight: 5000, width: 736
available display modes: inline, fullscreen

Quick (desktop):
width: 530
available display modes: inline, fullscreen

Lingua principale
TypeScript
Stelle
2.9k
Fork
387
Merge medio
3h 21m
PR unite (30g)
6

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di modelcontextprotocol/ext-apps

Tutte le issue di modelcontextprotocol/ext-apps

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.