MCP Apps Put 9 SaaS Front Ends Inside the Chat. Here Is What They Gave Up

MCP Apps went live on 26 January 2026 as the first official extension to the Model Context Protocol, and Claude shipped it the same day with 9 working vendor apps. A tool call can now return a vendor's own interactive screen, rendered inside the chat. The vendor still writes the HTML. The host decides almost everything around it, and that split is the real story for the SaaS front end.

How MCP Apps work: a vendor screen inside a sandboxed frame

MCP Apps is an extension to the Model Context Protocol that lets a server attach an HTML interface to a tool. When the model calls that tool, the chat client fetches the interface from a ui:// resource, renders it in a sandboxed iframe, and passes data both ways over JSON-RPC. The vendor writes the screen. The host frames it.

The extension identifier is io.modelcontextprotocol/ui. A host that supports it says so in its capabilities and lists the MIME type text/html;profile=mcp-app. The specification is labelled Stable as of 26 January 2026, and SEP-1865, the proposal behind it, is marked Final. Its authors came from Anthropic, OpenAI and the open-source MCP-UI project, which is why one server can render in more than one client.

The ui:// resource and the postMessage bridge

A tool points at its interface through a field called _meta.ui.resourceUri. The host fetches that resource, places it in an iframe, and the two sides talk over postMessage. On a web host the rule is stricter: the view must sit inside an intermediate sandbox proxy on a different origin from the host page.

From inside the frame, the view can do a short list of things. It can call tools, read resources, post a message into the conversation with ui/message, ask to open a link, ask for a different display mode, and push context to the model with ui/update-model-context. Everything else goes through the host, or it does not happen.

Network access is opt-in. The server declares four lists of allowed domains for connections, resources, frames and base URIs. The specification says the host "MUST NOT allow undeclared domains", and with no declaration at all it defaults to blocking outbound connections. A vendor view that quietly calls an analytics endpoint does not survive this model.

Tools the model never sees

The quietest change is tool visibility. A tool can be marked app-only, which the specification describes as hidden from the model. The host must leave it out of the agent's tool list, and must reject any call from a view to a tool that is not marked for the app.

This is the line between conversation and interface. A sort control, a pagination button or a filter can call your server directly, without the model reasoning about it. That is cheaper, faster and more predictable, and it is the part of the design that most resembles a normal web front end.

Our view is that app-only tools are the most underrated line in the specification for SaaS vendors. They keep deterministic behaviour deterministic, instead of routing every click through a model that may paraphrase it.

The MCP Apps timeline, from ChatGPT apps to an open standard

The standard did not start as a standard. OpenAI launched apps inside ChatGPT at its DevDay conference in October 2025, with an Apps SDK built on MCP. Launch partners were Booking.com, Canva, Coursera, Figma, Expedia, Spotify and Zillow, according to AFP reporting carried by Business Today. In parallel, the MCP-UI project had been building interface primitives for MCP servers.

On 21 November 2025 the MCP blog published a joint proposal from Anthropic, OpenAI and MCP-UI contributors. It limited the first version to HTML and explicitly deferred external URLs, remote DOM and native widgets. That choice matters to vendors: your in-chat screen is a web page in a box, not a native component of the host.

On 26 January 2026 the core maintainers announced MCP Apps as "the first official MCP extension" and called it ready for production. Claude, Goose and Visual Studio Code Insiders had support that day, with ChatGPT starting the same week. Microsoft followed on 7 April 2026, when its developer blog announced MCP Apps inside Microsoft 365 Copilot chat.

The ext-apps repository README now shows 8 client logos, including Postman and MCPJam alongside the large chat products. Several companies quoted in the January announcement, among them JetBrains, AWS for Kiro and Google DeepMind for Antigravity, described support in the future tense. Treat those as intentions, not shipped hosts.

If you want the background on why MCP became the default integration layer at all, the earlier analysis of how MCP became the agent interoperability standard covers the protocol's adoption. This post is only about the interface layer that now sits on top of it.

Nine MCP Apps at launch, and the scope of UI each exposes

Anthropic's launch post lists 10 partners, each with a one-line description of what its in-chat interface does. Salesforce is marked "Coming soon." The other 9 were live, and the post says they work on Claude mobile, web and desktop across the Free, Pro, Max, Team and Enterprise plans.

We sorted the 9 into three scopes using only those published descriptions. Look means the user reads and explores data. Make means the user produces a draft or artefact that finishes in the vendor's tool. Commit means the app writes to the vendor's system of record from the chat.

Descriptions are condensed from Anthropic's launch post of 26 January 2026. The Look, Make and Commit labels are our classification of those descriptions, not the vendors' own terms, and they say nothing about how often each app is used.

Look: the vendor becomes a chart inside someone else's answer

Amplitude, Box and Hex expose read and explore interfaces. Amplitude builds charts you can adjust in place. Hex returns answers with interactive charts and citations. Box searches and previews documents without leaving the conversation.

These are the cheapest apps to build and the most exposed to substitution. If the host can draw a passable chart from your API output, the only reason to ship your own view is that yours is better. The other reason is permissioned data that a generic chart cannot reproduce faithfully.

Make: drafts that still finish in the vendor's own tool

Canva, Figma and Clay create something. Canva builds deck outlines and lets you adjust branding live. Figma turns prompts into diagrams in FigJam. Clay researches accounts, pulls contact data and drafts personalised outreach.

The artefact lives in the vendor's system, and serious editing still happens there. That is a deliberate funnel. The chat is the top of it, and the vendor's own canvas stays the place where paying users spend their hours.

Commit: writing to the system of record from a chat window

Asana, monday.com and Slack write back. Asana turns a conversation into projects and timelines. monday.com updates boards and assigns tasks. Slack drafts messages and lets you format and review them before you post.

This tier carries the most risk and the most value. A wrong write to a project board or a public channel is a real event with real readers. Slack's description puts review before posting, and every commit-tier app should copy that pattern. The design questions here are the same ones covered in the human-in-the-loop architecture guide.

Who owns the screen: the MCP Apps control map

Reading the specification next to the published host rules gives a clear answer. Of the 12 layers we mapped, the host controls 5 outright and the vendor keeps 3. The other 4 are negotiated: the vendor asks, and the host decides.

The host owns the frame, the fonts, the logo placement, the action budget and the directory listing. The vendor owns layout inside the frame, all business logic and data, and authentication. The negotiated layers are network access, colour, display mode and what the model gets told.

The specification itself is lighter than the hosts. It lets hosts pass CSS variables for colour, fonts, radii and shadows, but deliberately leaves out spacing. Its stated reason is that "layouts break when spacing varies from original design". That one sentence protects more vendor identity than any other line in the document.

Display mode works the same way. A view can request inline, fullscreen or picture-in-picture. The host replies with the mode it actually granted, and it must not switch the view into a mode the view did not declare. The vendor can ask for the whole screen. It cannot take it.

We think "who owns the screen" is slightly the wrong worry. The host owns the frame, which is narrower. The more consequential loss happens before any screen appears, because the model decides whether your tool gets called at all. That shift in where distribution value sits is the subject of the analysis of who captures value in agent marketplaces.

One MCP Apps standard, three different hosts

A shared specification does not mean a shared experience. Each host publishes its own subset and its own rules, and they diverge on things a vendor's design team will notice in the first week of a build.

"Not stated" means the source we read did not say, not that the feature is absent. Anthropic may publish rules elsewhere. Treat the Claude column as the least complete.

ChatGPT's rules are the strictest published

OpenAI's developer guidelines, now filed under the name Plugins, are explicit. Inline cards support "up to two actions maximum, with one primary CTA and one optional secondary CTA". Cards may not scroll internally, may not hold deep navigation, and carousels hold 3 to 8 items.

Brand is boxed in too. Apps must inherit the system font stack and may not use custom fonts "even in full screen modes." Partners may add accents and icons but should not redefine system colours. Vendors may not place their logo in the response, because ChatGPT appends the logo and app name itself.

Commerce is narrow. OpenAI's plugin guidelines allow sales of physical goods only, through external checkout on your own domain, and prohibit advertising pricing, trials or discounts. Ads are banned outright. For a SaaS vendor hoping the chat surface would become a self-serve upgrade path, that rule closes the door for now.

Microsoft's subset is different again. Its Learn documentation, last updated 30 September 2026, serves widgets from a Microsoft-owned hashed subdomain, honours only the connect and resource domain lists, and marks file upload and modals as unsupported. The April blog describes an optional side by side mode that the Learn page does not list. That inconsistency is itself the signal: the host surface is still moving.

What the SaaS front end keeps, and what it gives up

Put plainly, the vendor keeps the parts that are expensive to copy and gives up the parts that were cheap to own. It keeps the data model, permissions, business logic, the deterministic interactions behind app-only tools, and the full product the user returns to. It gives up first contact, the navigation shell, typography and, in ChatGPT, the logo.

This sharpens the argument that the dashboard is losing its role as the primary interface. MCP Apps is the mechanism that makes it concrete, and it is gentler than the obituary version. The dashboard does not die. It gets cut into cards, one task at a time, and each card is rendered inside a frame somebody else designed.

The seat economics follow. When a user approves a Slack draft or updates a monday.com board from inside Claude, the vendor's own app records less time in product. Usage that once justified a seat arrives as a tool call authenticated as that user. That is the same pressure described in the analysis of seat compression in SaaS pricing, now with an interface attached.

Our position is that the commit tier is where vendors should build first. A host can draw a chart from anyone's API. It cannot become your system of record without rebuilding your product. If we were shipping one MCP App this quarter, it would be a single commit action with a review step, not a read-only dashboard card.

The design job changes as well. A team that spent years refining navigation now writes for a frame with two buttons and the host's fonts. That moves the craft toward constraints, a shift examined in the piece on what generative UI does to the designer's role.

Security does not get easier because the UI is sandboxed. Every MCP App is still an MCP server with tools and credentials behind it, so the risks in the MCP server supply chain analysis apply unchanged. The MCP maintainers themselves told users to keep vetting servers before connecting them.

Where this argument is weakest

Three parts of this analysis are thinner than we would like, and each could change the conclusion.

Launch lists are not usage

Every vendor figure in this post comes from a launch announcement. None of the three hosts has published how often apps are invoked, how many users connect them, or whether interactive views outperform plain text answers. The 9, the 18 and the even three-way split are counts of announcements and one-line descriptions, not measurements of behaviour.

The Look, Make and Commit labels are our judgement on marketing copy. A vendor could reasonably argue that Clay belongs in Commit or that Canva is closer to Look. Sources also disagree at the edges: Anthropic's post lists Claude mobile, while the MCP maintainers named only web and desktop on the same day.

The text fallback may matter more than the screen

The November proposal said servers should provide a text-only fallback for every UI-enabled tool. If most invocations end as text, through hosts that render nothing or users who never expand a card, then the real competition is in tool descriptions and returned data, not in iframes. Public data cannot rule that out, and a vendor who over-invests in the view while neglecting the tool description could lose on both.

The strongest competing view is that none of this displaces the SaaS front end at all. Power users will keep working in the native app, and MCP Apps will stay a convenience layer for light tasks. We think that is right for the next year and wrong for the occasional user, who is exactly the seat a renewal negotiation targets.

Frequently asked questions

How to decide what your MCP App should be

Start with a list, not a build. Write down the 5 tasks your occasional users perform most often, and label each one Look, Make or Commit using the table above. Pick the single Commit task with the clearest review step, and scope an MCP App around that task alone, with app-only tools behind every deterministic control.

Then design to the strictest host first. Mock the screen with 2 actions, the system font stack, no internal scroll and no logo, then check it in a host that renders nothing at all. If the task still works as a text answer and as that constrained card, it will work everywhere the standard reaches.

Related reading