Design guidelines changedconnectors/building/mcp-apps/design-guidelines
Nearest release: v2.1.322, published 15 hours before upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Upstream edited this page at 10 Nov 2026 17:02 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 10 Nov 2026 17:07 UTC.
Upstream edited
Recorded here
Lines+30added
Lines−4removed
From line
44
where the diff opens
First seen
14 Aug 2026
this site's first read of the page
Recorded edits7to this page, all time
### Side panel
The whole hunk
from line 44, old and new numbered
/
from line 44
4444
4545## Display modes
4646
47An MCP App appears in the conversation as an inline card, an inline carousel, or a full screen view. Each mode suits different content and carries its own constraints on desktop and on mobile.
47> [!NOTE]
48>
49> The [side panel](#side-panel) is available to a limited set of organizations, and not in every conversation. Where it isn't available, a fullscreen request opens your app full screen if Claude offers that mode. To check, see [Show your MCP App in the side panel or full screen](https://claude.com/docs/connectors/building/mcp-apps/display-modes.md).
4850
51An MCP App appears inline in the conversation as a card or a carousel, in a side panel beside the conversation, or full screen. Each placement suits different content and carries its own constraints on desktop and on mobile. To declare and request display modes in code, see [Show your MCP App in the side panel or full screen](https://claude.com/docs/connectors/building/mcp-apps/display-modes.md).
52
4953### Inline card
5054
5155An inline card is a compact component embedded directly in the conversation. Keep it focused. Use an inline card for:
from line 98
9498
9599
96100
101### Side panel
102
103The side panel keeps your app open beside the conversation on web and desktop, so users can keep chatting while they watch the app update. Use the side panel for:
104
105* Documents, boards, and maps that the user and Claude work on together
106* Results the user refers to while they ask follow-up questions
107* Editors and previews that change as the conversation goes on
108
109The side panel has these constraints:
110
111* The panel opens at about half the width of the chat area, and users can resize it down to about 320px
112* Your app reads the `fullscreen` display mode in the panel, as it does in full screen, so lay out by the container's size rather than by the mode
113* Icon buttons in the panel's title bar take users on to full screen or back to the conversation
114
97115### Full screen
98116
99117Full screen mode gives complex interactions an immersive interface. The conversation composer remains available, so users can continue talking to your app through Claude. Use full screen for:
from line 129
111129Full screen mode has these constraints:
112130
113131* Your app provides its own fullscreen button, and a close button appears in the native header bar
132* Where the [side panel](#side-panel) is available, Claude also shows its own expand button above an inline app that supports `fullscreen` on web and desktop
133* A fullscreen request from your app opens the side panel where there is one, and users go on to full screen from the panel
114134* The composer is always visible, so design your UX to work with it
115135* No floating panels, so use collapsible sidebars, tabs, or pagination to disclose details
116136* The chat sheet maintains conversational context
from line 165
145165
146166### Declare supported display modes
147167
148Declare which modes your app supports through `appCapabilities.availableDisplayModes` in `ui/initialize`. The host responds with the modes it supports, and your app can request a switch with `ui/request-display-mode`. Modes are `inline`, `fullscreen`, and `pip`.
168Declare which modes your app supports through `appCapabilities.availableDisplayModes` in `ui/initialize`. The host responds with the modes it supports, and your app can request a switch with `ui/request-display-mode`. Claude offers `inline` and `fullscreen`. For the request, its result, and the size that Claude reports, see [Show your MCP App in the side panel or full screen](https://claude.com/docs/connectors/building/mcp-apps/display-modes.md).
149169
150170### Content security policy
151171
from line 178
158178 "csp": {
159179 "connectDomains": ["https://api.example.com"],
160180 "resourceDomains": ["https://cdn.example.com"],
161 "baseUriDomains": []
181 "frameDomains": ["https://editor.example.com"]
162182 }
163183 }
164184 }
from line 185
165185}
166186```
167187
168The `frameDomains` field, for embedding third-party iframes, is restricted in Claude pending security review.
188Each field allows a different kind of request to the origins it lists:
189
190* `connectDomains`: origins your app reaches with `fetch`, `XMLHttpRequest`, or a WebSocket
191* `resourceDomains`: origins your app loads scripts, styles, images, fonts, media, and web workers from
192* `frameDomains`: origins your app embeds in an `<iframe>`. Claude also has to allow these origins for your connector, as [Embed a website in an MCP App](https://claude.com/docs/connectors/building/mcp-apps/embedded-sites.md) explains.
193
194Start each entry with its scheme, such as `https://` or `wss://`. In `connectDomains` and `resourceDomains`, Claude drops an entry it can't read and applies the rest. A request to a dropped origin fails with a Content Security Policy error in the browser console. If you set `baseUriDomains`, Claude ignores it and keeps the base URI on your app's own origin.
169195
170196### Viewport and layout
171197
No line in this hunk matches that.