Minimal preferred size

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).

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.

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.

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

No files or tests are named. Start by reviewing the proposed display modes, minimal dimensions, metadata, and CTA behavior in this issue, then compare them with the existing MCP Apps specification and SDK entry points. Done requires a decided approach and agreed client and app behavior.