TL;DR: An MCP app is a packaged, interactive UI surface that an MCP server delivers to a host application through the MCP Apps extension (SEP-1865, finalized January 26, 2026). The core protocol does not define apps as a primitive; the extension delivers them as an optional, negotiated capability identified as io.modelcontextprotocol/ui. Servers still execute tools and expose resources. Apps render HTML UI in sandboxed iframes and talk back to the host over JSON-RPC via postMessage. The architectural decision is whether your integration needs server-delivered interactive UI, and whether you build or buy the credential, OAuth, and policy layer that integration depends on.
Your team is planning an MCP integration, and someone just asked whether you need an MCP app or an MCP server. The answer determines your architecture, your maintenance surface, and what breaks when the upstream API changes. Most MCP documentation treats apps as a UI afterthought bolted onto servers, leading teams to build the wrong thing. This article explains what the MCP app model actually specifies at the protocol level, where its boundaries are, and what the spec deliberately leaves unsolved, so you can make the build-vs-buy call with accurate information.
How MCP apps function at the protocol layer
Here is the first thing most explainers get wrong: the core MCP specification omits "app" from its protocol primitives. In the base spec, servers expose three primitives: prompts, resources, and tools, which are executable functions the model calls to retrieve information or act. MCP apps arrive through a separate track.
The MCP Apps extension defines MCP apps as a mechanism that extends the Model Context Protocol to enable servers to deliver interactive user interfaces to hosts. The extension mechanism itself is the protocol's incubation pathway: official extensions live in the MCP GitHub organization with the ext- prefix, as described in the MCP extensions overview.
So the precise answer to "what is an MCP app" is: a UI delivery mechanism standardized as an optional extension, not a data access mechanism and not a fourth core primitive. Servers still own tool execution and resource access. Apps package interactive components that render inside the host.
MCP app model: Core specifications
The MCP app model, as specified in SEP-1865, introduces four things:
UI resources: HTML content served under a ui:// URI scheme, with the initial content type text/html;profile=mcp-app.
Tool-UI linkage: tools reference UI resources through metadata in their descriptions.
Bidirectional communication: the rendered UI iframe talks to the host using standard MCP JSON-RPC.
A security model: mandatory iframe sandboxing with auditable, host-controlled communication.
The MCP-UI creators and maintainers from OpenAI and Anthropic developed the proposal together, according to the MCP Apps announcement post from November 2025.
MCP app integration vs. traditional APIs
Traditional MCP tools return text, images, resources, or structured data that the host displays as part of the conversation. MCP apps extend that pattern by letting a tool declare a reference to an interactive UI in its description, which the host renders in place, per the MCP Apps overview. Compared with direct API integration, where you build and maintain custom client-side rendering for every surface, the app model standardizes delivery, sandboxing, and the message channel.
Anatomy of MCP application components
An MCP app at runtime has four moving parts:
The UI resource: the HTML bundle fetched from the server under its ui:// URI.
The tool linkage: the _meta.ui.resourceUri field on a tool description that points the host at the UI resource.
The iframe: the sandboxed container the host constructs to render the resource.
The message channel: JSON-RPC over postMessage between iframe and host.
Each part maps to a distinct responsibility in the overall architecture.
Comparing MCP app and server responsibilities
The cleanest mental model: servers execute, apps render. The host acts as a proxy between the UI iframe and the actual MCP server, receiving requests from the embedded UI and forwarding them, which means apps never execute tools directly. A button click that triggers a tool call goes through the host's ordinary audit and consent path.
MCP server functional boundaries
Servers handle tool execution, resource access, and data retrieval. Server responsibility ends at returning results. Servers do not render UI, manage interaction, or own presentation. When you run servers through Composio, server-side concerns like credential resolution and audit logging happen in Composio's execution layer, and you can scope a server to a single toolkit using single toolkit MCP or spin up instances programmatically via the MCP server instance API.
What MCP apps handle vs servers
Dimension | MCP App | MCP Server |
|---|---|---|
Primary function | Render interactive UI | Execute tools, expose resources |
UI delivery | HTML via ui:// resource in sandboxed iframe | None |
Tool execution | Requests calls through host | Executes tools directly |
Credential handling | Never touches credentials | Resolves credentials (or delegates to a managed layer) |
Session state | Not specified in the extension | Stateless per the 2026-07-28 core spec revision |
Maintenance surface | UI bundle plus host compatibility | Tool schemas plus upstream API changes |
The mcp apps vs mcp servers distinction matters most in the credential row: the app iframe is untrusted by design, so any architecture that routes tokens through it is broken on arrival.
Architectural patterns for MCP integrations
Research on MCP deployments has catalogued five recurring server architecture patterns (Resource Gateway, Tool Orchestrator, Stateful Session Server, Proxy Aggregator, and Domain-Specific Adapter) in an analysis of MCP server architectures. When you add apps to the picture, common configurations include server-only approaches where tools return structured data and the host renders it natively, app-plus-server patterns where tools declare UI resources for workflows that need interaction (approvals, dashboards, pickers), and patterns where UI delivery dominates the integration layer.
The build-vs-buy math on the underlying integration layer looks like this:
Cost factor | Custom MCP build | Managed platform (Composio) |
|---|---|---|
OAuth implementation | Weeks per app | Handled centrally |
Token refresh maintenance | Ongoing, per upstream change | Managed lifecycle |
Upstream API change | Your team's problem | Absorbed by the platform |
Architecting MCP app surfaces for AI agents
From the model's perspective, the app is invisible. The model sees a tool description that happens to carry UI metadata. Design your app surface so the tool's textual description fully describes the action, because the model's decision-making depends on the description, not the rendered pixels.
Defining the MCP app package schema
The app package centers on the UI resource declaration: the ui:// URI, the HTML content type, and the metadata that links it to one or more tools. The host constructs a Content Security Policy from domains the server declares, with a default-deny posture when nothing is declared.
How MCP apps register with models
Apps are discovered through tool metadata, not through a separate registration flow. When a tool supports MCP Apps, its description includes the _meta.ui.resourceUri field, and the host can preload the UI resource before the tool is even called. This is a meaningful design point. Discovery rides on the existing tool listing path, so anything that governs tool visibility (including a managed catalog such as Composio Connect, which exposes 1,500+ apps through a single MCP server) governs app visibility too.
How models trigger MCP app actions
The model triggers the tool, the host renders the linked UI, and user interactions become JSON-RPC messages routed back through the host's consent and audit path. The model stays in the loop through tool results, not the iframe.
Mechanism: Delivering UI components via transports
The transport mechanism is straightforward by design: the iframe speaks MCP, communicating with the host via JSON-RPC over postMessage, the same base protocol as the rest of MCP.
MCP app connectivity mechanics
Web hosts render MCP Apps HTML inside a sandboxed iframe within the conversation, and the sandbox restricts the app's access to the parent page. Hosts receive UI templates during connection setup, before tool execution, which lets the host preload and cache UI for faster rendering.
Mapping MCP actions to UI elements
The protocol treats action mapping as convention, not deep magic: the tool description declares the UI resource, the host renders it, and interactive elements inside the iframe send JSON-RPC requests (tool calls, notifications) that the host validates and forwards. The practical takeaway: every interactive element in your app UI should map to a tool that exists and is permissioned, because the host will reject anything else.
Handling session state in MCP apps
The MCP Apps specification does not formally document session state management or lifecycle. The extension standardizes emitting interactive HTML and is deliberately silent on hosting it beyond the session. At the protocol level, the 2026-07-28 revision removed the Mcp-Session-Id header and protocol-level sessions entirely, making MCP stateless. If your app needs durable state, you design that yourself today, typically by persisting server-side and rehydrating through tool calls. On the managed side, Composio documents how session semantics work across the platform in using sessions via MCP, and teams moving off per-user server instances can follow the migration guide to sessions.
Mapping the MCP app, tool, and resource stack
Apps sit on top of the existing stack; they do not replace any layer of it. An app orchestrates the user-facing side of tools and resources, while the server remains the execution and data layer.
How MCP tools enable agent action
MCP defines tools as the executable primitive: the model calls them, the server runs them, results come back. A tool is the right choice whenever the outcome is data or an action. An app action is the right choice only when a human needs to see or manipulate something interactively before or after the tool runs.
Defining data access in MCP apps
Apps access data indirectly. The iframe cannot query resources on its own authority; it asks the host, which applies its own consent and policy checks. In practice, hosts and servers carry most of the enforcement burden, but the core spec has gaps: it lacks support for exchanging role-based access control permissions at instantiation, which makes access boundaries hard to verify. If you find yourself wanting to pass a token into the iframe "just for one call," that is the signal your architecture has drifted.
How MCP apps orchestrate external tools
The orchestration pattern is: model calls tool, tool result renders in the app UI, user interaction triggers a follow-up tool call through the host, and the cycle repeats. Composio's action infrastructure spans 1,500+ business systems with more than 50,000 agent-ready tools, and Composio's platform self-learns from 1B+ tool calls run across 1M+ connected accounts to handle these orchestration loops at scale.
Execution flow: How MCP apps process requests
The end-to-end flow works like this:
The typical execution flow follows this pattern: the model selects a tool, the host fetches and renders the linked UI resource in a sandboxed iframe, the user interacts with the UI, interactions become JSON-RPC messages to the host, and the host executes follow-up tool calls against the server. The server or gateway layer resolves credentials, never the iframe and never the model's context.
MCP app model request logic
The request logic lives in three places: the model (tool selection), the host (rendering, consent, routing), and the server (execution). The app itself holds presentation logic. Keeping it that way is what makes the security model auditable.
Securing MCP app access and scopes
Hosts must render all view content in sandboxed iframes with restricted permissions, and hosts must enforce Content Security Policies built from server-declared resource metadata. Apps cannot access the parent page, steal cookies, or escape their container, which lets hosts render third-party UIs without fully trusting the server author.
Sandboxing contains the UI but does not govern tool permissions. That is a separate layer - policy enforcement and audit logging - and it is where Composio operates across those 1,000+ systems. Composio's trust center documents SOC 2 Type II and ISO/IEC 27001:2022 certifications that support enterprise security reviews.
How MCP apps process tool calls
Within an app context, every tool call still resolves a credential somewhere. In a self-built stack, that somewhere is your code, your vault, your refresh logic. Composio's execution layer handles credential resolution, token refresh, and error recovery across those 1,500+ systems, absorbing the maintenance surface so your team does not carry it; teams running agent frameworks can connect to the same catalog through the LangChain Composio integration. The 11x deployment quantified the payoff: $4.2M in enterprise deals closed and approximately 380 engineering hours recovered (vendor-reported figures documented in Composio's 11x case study; 11x has not independently published them).
If your roadmap includes more integrations than your team can maintain, Composio offers a free tier with 100,000 tool calls per month, letting you start testing your first integration without a sales call or credit card.
FAQs
Can an MCP app call multiple external APIs?
Yes, but only indirectly: the iframe requests tool calls through the host over JSON-RPC, and the host or server executes each call against the relevant API. The app itself never holds credentials or calls APIs directly.
Do MCP apps require a server component to run?
Yes. A server must serve the ui:// resource and execute the tools the UI triggers. The extension adds UI delivery, not a standalone capability.
How do MCP apps handle credential storage?
They don't. The specification keeps credentials out of the app layer entirely, so storage and refresh belong to the server or a managed layer such as Composio's AES-256 encrypted vault.
What happens when an upstream API changes?
Upstream API changes require ongoing maintenance of the server and tool schemas. With a managed platform, the vendor absorbs that breakage rather than your on-call rotation.
Key terms glossary
MCP app: Interactive UI delivered by an MCP server and rendered by a host in a sandboxed iframe, defined by the MCP Apps extension (SEP-1865).
MCP server: The protocol component that exposes tools, resources, and prompts and executes tool calls. Servers own data access; apps own presentation.
MCP tool: An executable function a model can call to retrieve data or act. Tools can declare a linked UI resource via metadata.
MCP resource: Data exposed by a server for models or apps to consume. The server layer enforces access.
Transport layer: The channel carrying MCP messages between components. For apps, this is JSON-RPC over postMessage between iframe and host.
Package schema: The declared structure of an app's UI resource, including its ui:// URI and content type. A fully ratified field-level schema is not yet published.
Iframe sandboxing: Browser-enforced restriction that isolates the app's UI from the host page. Mandatory for all MCP app rendering.
Session state: Durable state across app interactions. The 2026-07-28 spec revision removed protocol-level sessions, so teams design durable state themselves.
Action mapping: The linkage between interactive UI elements and the tools they trigger through the host. The host validates every mapped call.
Policy-as-code: Access restrictions evaluated in the request path before the model is involved. Composio enforces this at the infrastructure layer rather than through prompt instructions.
Get started
