MCP Apps: a real interface in the chat, without an iframe
MCP Apps moves to first class in the 2026-07-28 spec. What it changes for a SaaS, when it is worth it, and when text is enough.
The MCP 2026-07-28 revision promotes MCP Apps to first class. The principle: a server can render an interface that appears inside the client, in the conversation, without an iframe and without the user leaving their chat.
For a SaaS, this is the most interesting change in the revision, because it touches the product rather than the plumbing.
The problem it solves
A classic MCP server returns text. That works well for an answer, badly for anything visual or interactive.
Three cases where text is clearly the wrong medium:
Preview. The user just asked to create something and wants to see it before confirming. A form, a chart, a layout, a configuration.
Selecting from a set. Choosing three items out of forty by dictating their names to the model is painful. A clickable list is not.
Confirming a sensitive action. Seeing exactly what is about to change, with a button, beats a text summary.
What it changes for the product
The real effect is not aesthetic. It is that your product becomes usable without leaving the chat.
Until now the typical journey was: the user asks their agent for something, the agent calls your server, your server returns a link, the user opens your dashboard. The link breaks the flow, and plenty of users do not click.
With an interface rendered in the conversation, the loop closes where the user already is.
When it is not worth it
Worth saying too, because the temptation is to dress everything up.
When text is enough. An answer to a question gains nothing from becoming a component.
When you want to recreate your dashboard. An in-chat interface is a fragment of a journey, not a full application. If your component needs navigation, you picked the wrong medium.
When your server is purely read-only. The value comes mostly from interaction. With no action to trigger, the gain is small.
When you have not done the rest. A pretty interface on a server with a shaky OAuth chain convinces nobody.
Constraints to anticipate
Not every client renders the same thing. Your server must remain fully usable in text alone, otherwise you exclude a share of your users. The interface is an enhancement, not a dependency.
The rendering is not your dashboard. Capabilities are deliberately limited. Design for a component, not a page.
Displayed data goes through the context. What is rendered is visible to the model. Do not render in a component what you would not want sitting in a conversation history.
It is an extension. It evolves on its own schedule, which is the point of the extensions system introduced in this revision. Track its release notes like the protocol's.
Where to start
Pick one moment in your journey, the one where you lose the most users to an outbound link. Dress that one, measure, and do no others until you have a result.
In most products, that moment is preview before confirmation. It is where the user hesitates, and where a visual changes a decision.
FAQ
Does it replace my dashboard?
No, and that is not the goal. It moves the short, decisive moments into the chat. The rest keeps living on your side.
Does it work everywhere?
No. Always design an equivalent text path.
Is it an argument for a directory submission?
Yes. A preview rendered in the chat is the best way to show a product on a listing.
Get the interface layer designed
Building an MCP server runs from €4,500 to €7,500 depending on scope, interface included. If your server already exists, the addition is quoted separately after a diagnostic.
Interested? Talk about my MCP server →
Related reading
Got an MCP server to audit?
Five minutes to describe it. I reply within one business day with a first written diagnosis, free of charge.
Get my MCP server audited