---
title: "What Are MCP Apps, and Where Does the HTML Live?"
slug: /blog/mcp-apps-html-ui
publishedAt: "2026-10-14"
updatedAt: "2026-10-14"
author: ott
description: "MCP Apps let a tool return an interactive HTML interface that renders inside the chat. What they standardize, what the docs say about security, and when a published URL is the better home for the result."
---

# What are MCP Apps, and where does the HTML live?

> **TL;DR:** MCP Apps let an MCP tool return an interactive HTML interface. The host shows it inside the conversation, in a sandboxed iframe. The interface stays in the chat. If colleagues must open the result later, publish it to a URL. Display (display.dev), the docs workspace for agents and people, is one place to do that.

Display is our product. We checked the MCP facts against the [MCP Apps overview](https://modelcontextprotocol.io/extensions/apps/overview) on 14 October 2026.

---

## What MCP Apps standardize

The MCP documentation describes one pattern. A tool declares a UI resource in its description, with a `_meta.ui.resourceUri` field that points to a `ui://` resource. The host gets the HTML from the server and shows it in a sandboxed iframe. The app and the host talk through their own JSON-RPC dialect of MCP over `postMessage`. The app can call tools on the server, send messages and update the context of the model.

The docs list these hosts: Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam and Archestra.AI. The docs also say that host support varies by client.

The docs say that the sandbox isolates the app from the host. The app cannot get access to the DOM of the parent window. It cannot read the cookies or the local storage of the host.

---

## Where the HTML lives

The MCP documentation says that the app "lives inside the conversation". The MCP server supplies the interface, and the host shows it. The docs compare an MCP App with a standalone web app that you send as a link. They do not describe a shared URL with access control for the result. If you need that, you need a place to publish.

---

## The gap for company documents

An interactive result in a chat is correct when one person explores data. A report that ten colleagues read next week needs a URL, an access rule and a version history. Display gives you these three:

1. Tell the agent: "Publish dashboard.html to Display for my company."
2. Colleagues open the link after they sign in with Google or Microsoft (Pro) or with a one-time password.
3. They comment on the page. The agent reads the comments and publishes the next version at the same URL.

Scripts in a published file run in the browser of the reader with normal browser capabilities. Display does not put them in a sandbox. Read [Security](/security) for the details. An MCP App runs in a sandboxed iframe that the host controls.

---

## When another approach is better

- **Use an MCP App** when the user works with live data in the chat and calls server tools from the interface.
- **Use a deploy platform** when the page needs a backend.
- **Use Display** when the output is a document for a team.

---

## FAQ

**What is an MCP App?**

An interactive HTML interface that an MCP tool returns. The host shows it inside the conversation.

**Is an MCP App the same as a published page?**

No. An MCP App shows in a sandboxed iframe that the host controls. A published page has its own URL and its own access rule.

**Can I publish the HTML from an MCP App to Display?**

Yes, if you have the HTML source. Publish it as an HTML artifact. The app gets some data through the host. That data is not available at the new URL.

**Does Display show MCP Apps?**

No. Display is an MCP server for publishing. Its tools do not return MCP App interfaces.