What are MCP Apps?
The announcement defines them in one line: “MCP Apps let tools return rich, interactive interfaces instead of plain text.” The documentation gives examples of what that means: servers can return interactive HTML interfaces (data visualizations, forms, dashboards) that render directly in the chat.
Without the extension, a tool returns text, an image or structured data, and the client decides how to show it. With it, the server author ships the interface along with the tool.
How do MCP Apps work?
The pattern combines two things MCP already had: a tool, and a resource. The documentation describes four steps.
- The tool declares its view. The tool description includes a
_meta.ui.resourceUrifield that points to aui://resource. The host can preload it before the tool is called. - The host fetches the resource. It contains an HTML page, often bundled with its JavaScript and CSS.
- The host renders it in a sandbox. Web hosts typically put the HTML in a sandboxed iframe inside the conversation.
- The view and the host talk. They exchange JSON-RPC messages over
postMessage. The view can request tool calls and receive fresh data from the host.
The exact messages are in the MCP Apps specification, version 2026-01-26.
When is a view better than text?
The documentation lists five situations where an MCP App is a good fit:
- Exploring complex data, such as a map of sales by region that the user can click into.
- Configuring with many options, where a form shows every choice at once instead of a long back-and-forth.
- Viewing rich media, such as a PDF or a 3D model.
- Real-time monitoring, where a dashboard updates without the user asking again.
- Multi-step workflows, such as approving items one by one.
If the answer is a sentence or a short list, text is still the better result. A view earns its place when the user needs to interact with the data, not only read it.
How is an MCP App kept safe?
A view is code from the server author running in the user's client, so the extension is built around containment. The announcement lists four mechanisms:
- Iframe sandboxing. All UI content runs in sandboxed iframes with restricted permissions.
- Pre-declared templates. Hosts can review HTML content before rendering.
- Auditable messages. All UI-to-host communication goes through loggable JSON-RPC.
- User consent. Hosts can require explicit approval for UI-initiated tool calls.
The documentation adds that the sandbox prevents the app from reaching the parent page's DOM, reading the host's cookies or local storage, or navigating the parent page. A view declares the outside origins it needs in _meta.ui.csp and any extra capabilities, such as the microphone or camera, in permissions.
Which clients render MCP Apps?
Support is not universal, because this is an extension. When this page was last updated, the documentation's client support section listed Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam and Archestra.AI. The January 2026 announcement also named ChatGPT. Check the documentation for the current list before you depend on one client.
Should you build an MCP App or a normal web app?
| MCP App | Standalone web app | |
|---|---|---|
| Where the user is | Inside the conversation that led to it | A separate tab |
| Data access | Calls tools on its MCP server through the host | Needs its own API, sign-in and state |
| Isolation | Sandboxed iframe controlled by the host | Your own origin and your own security |
| Reach | Clients that support the extension | Any browser |
| Best for | Acting on a result the model just produced | A product people open on its own |
The trade-offs in the first three rows are the ones the documentation gives under “Why not just build a web app?” It also says plainly that if your use case does not benefit from them, a regular web app might be simpler.
How do you ship an MCP App?
You need three things: a tool, an HTML view, and a server that links them and serves the view as a resource.
- Start from a tool that already returns useful structured data.
- Write one HTML page that renders that data. Keep it self-contained where you can.
- Register the page as a
ui://resource and set the tool's_meta.ui.resourceUrito it. - Declare any outside origins the page loads from, then test in a client that supports the extension.
Related: how to build an MCP server for your company.
Sources
Every figure and dated fact above comes from one of these pages. Follow the link to check it.
- MCP Apps - Bringing UI Capabilities To MCP Clients. Model Context Protocol blog, January 26, 2026.
- MCP Apps (extension documentation). modelcontextprotocol.io.
- MCP Apps specification, version 2026-01-26. modelcontextprotocol/ext-apps on GitHub.
