MCP Apps: how interactive UI gets into the conversation

MCP Apps is the Model Context Protocol (MCP) extension that puts interactive user interfaces (UIs) inside the chat. Its history caught my attention: it came out of collaboration rather than competition. The community MCP-UI project and OpenAI’s Apps software development kit (SDK) were merged into one standard, co-authored with Anthropic. That’s why one MCP server can target Claude, ChatGPT, VS Code and other hosts with the same UI.

This is part 24 of my series on what an MCP server does under the 2026-07-28 specification, after how extensions work in part 23. It covers why MCP Apps exists and how an app reaches the screen; the next part builds one. The facts are as I read them in October 2026.

In brief #

1. MCP Apps lets your server put an interactive HyperText Markup Language (HTML) interface inside the chat, such as a chart, a form, a dashboard or a viewer.
2. MCP Apps was the first official MCP extension, shipped on 26 January 2026.
3. Three parties share the work: your server, the host, and the view, a sandboxed page that talks only to the host.
4. The view speaks a dialect of MCP overpostMessage : most of its methods carry aui/ prefix, andping , which left core MCP in 2026-07-28, lives on only there.
5. The host can read the app’s ui:// HTML template before the tool is called, so it can cache and review it; when the model calls the tool, the host renders it, and under the MCP Apps convention the result reaches the view as data while the model gets the text.

What MCP Apps is #

The extension’s identifier is io.modelcontextprotocol/ui. It was proposed in November 2025 as SEP-1865, a Specification Enhancement Proposal, and shipped as the first official MCP extension on 26 January 2026. It now sits within the extensions framework of the 2026-07-28 specification, so a host and a server agree on it the way part 23 describes.

Why not send a link to a web app?

Your server could return a link instead. The official MCP Apps overview lists four advantages:

Three parties and a bridge #

An MCP App has three parties: your MCP server, the host the user chats in, and the view, which is the app itself. The large language model (LLM) sits outside the app and gets only what the host passes on.

On the server, the link between a tool and its interface is one field: the tool’s _meta.ui.resourceUri names a ui:// resource. That resource is served as text/html;profile=mcp-app through the same resources/read that part 10 covers, and its own _meta.ui declares what the page needs, such as its Content Security Policy (CSP) and permissions. The tool’s result carries content and structuredContent, the two halves for two audiences from part 8. In the host, the app bridge enforces the CSP, which tools the model and the app may each call (their visibility, covered in the next part) and the user’s consent.

A dialect of MCP

The view exchanges JSON-RPC messages with the host over the browser’s postMessage, and it talks MCP only to the host, never to your server directly. Conceptually, the iframe is an MCP client of the host, and the host acts as a server that can proxy to your real MCP server. So the view speaks a dialect of MCP:

• tools/call andresources/read are core MCP methods, used as they are;

• ui/initialize is similar to theinitialize handshake core MCP used to have ;

• most of the other methods are new, with a ui/ prefix;

• ping is no longer shared with core MCP: the 2026-07-28 revisionremoved it from the core , so it lives on only in this dialect.

From discovery to the first render #

Before the user touches anything, the lifecycle runs in two phases: the host negotiates and discovers, then the model calls the tool and the view comes up.

Negotiate and discover. When the host lists tools, its client capabilities declare the ui extension and the content types it can render (mimeTypes). A tool with an interface comes back with _meta.ui.resourceUri. The host can read that ui:// resource ahead of time, getting the HTML with its _meta.ui.csp, so it can cache the template and review it before anything runs.

The model calls the tool. The host sends tools/call to your server and renders the HTML in a sandboxed iframe under that CSP. The view opens a handshake of its own with ui/initialize, and the host answers with a hostContext: theme, styles, display mode, container dimensions and locale. Next the host passes the view the tool’s arguments, optionally streamed in part before the complete set, and forwards your CallToolResult as ui/notifications/tool-result, giving the model the content only.

In this sequence, the view is up, themed and holding the arguments before your server has answered. And the model and the view get different halves of one result: under the MCP Apps convention, structuredContent is the view’s data and isn’t added to the model’s context. Some hosts show it to the model anyway: Anthropic’s Agent SDK documentation says the Claude Code runtime does, and ChatGPT does too (part 8 has the detail). So write content that stands on its own.

The next part picks up at the user’s first click and runs to teardown, with what each party declares, the security model and which hosts support MCP Apps.

Method and caveats #

• Built from the first half of my guide’s chapter on MCP Apps, written against the 2026-07-28 specification and the MCP Apps specification of 2026-01-26. Facts as of October 2026.
• Where the specification is more precise than my notes (ping left core MCP in the 2026-07-28 revision and lives on only in the app dialect), this article follows the specification.
• Keeping structuredContent from the model is the MCP Apps convention, not a core rule; where hosts differ, this article follows their documentation as read on 8 October 2026.