What are MCP Apps and how do they work?

MCP Apps are interactive applications built on top of the Model Context Protocol that let a host such as Claude, ChatGPT, Codex, or Cursor render UI from an MCP server instead of showing only plain tool output. Unlike a basic MCP server that returns structured data or text, an MCP App can return a s

MMichael SwindellJuly 3, 202619 min read

MCP Apps are interactive applications built on top of the Model Context Protocol that let a host such as Claude, ChatGPT, Codex, or Cursor render UI from an MCP server instead of showing only plain tool output. Unlike a basic MCP server that returns structured data or text, an MCP App can return a sandboxed interface, keep state synchronized with the model, send follow-up messages into the conversation, and trigger additional tool actions. That makes MCP Apps a new software surface for agentic workflows, where users do not just read responses but act through interfaces that live directly inside AI-native clients and coding environments.

At a Glance

MCP Apps turn MCP servers into interactive software experiences inside AI clients.

Core idea: An MCP App returns UI components from an MCP server, not just JSON or text.
How it runs: The host renders the app in a sandboxed iframe and connects it back to the conversation.
Why it matters: It gives users richer workflows directly inside tools like Claude, ChatGPT, Codex, and Cursor.
Key advantage: State, UI, and model context can stay synchronized during the interaction.
Distribution shift: Store-based discovery and one-click installs are becoming a major channel for MCP builders.

Why are MCP Apps different from normal MCP servers?

MCP Apps differ from standard MCP servers because they add a live interface layer to tool calls. Instead of returning only structured outputs for the model to read, they can render interactive UI, maintain state, and participate in the conversation flow through host-supported primitives.

A conventional MCP server is usually thought of as a tool provider. The model calls a tool, receives text or structured output, and continues. That works well for automation, but it can become hard for humans to interpret when the result is dense, visual, or multi-step.

MCP Apps address that gap. They let the server return a widget that appears directly in the host client. That widget can show analytics, diagrams, cards, forms, canvases, or other task-specific views. The result is not just better formatting. It is a different interaction model.

This matters because some workflows are easier to understand visually than through a wall of text. Analytics dashboards, diagram generation, private data display, and media workflows all benefit from having a rendered interface instead of raw output.

How does an MCP App actually work under the hood?

An MCP App works by having the MCP server declare UI resources that the host can render when a tool is called. The host displays that UI inside a sandboxed iframe, then maintains a communication channel so the app and conversation can exchange updates during the session.

The architecture starts similarly to a normal MCP flow. A host connects to an MCP server. The server exposes tools. The model decides to call one of those tools.

The difference comes in the tool response. Instead of only returning plain output, the server can also return a UI resource. The host then renders that UI below or alongside the tool call. The interface is typically isolated in a sandboxed iframe, which gives the builder flexibility while keeping the host environment controlled.

The metadata exchanged during initialization tells the host what UI resources exist and how they should be used. When a tool is called, its arguments can populate the UI resource so the rendered component reflects the model’s current work.

This creates a layered system:

The host manages the conversation and rendering environment.
The model decides when tools should be used.
The MCP server defines tools and UI resources.
The app UI gives the human a visual, interactive surface.

The result feels closer to using software inside the AI client than reading a tool log.

What primitives make MCP Apps useful in real workflows?

MCP Apps become useful because they are not passive widgets. They can update model context, send messages into the conversation, react to streaming tool inputs, and trigger additional actions. Those primitives turn the app from a display layer into an active part of the workflow.

Several capabilities stand out.

Model context updates

An app can update what the model knows about the UI state without requiring the user to type another message. For example, if a user selects an item in a widget, the model can be informed that this item is now the active choice.

This matters because the model cannot always infer what changed in the interface just by seeing that a widget exists. A state update closes that loop and makes later responses more context-aware.

UI-to-model messaging

The app can send a follow-up message back into the conversation. That means a button inside the widget can trigger a new conversational step, such as asking for more detail about a selected product, record, or result.

Client behavior can vary. Some hosts may surface the message in the input box for confirmation, while others may send it directly and begin responding immediately. The important point is that the UI can drive the chat, not just respond to it.

Streaming input into UI

As tool arguments are generated incrementally, the UI can update in real time. This makes it possible to render diagrams, structured layouts, or media previews while the model is still composing the tool call.

That pattern is especially strong for visual tools. If a model is generating diagram syntax or structured scene data, the app can progressively render the result instead of waiting for completion.

Tool calls from the widget

The widget itself can trigger additional tool interactions. For example, a user might click to fetch more detail, load related data, or expand a view. This allows a workflow to continue from within the interface instead of bouncing the user back into manual chat turns.

How do MCP Apps handle privacy and model visibility?

MCP Apps can separate what the user sees from what the model sees. A tool can return rich UI data to the widget while sending only selected text or structured information to the model. That makes MCP Apps useful when sensitive data should stay visible to the user but not to the provider model.

This is one of the most practical design patterns in the MCP App model.

Some applications need to show information that should not be fully exposed to the model provider. Think about internal records, user-specific account details, or operational dashboards. In those cases, returning everything as plain tool output can create an unnecessary privacy risk.

MCP Apps provide a cleaner option. The tool can populate the widget with detailed information, while the model receives a reduced summary, an instruction describing what the user is seeing, or even no sensitive content at all.

That split creates useful patterns such as:

Private UI, minimal model context: The interface shows the full record, but the model only knows that the user is reviewing it.
Structured UI, redacted model output: The widget gets all fields, while the model receives only non-sensitive metadata.
Human-in-the-loop review: The model guides the workflow, but the person makes decisions from the private UI.

This matters for agentic systems because many organizations want AI-assisted workflows without exposing every piece of application data to the underlying model.

What kinds of user experiences can MCP Apps create?

MCP Apps can create experiences that are far richer than tool text, including analytics panels, live diagrams, visual editors, and full-screen interfaces. The key value is that the interaction happens inside the AI client instead of forcing the user back to a separate dashboard.

Common examples include:

Analytics views: Charts, summaries, and KPI panels that are easier to scan visually than as prose.
Diagram generation: Interfaces that render diagrams while the model streams structured instructions.
Canvas-based workflows: Interactive surfaces for visual planning and editing.
Cards and records: Compact, human-readable displays for entities like people, products, tickets, or events.
Media or editing surfaces: Interfaces that benefit from large visual areas and iterative prompts.

Hosts may also support different display modes. Inline rendering is the common case, but some experiences can expand into full-screen or picture-in-picture style layouts. That opens the door to workflows where the conversation controls a visual environment rather than merely annotating it.

For teams building coding-agent workflows, this has a direct parallel with control plane design. If an agent is generating plans, updating issues, and running verification, a visual layer becomes much more useful when it lives where the work already happens. That is why agent-first platforms like Levr’s feature set treat project context, test state, and workflow observability as part of the same operating surface rather than scattered across disconnected tools.

Which clients support MCP Apps today?

MCP Apps already have support across several major AI clients, although support depth varies by host. Claude, ChatGPT, Codex, Cursor, VS Code, and other clients can support MCP App rendering, but builders still need to account for differences in behavior and fallback handling.

That variation matters in practice.

Some hosts may fully support app rendering, message primitives, and integrated interactions. Others may support only a subset. A host that does not render MCP Apps at all might ignore the widget and rely only on plain tool outputs.

This means builders should think through compatibility from the start:

Detect app support when possible.
Return useful non-UI output when the widget is not shown.
Keep critical information available in a fallback path.
Test across multiple clients, not just one happy path.

The need for fallback behavior is easy to miss. If a tool puts most of its value inside the widget, and the client fails to render it, the user may get an incomplete experience unless the server also returns alternative output.

Need a better operating layer for coding agents?

When MCP-powered tools start creating plans, issues, and test flows, a shared control plane keeps humans and agents working from the same context.

See how Levr structures agent workflows

How do you build and ship an MCP App?

Building an MCP App usually means extending a normal MCP server with registered UI resources and host-aware behavior. You define tools as usual, attach widget resources to the relevant tool outputs, and make sure the app can degrade gracefully when a host does not support rendering.

The practical build flow looks like this:

Define the MCP server and tools. Start with the same tool architecture you would use for a standard MCP server.
Register UI resources. Associate interface components with the tools that need visual rendering.
Pass tool arguments into the UI. Let the widget render from the same context the model uses.
Implement state and messaging primitives. Add model-context updates, follow-up messaging, or additional tool calls when needed.
Prepare fallback behavior. Return meaningful output for hosts that do not render apps.
Test locally. Use inspection and testing tools to validate both the server behavior and UI behavior.
Publish remotely. Host the server so it can be submitted to client stores and directories.

The transcript source referenced open source tooling that helps developers build servers, clients, and agents more quickly, plus a local inspector and a cloud layer for shipping remote MCP servers from a GitHub repository. The main point for readers is broader than any one tool: treat MCP App development as both a protocol problem and a product-surface problem.

If your team is already coordinating multiple coding agents, one way to apply this operationally is through Levr’s agentic workflow. You define intent in natural language, let agents pick up scoped work, run automated verification, and keep human review as the approval boundary. MCP Apps fit naturally into that pattern when you need interactive surfaces inside the agent workflow.

How do MCP App stores and discovery work?

MCP App stores create a new distribution model for tool builders by offering submission, review, and one-click installation inside major AI clients. Instead of sharing manual configuration files, builders can publish vetted servers that users discover and install directly from supported hosts.

This is one of the biggest shifts around MCP adoption.

Several major clients now support self-serve submission processes for MCP servers and apps. The exact workflow differs by provider, but the common model includes:

Submitting a remote MCP server
Providing authentication details if required
Ensuring tools are annotated and structured correctly
Supplying test cases and prompts
Passing automated or partial manual review

Once approved, the app can appear in a store or connector directory where users can install it with a much simpler flow than copying raw MCP configuration.

This matters because distribution friction has always limited tool ecosystems. One-click install dramatically lowers the barrier to trial and adoption.

It also introduces a second, potentially larger change: dynamic discovery.

Instead of only browsing a directory manually, a host can search a registry when the user expresses an intent the current toolset cannot satisfy. In that model, a user asks for an outcome, and the host looks for the best matching connector. If your MCP App is present and well-positioned, it can be selected organically.

That turns app-store presence into more than a listing benefit. It becomes an intent-capture channel inside AI-native software.

This aligns with broader industry movement toward AI-assisted development. GitHub’s Octoverse reports and the Stack Overflow Developer Survey 2024 both show how mainstream AI tooling has become for developers, even as teams remain concerned about trust, correctness, and workflow integration. Discovery matters more when these tools become part of daily work rather than occasional experiments.

Why do MCP Apps matter for the future of software?

MCP Apps matter because they shift software usage from navigating standalone dashboards to completing tasks inside AI clients. If users increasingly work through agentic interfaces, products that expose useful MCP surfaces gain a path to stay present in those workflows instead of being bypassed.

The argument is straightforward. When users can search, plan, execute, and inspect work inside AI-native tools, they stop thinking in terms of “open the website first.” They think in terms of “ask for the task to be done.”

That does not mean websites disappear. It means the access pattern changes.

In this model:

AI clients become a primary software entry point.
MCP servers become the action layer.
MCP Apps become the visual and interactive layer.
Stores and registries become the distribution layer.

For engineering teams, that raises a new question: what happens when software is increasingly consumed through coding agents and AI hosts rather than traditional navigation?

The answer is usually not "replace everything with chat." It is "expose the right actions, state, and interfaces where agentic workflows happen." For teams managing many agents at once, the same principle shows up at the orchestration layer. Levr, for example, focuses on the message bus, shared memory, intelligent routing, and coordination layer needed when multiple coding agents need shared context instead of isolated prompts.

MCP Apps sit one level above that infrastructure. They are how useful capabilities become understandable and interactive inside the host.

What mistakes should builders avoid with MCP Apps?

Most MCP App mistakes come from treating the UI as a cosmetic add-on. Builders run into trouble when they forget fallback behavior, overload the model with private data, ignore client differences, or design widgets that look good visually but do not improve task completion.

The most common pitfalls include:

No fallback output: If the host does not render the widget, the experience breaks.
Overexposing sensitive data: Just because the app can show information does not mean the model should receive all of it.
Ignoring host-specific behavior: Message handling and interaction patterns differ across clients.
Shipping for demos, not real work: A flashy widget is less valuable than one that reduces friction in an actual workflow.
Poor submission readiness: Missing annotations, broken auth flows, or weak test prompts can delay store approval.
Assuming discovery happens automatically: Being listed is not enough if your tools are unclear or poorly described.

A good rule is simple: the UI should make the workflow easier for both the human and the model. If it only makes the interface prettier, it is probably not enough.

Technical Deep Dive FAQ

What is an MCP App?

An MCP App is an interactive application surface built on the Model Context Protocol. It extends the basic MCP server model by allowing a tool to return rendered UI, not just text or structured data. That UI lives inside a supported host and can interact with the conversation through state updates, messaging, and additional tool actions. The result is a workflow where users can inspect and act through interfaces embedded directly in AI clients.

How is an MCP App different from an MCP server?

An MCP server exposes tools a host can call. An MCP App uses that same tool structure but adds a UI layer and interaction primitives. In practical terms, a standard server may return JSON or text, while an MCP App can return a widget rendered by the host. The app can also keep the model informed about interface state and react to user interactions inside the interface itself.

Why are sandboxed iframes used in MCP Apps?

Sandboxed iframes let hosts render third-party UI while maintaining isolation boundaries. The app can present custom visuals and interaction flows, but it does not get unrestricted access to the host environment. This creates a safer execution model for embedded interfaces and gives the host a consistent way to manage rendering, communication, and permissions across different app providers and use cases.

Can an MCP App update the model without a new user message?

Yes. One of the important primitives in MCP Apps is the ability to update the model’s understanding of UI state directly from the widget. If a user selects an item, filters a view, or changes a setting, the app can push that state into the model context. That allows later responses to reflect the actual interface state instead of relying on the user to describe every change manually.

Can the widget send messages back into the conversation?

Yes. MCP Apps can send follow-up messages from the UI into the host conversation. This means a button or interaction inside the interface can trigger a new conversational action, such as asking for deeper analysis, requesting a next step, or gathering more detail on a selected object. Different hosts may handle this differently, but the general pattern allows the interface to actively guide the flow.

What happens if the host does not support MCP Apps?

If the host does not support MCP Apps, the widget may not render at all. That is why fallback output is important. Builders should return useful text or structured data so the workflow still works without the visual component. In many cases, the model still needs enough information to proceed, even if the user loses the richer interface. Good app design assumes partial client support is normal.

Can MCP Apps protect sensitive data from the model?

They can help. An MCP App can show detailed or private information in the widget while sending only selected data, a summary, or no sensitive details to the model itself. That separation is one of the strongest practical features of the pattern. It does not remove all privacy concerns, but it gives builders a way to avoid exposing every visible field to the underlying model provider.

How do MCP App stores review submissions?

Store workflows vary by host, but the process generally includes validating the remote MCP server, checking tool annotations and arguments, reviewing authentication behavior, and testing prompts or scenarios supplied by the builder. Review may be partially automated and partially manual. If the app passes, it can be published into a directory or store where users can install it with much less setup friction than manual MCP configuration.

Why does dynamic discovery matter for MCP builders?

Dynamic discovery changes MCP distribution from a manual install problem into an intent-matching problem. Instead of relying only on users to browse directories, hosts can search registries when a user asks for something the current tools cannot do. If your MCP App is well described and relevant, the host may surface it at the moment of need. That creates a much stronger path to adoption than static documentation alone.

How do MCP Apps fit into multi-agent engineering workflows?

MCP Apps fit best when they expose stateful, inspectable interfaces inside larger automated flows. A coding agent may gather data, create plans, update tickets, or run tasks through MCP, while the app gives humans a readable and interactive surface for review. In a multi-agent setup, that works even better when the system also has shared context, routing, and observability, which is where agent-first platforms and infrastructure layers become useful.

Are MCP Apps only useful for consumer chat tools?

No. They are also useful in developer tools, coding environments, and enterprise workflows. The transcript source specifically referenced support in tools like Claude, ChatGPT, Codex, Cursor, and VS Code. Anywhere a host can call tools and render embedded UI, MCP Apps can make complex output more usable. That includes analytics, planning, software delivery, and internal operational systems, not just general-purpose assistants.

Do teams need both MCP Apps and a control plane?

Often, yes, because they solve different problems. MCP Apps handle interactive presentation and workflow actions inside the host. A control plane handles coordination across people, agents, issues, tests, and approvals. If your team is experimenting with coding agents, the combination is powerful: MCP gives the agent actions, apps provide the UI surface, and a system like Levr provides the shared operational context.

Key Takeaways

MCP Apps are becoming a serious software surface, not just a protocol curiosity.

The real shift is from tool output to interactive, discoverable software inside AI-native hosts.

Architecture: MCP Apps let servers return rendered UI through host-managed, sandboxed interfaces.
Primitives: State updates, UI messages, streaming input, and tool calls from widgets make apps interactive.
Distribution: Stores and registries reduce setup friction and create new discovery channels.
Strategy: Products that want to stay visible in agentic workflows should think beyond dashboards and APIs alone.

The main question is no longer whether software will be used through agents, but how usable your product is when that becomes the default path.