A developer asks their agent to pull this week's error count. The agent calls a Sentry MCP server, and instead of a wall of JSON or a markdown list the model assembled from memory, a live bar chart appears inline in the chat - clickable, filterable, updating as new errors land. No context switch to the Sentry dashboard. No copy-paste. The answer is just there, in the conversation.
That is what MCP Apps makes possible, and it became a finalized, production-ready extension on January 26, 2026.
What MCP Apps actually does
MCP Apps let a server return an isolated, interactive, stateful UI alongside tool responses, rendered inline in a chat client instead of relying on the AI to generate markdown. Before this extension, every MCP tool response had to fit in text or structured data. The model would then turn that data into prose or a table. What you got depended on how the model interpreted the results - not on what the data actually looked like.
MCP Apps (SEP-1865) lets servers ship interactive HTML interfaces that hosts render in a sandboxed iframe. Tools declare their UI templates ahead of time so hosts can prefetch, cache, and security-review them before anything runs.
It gives every MCP server one way to ship an interactive HTML interface: predeclare a template as a ui:// resource, let the host render it in a sandboxed iframe, and communicate over MCP's own JSON-RPC.
The iframe is not a one-way display.
The rendered UI talks back to the host over the same JSON-RPC base protocol used everywhere else in MCP, so every UI-initiated action goes through the same audit and consent path as a direct tool call.
Claude (web and desktop), Goose, and VS Code Insiders rendered MCP Apps on launch day, ChatGPT within the week, and the official repository now lists Postman, MCPJam, and the mcp-use inspector alongside them.
The SDK, @modelcontextprotocol/ext-apps, is at v1.7.4.
The hype vs. what the spec actually says
This is the part most coverage skips. MCP Apps is real and production-ready - but it solves a specific problem: display, not reasoning. A server can now return a chart instead of a list of numbers. It cannot make the model smarter about which chart to show.
It standardizes agents emitting HTML inside a conversation. It defines nothing about hosting, sharing, or persisting that HTML beyond the session; that part still needs a publish step. If your use case requires sharing the output with someone not in the chat, you are on your own.
There is also a client gap. Six clients support MCP Apps at launch: Claude Desktop (beta), Cursor (experimental), 5ire, Sourcegraph Cody, Genkit, and the MCP Inspector. Claude Code CLI, Cursor's full editor, and Zed are notable absences. If your team lives in Zed or relies on Claude Code CLI in CI, MCP Apps does nothing for you today.
Google's response illustrates the iframe limits honestly. Reliance on iframes can lead to a fragmented user experience, characterized by aesthetic inconsistencies like clashing design systems or redundant scrollbars, while simultaneously presenting notable hurdles in both computational performance and security encapsulation. Google's A2UI alternative bypasses the iframe, allowing the host application to natively render the agent's intent using its own design system
- though that requires a different integration path entirely.
The non-obvious part: app-only tools
Here is the detail that almost no coverage of MCP Apps mentions.
A server can restrict a tool to app-only visibility so the model itself cannot invoke risky write operations - only the human user can, through the UI.
Think about what that means in practice. You can expose a delete_record tool that the LLM cannot call directly. The only path to execution is a button press in the sandboxed UI - a deliberate human action. The model proposes; the interface enforces the gate. This is a cleaner form of human-in-the-loop than anything the base protocol offered before, because the constraint is structural, not prompting-based.
MCP elicitation lets a Model Context Protocol server pause mid-task and ask the user for structured input through the client. It is how an AI agent gathers a missing detail or a confirmation without failing the whole request. Elicitation handles the "I need more input" case; app-only tool visibility handles the "this action should never fire without a click" case. They are complementary, not the same thing.
What to watch before you ship
Hosting interactive UI content from potentially untrusted MCP servers requires careful security consideration. All view content must be rendered in sandboxed iframes with restricted permissions. The sandbox limits the view from accessing the host or manipulating it. All communication with the host is done via postMessage, where the host is in control.
The sandboxing is real. The remaining risk is the server itself. A malicious MCP server or tool can appear legitimate during installation but later change its behavior. A tool described as harmless could be updated to collect confidential data or perform unauthorized actions. Pre-declared UI templates - one of MCP Apps' explicit safety features - help here because the host has the HTML before anything executes, but they only help if your host actually reviews them.
BlueRock Security found 36.7% of public MCP servers carry SSRF vulnerabilities, 41% have no authentication at all, and only 8.5% use OAuth. MCP Apps does not change that math. A beautifully rendered iframe from a server with no auth is still a server with no auth.
The larger arc is worth naming plainly: MCP has moved from a text-in, text-out protocol to something that can hold a real interactive surface. The 2026-07-28 release delivers a stateless core that scales on ordinary HTTP infrastructure, extensions including server-rendered UIs through MCP Apps and long-running work through the Tasks extension, and authorization that aligns more closely with OAuth and OpenID Connect deployments. The protocol is no longer just a smarter function-call spec. It is starting to look like a deployment target.
Whether that is good depends on how carefully you vet what you connect. The tooling for doing that is still catching up to the pace of server releases.
MCP Apps extension: common questions
What is the MCP Apps extension?
MCP Apps (SEP-1865) is an official extension to the Model Context Protocol that lets servers ship interactive HTML interfaces rendered as sandboxed iframes inside MCP clients. Tools predeclare their UI templates so hosts can cache and review them before rendering. UI actions go through the same JSON-RPC audit path as direct tool calls.
Which MCP clients support MCP Apps today?
At the July 2026 formalization, confirmed clients include Claude (web and desktop), ChatGPT, VS Code GitHub Copilot Chat, Goose, Postman, and MCPJam. Cursor's full editor, Claude Code CLI, and Zed are not yet supported. Check the official MCP Apps repository for the current list.
How is MCP Apps different from elicitation?
Elicitation lets a server pause mid-task and ask the user for a structured input - a missing parameter or a confirmation. MCP Apps returns a full interactive UI alongside a tool response. Elicitation is for gathering input before or during tool execution; MCP Apps is for delivering a richer output once a tool has run. They can work together on the same server.
Can MCP Apps tools be restricted so the model cannot call them?
Yes. A tool can be declared as app-only, which removes it from the list of tools the model can invoke directly. The only way to trigger it is through a button or form in the rendered UI - a deliberate human action. This is one of the more underused safety mechanisms the extension offers.
Is MCP Apps safe to use with third-party servers?
The iframe sandbox is real: all view content runs with restricted permissions, and all UI-to-host communication goes through auditable JSON-RPC. The risk is the server behind the UI, not the rendering layer. Verify OAuth authentication, review pre-declared HTML templates before first render, and treat each new MCP server connection with the same diligence you would apply to any third-party API integration.