MCP Apps Overview

What are MCP Apps?

MCP Apps extend the Model Context Protocol so servers can deliver secure, interactive user interfaces to any compliant host. Declare UI once, render everywhere.

Browse MCP Apps Read the specification

Why MCP Apps?

Text responses are not enough for many workflows. MCP Apps unlock rich, interactive experiences without sacrificing portability or security.

Data visualization

Charts, graphs, dashboards, and analytics that update as data changes.

Rich media

Video players, audio waveforms, 3D models, and immersive previews.

Interactive forms

Multi-step wizards, configuration panels, approvals, and onboarding flows.

Real-time displays

Live logs, progress indicators, streaming content, and status dashboards.

Progressive enhancement, by design

Hosts advertise their UI capabilities. Servers register UI-enabled tools only when supported, so everything still works as text on non-UI hosts.

Servers check host capabilities before enabling UI tools.
If UI is unavailable, tools return text and structured data instead.
The same server runs everywhere with consistent behavior.

UI is optional, not required

Your MCP server remains compatible with every host. UI is a bonus where supported.

See capability negotiation in the spec

Architecture at a glance

Three entities collaborate to deliver interactive experiences without breaking the MCP model.

MCP Server

Defines tools and UI resources, plus the data that powers them.

Host (Chat Client)

Renders Views in sandboxed iframes and proxies communication.

View (Iframe UI)

Receives tool data, renders UI, and calls tools or sends messages.

The View acts as an MCP client, the Host is the proxy, and the Server remains a standard MCP server.

Lifecycle

From discovery to teardown, MCP Apps follow a predictable sequence that hosts can trust.

Discovery

Hosts discover tools and their UI resources during connection.

Initialization

The View sends ui/initialize and receives host context and capabilities.

Data delivery

Hosts send tool inputs and results, including UI-optimized structured content.

Interactive phase

Users interact with the View, which can call tools and update context.

Teardown

Hosts notify the View so it can save state and release resources.

UI resources

Servers declare HTML templates with ui:// URIs during tool registration so hosts can prefetch and review them.

Hosts can prefetch and cache templates before execution.
Presentation and data stay decoupled for clean architectures.
Hosts can inspect UI templates during connection setup.

Example UI resource URI

ui://weather/forecast

Tool–UI linkage

Tools reference their UI templates via metadata. When called, the Host fetches the template and renders it securely.

Fetch the UI resource declared by the tool.
Render the View inside a sandboxed iframe.
Pass tool inputs and results to the View.

Tool metadata example

{
  "_meta": {
    "ui": { "resourceUri": "ui://weather/forecast" }
  }
}

Bidirectional communication

Views and Hosts communicate over JSON-RPC via postMessage, keeping interactions auditable and secure.

Interact with the server

Call tools (tools/call) or read resources (resources/read).

Access server data

Receive structured results optimized for UI rendering.

Interact with the chat

Send messages (ui/message) or update model context.

Request host actions

Open external links or request host UI changes.

Tool visibility

Tools can be visible to the model, the app, or both. This prevents UI interactions from cluttering model context.

Default visibility is both model and app.
App-only tools keep UI interactions private.

Keep model context clean

Use app-only tools for refresh actions, pagination, or form submissions.

Host context & theming

Hosts provide runtime context so Views can adapt their layout and styling.

Theme preference (light or dark).
Locale, timezone, and platform metadata.
Display mode (inline, fullscreen, or picture-in-picture).
Container dimensions and layout constraints.

Theme variables example

.container {
  background: var(--color-background-primary, #ffffff);
  color: var(--color-text-primary, #000000);
}

Hosts notify Views when context changes so UIs can update without reloads.

Display modes

Views declare which modes they support; Hosts decide what they can provide.

Inline

Embedded in the chat flow for quick previews and forms.

Fullscreen

Immersive experiences like editors or dashboards.

Picture-in-picture

Persistent widgets that stay visible while chatting.

Security by default

MCP Apps keep data safe through sandboxing and strict communication rules.

Views run in sandboxed iframes with no host DOM access.
CSP declarations restrict external connections by default.
All communication flows through auditable JSON-RPC.

Restrictive by default

If a server does not declare a domain, the View cannot connect to it.

What you can create

Build highly customized MCP Apps — even personalized experiences for a single user or team.

Personalized assistants

Private dashboards, trackers, and workflows tailored to one person.

Business workflows

Approvals, multi-step forms, onboarding, and automation panels.

Insights & monitoring

Live metrics, status boards, and operational health views.

Custom experiences

Interactive demos, learning modules, or branded client portals.

Want us to build your MCP App?

Progressive enhancement, by design

Hosts advertise their UI capabilities. Servers register UI-enabled tools only when supported, so everything still works as text on non-UI hosts.

Servers check host capabilities before enabling UI tools.

If UI is unavailable, tools return text and structured data instead.

The same server runs everywhere with consistent behavior.