Your Product's UI Is Moving Inside the Chat Window: What MCP Apps Mean for Every Web Platform

MCP gave agents access to data and actions, but the results came back as text. Exploring anything meant another prompt every time: sort by revenue, only last week, show me row 47. Each follow-up is a round trip through the model, and the user is left reading a table that was flattened into sentences. MCP Apps closes that gap by letting a tool hand back a real interface instead.

How it works, in three sentences

A tool declares that it has a UI by pointing its _meta.ui.resourceUri at a resource on your MCP server. That resource is a bundle of HTML and JavaScript served under a ui:// address. The AI client renders it in a sandboxed iframe, and the UI and the client talk to each other through a standard, auditable message channel.

The detail that matters most: the model stays in the loop. The UI can call your server’s tools directly and quietly update the model’s context ("the user selected option B"), so the conversation and the interface stay in sync. The user can click through a dashboard and then ask a follow-up question about what they just filtered, and the model knows what they are looking at.

At launch, MCP Apps rendered in Claude (web and desktop), Goose, and Visual Studio Code, with ChatGPT support rolling out the same week. The July 2026 MCP specification then brought Apps into a formal, versioned extensions framework, and clients that do not support it fall back to plain tool results. One build, many hosts, no client-specific code.

Is this the only standard?

MCP Apps standardizes patterns pioneered by the community MCP-UI project and OpenAI’s Apps SDK, and both backed the official extension. Google’s A2UI takes a separate approach. Our view: the official MCP extension is the lower-risk bet today, because it rides on the protocol your agent-callable tools already speak.

The announcement describes four kinds of experience. Reframed for the SaaS products, customer portals, and internal tools we build, they look like this:

• Data exploration. A client portal’s reporting view, filterable inside the chat instead of behind a login and three menus.
• Configuration and intake. A quote builder or onboarding form with dependent fields, completed without leaving the conversation.
• Review and approval. A document or contract with highlighted sections the user approves or flags, while the model sees each decision.
• Live status. An order, project, or system status view that updates in place rather than going stale in a text reply.

The point to take away is that this is distribution. Your product shows up wherever your users already work with AI, rather than waiting for them to open a new tab, find the bookmark, and sign in. For internal tools the effect is even more direct: staff who live in Claude or VS Code all day can approve, review, or check status without switching context.

We have already worked the opposite direction. In Building Ask, we described putting an AI assistant inside our own website. MCP Apps is the inverse: putting a focused piece of your website inside the assistant.

Most MCP Apps coverage stops at the demo. The demo is real, but it hides five decisions every product owner should make before a line of UI code is written.

1. Whose front door is it?

When the AI client becomes the entry point, you gain reach but lose control of the surrounding experience. Some products benefit: a status check or an approval is faster in the chat than on your site. Others commoditize themselves, because a customer who only ever sees one small view of your product inside someone else’s interface can start to see you as a feature of that interface. Decide which of your workflows gain from reach and which depend on your own front door.

2. What happens to your brand and design system?

Your UI renders in a small, sandboxed frame inside another company’s product, next to their styling and their light or dark theme. A component system built on design tokens, like our shadcn/ui and Tailwind approach, adapts well because color, spacing, and type are variables rather than hard-coded values. A one-off marketing site with styles baked into every page does not.

3. How do auth and permissions cross the boundary?

Which user is acting, with what scope, and how is a session revoked? The UI can trigger tool calls, and hosts can require explicit user consent before those calls run. Treat that as a design input from the start: scope tokens tightly, make destructive actions confirmable, and make sure revoking access in your platform actually ends the in-chat session.

4. Where do your analytics go?

Page views, funnels, and conversion tracking all assume users are on your site. Engagement inside a host you do not own will not show up in your usual dashboards unless you plan for it. Log tool calls and UI events on your server, tag them as in-chat traffic, and decide up front which outcomes count as success.

5. What are you willing to run inside someone else’s product?

The extension has real security layers built in: the UI runs in a sandboxed iframe with restricted permissions, templates are declared ahead of time so the host can review them before rendering, every message between the UI and the host is auditable, and hosts can gate tool calls behind user consent. The other side matters just as much. Users and IT teams should vet any MCP server before connecting it, which means your documentation, permissions model, and transparency become part of the product.

“Not every product should do this. If your value depends on a long, immersive session on your own site, an in-chat app may be a teaser, not a replacement.”

Whether you can ship an MCP App in a sprint or need a rebuild first is an architecture question, not a feature question. Four things decide it.

• A clean, agent-callable API layer. An MCP App is a UI on top of MCP tools. If the tools do not exist, the app has nothing to call. This is the work described in our agent-callable APIs post, and it comes first.
• A component-based front end. Apps ship as bundled HTML and JavaScript. Teams already building with composable components (React, a modern UI component system, TanStack) can package a focused view. Teams on a page-template CMS usually cannot without a rebuild.
• Small, purposeful views. An MCP App does a single job: a chart, a form, an approval. It is not your whole product. Deciding what to leave out is a product decision, not an engineering one.
• Observability that distinguishes agent traffic. Log in-chat interactions separately from on-site use so you can see what is working and roll back safely. We covered the production side of this in Your In-App AI Feature Survived the Demo.

The contrast is stark. A brochure site on WordPress or Squarespace is not positioned for this at all. A custom platform with a real API and a component library is most of the way there. That gap is the same one we described in Beyond WordPress, and MCP Apps widens it.

Move now if

• You run a SaaS product, customer portal, or internal tool with a repeatable workflow such as reporting, intake, approvals, or status.
• Your users or staff already work in Claude, ChatGPT, or VS Code daily.
• You already have, or are building, MCP tools.

Wait if

• You do not yet have an API layer agents can call. Fix that first.
• Your product’s value is the full, immersive on-site experience.

Four first steps

1. Audit your API and MCP surface. List the tools an agent could call today and the gaps that block a useful view.
2. Pick the one workflow users repeat most often. Reporting, intake, approvals, or status are the usual candidates.
3. Prototype a single MCP App for it. Keep it behind a flag or limited to an internal group.
4. Measure usage and decide whether to expand. Compare in-chat completion against the same task on your site.