Stacks and Flows

Protocol Boundary Guide · Source-verified

MCP Apps: when an agent tool needs an interactive UI

MCP Apps extends an MCP tool with an interactive interface that a compliant host can render inline. Use that boundary for charts, forms, dashboards, or canvases that need interaction—not as a default replacement for structured tool results or a normal web application.

Interactive UI boundary

Add a UI only when the result needs interaction

MCP tool
declare view
ui:// resource
fetch after tool call
Compliant host
render with policy
Sandboxed view
mediate messages
User interaction
A tool declares a UI resource. A supporting host fetches and renders it in a sandbox, then mediates data and tool calls.

What the sources establish

  • The official MCP Apps repository defines UI resources referenced through ui:// URIs and rendered by a supporting host in a sandboxed iframe.
  • MCP tools can still return text or structured data; an app resource adds an interactive view and a host-mediated communication bridge.
  • MCP Apps is an extension to MCP, and host support varies; an MCP-compatible client is not automatically an MCP Apps-compatible host.
  • AWS published an AgentCore implementation guide for interactive MCP Apps on September 11, 2026.

Tool output versus interactive view

A normal MCP tool can return text and structured content for a model or host to use. MCP Apps adds a ui:// resource for cases where a person must inspect, manipulate, or submit information through an interface. Do not add the UI layer when the result can remain a compact tool response.

The host is part of the compatibility boundary

A server can publish an app resource, but the client must advertise and implement the extension, fetch the resource, render it safely, and bridge messages. Verify each named host; protocol branding alone is not compatibility evidence.

Security and data boundary

The view runs inside a host-controlled sandbox and communicates through a mediated bridge. Review content-security policy, allowed origins, tool permissions, secrets, user inputs, links, and data passed between the tool, UI, and host before enabling it.

When not to use MCP Apps

Prefer a tool-only integration for machine-readable results and a conventional web app for standalone user journeys, broad browser compatibility, or product surfaces that should not depend on an agent host. An MCP App is an embedded interaction boundary, not a universal application runtime.

Decision detail

  1. Use MCP Apps when an agent result needs an interactive chart, form, dashboard, canvas, or other in-conversation interface.
  2. Keep a tool-only path when text or structured output is enough, or when target hosts do not support the extension.
  3. Use a normal web application when the experience must work independently of an agent host, needs direct navigation, or owns a broader product lifecycle.
  4. Before adoption, test the named host, sandbox policy, resource origins, permissions, fallback behavior, and portability requirement.

Evidence

These claims are source-verified. We do not label this page hands-on or benchmarked because no reproducible test artifact is attached.

Continue the decision