MCP Apps for SaaS: What Belongs Inside ChatGPT and Claude

The short answer

Build an MCP App only for the narrow moments where a person needs to see, compare or confirm something the assistant has just found. Leave everything that needs your product's full context, history and controls inside the product, behind a clear link. And before you design any view, make the plain text answer good enough to stand alone, because the specification treats the interface as an enhancement that can disappear.

Think of the assistant as a new front door, not a replacement building. People will arrive through it with a question, and the most useful thing your product can do is show them one purposeful view, then hand them to the right room.

What an MCP App is

An MCP App lets a tool on your server return its own interface, which the assistant renders inside the conversation. The tool points to a ui:// resource, the host fetches it and shows it in a sandboxed iframe, and the view talks to the host over postMessage (MCP blog, 26 January 2026). It is the first official extension to the Model Context Protocol, and the announcement lists Claude and ChatGPT among the hosts that support it. Protocol, authentication and server setup are covered in the specification; this article is about the product decision that comes before any of that.

Two properties from the MCP Apps overview shape every design choice below. First, hosts that do not support the extension still run the tool and return text, so the interface is "a progressive enhancement, not a requirement". Second, the host "always has final say over its own UI": it decides the display mode, and your view arrives with the host's theme, locale and container size.

A decision rule: which jobs belong in the chat

Start from the job the person is doing, not from the screens you already have. Ask three questions of each job. Does the person need to see, compare or confirm something the model has just produced or found? Can it be finished in one view, without drilling into other views? Does the result still make sense without the rest of your product's context? A job that passes all three is a candidate. A job that fails any of them stays in the product, with a link.

Anthropic and OpenAI give the same boundary in their own guidelines. Anthropic's design guidelines say an MCP App works best for a task the user can finish inside the conversation, and name what to avoid: long-form content, complex multi-step workflows, deep navigation such as drill-ins, breadcrumbs or multiple views, and chat inputs that copy Claude's own. OpenAI's UI guidelines say to use visual modes "only when visual interaction improves the workflow".

If you are weighing the same question inside your own product, our piece on whether an AI product should replace its dashboard with chat covers that side of it.

What the in-chat view should and should not hold

The view is a summary of a decision, not a window onto your app. Hold it to these limits.

• One job, one view. Both hosts describe inline cards as compact: Anthropic caps them at two actions and four or five data points, and OpenAI advises against more than two actions per card, one primary and one secondary.
• No navigation inside it. No tabs, drill-ins or breadcrumbs. If the person needs another view, that is a new turn in the conversation or a link out.
• No nested scrolling. Inline views should fit their content height. If a job needs its own scrolling area, it probably wants fullscreen or the product.
• No second chat box. Typed text goes to the assistant's own input. Direct manipulation of content already on screen, such as selecting, sorting, toggling and confirming a prepared action, belongs in the view. Anthropic draws this line explicitly: anything that needs language understanding goes through chat.
• The host's look, your accent. Use the host's colour, type and spacing tokens for structure and keep your brand to accents. OpenAI asks that you do not include your logo in the response, since ChatGPT adds your app name and logo itself.
• Visible controls, not menus. Dropdowns and popovers can clip against the host container, so prefer segmented buttons, toggles and inline options.

Then decide what the model can see. A view that changes what the person has selected or staged is invisible to the assistant unless you tell it. The specification gives the view ui/update-model-context for that and ui/message for sending a follow-up into the conversation. OpenAI's lessons from building ChatGPT apps describe the same asymmetry between the user, the widget and the model, and say to decide explicitly who needs to know what. Share the selection the next question depends on. Keep the rest out of the model's context.

A worked example: approving an invoice

This is a generic B2B workflow, not a client project. Suppose a finance lead asks the assistant, "What is waiting for my approval this week?" and your product holds the invoices.

• Text only. The assistant lists four invoices with supplier, amount and due date. That answers the question, and for a person who just wants to know, it is enough.
• One in-chat view. The person says, "Show me the one from the new supplier." The view shows a single invoice: supplier, amount, due date, the purchase order it matches and the one line that does not match. It has two actions: approve, and open in the product. It does not show the supplier history, the approval chain editor or the ledger.
• Confirm. Pressing approve changes the card to a statement of what will happen, in plain words, with a final confirm. Afterwards the card shows the new status and a link to the audit trail.
• Stay in the product. Disputing a line, splitting a payment, changing the approver, and reading three years of supplier history all remain in the product. The card links to the exact record.

The principle is that the view proves its worth in one turn. If the job grows, the link carries the person across with the context intact.

Check one constraint before you design a payment step. Anthropic's Help Center states that purchases and financial transactions through third-party interactive connectors are not supported (Claude Help Center). Approving an invoice and paying it are different acts, and the host may allow only the first.

A checklist for the view's states

Every view you ship needs answers to these before it goes near a host.

1. Loading. Show a skeleton that matches the final layout. Anthropic's guidelines prefer skeletons to spinners for inline content, and OpenAI's lessons note that tool calls can take several seconds, so send as much data as you can in the first response.
2. Empty. Say what is empty and why, and what the person can ask the assistant to do next.
3. Error. Say what failed in plain words, keep the person's selection, and offer a retry or the link to the product.
4. Confirmation for write actions. Show exactly what will change before the action runs, and show the result afterwards. Our article on human-in-the-loop patterns covers the confirmation designs in depth. Mark read-only and destructive tools honestly: OpenAI's lessons say tool annotations are required and validated at submission.
5. Model context. Decide what the model sees of the view's state, as above, and send only that.
6. Handoff. Every view ends in a link to the full record in your product, so the person never reaches a dead end. The specification gives the view ui/open-link to ask the host to open it.
7. Host fit. Test light and dark themes, a narrow mobile width and keyboard use. Anthropic asks for WCAG AA contrast and tap targets of at least 44 points on mobile, and Anthropic requires every view to support light and dark themes.
8. The text path. Turn the interface off and read what the assistant returns. If the person could not act on that text alone, fix the tool result first.

Failure modes to design against

• A whole app in an iframe. Porting your main screen produces a cramped view with navigation the host does not want. Design one view per job.
• State that splits between chat and product. If a person edits something in the card and the product shows the old value, or the reverse, trust goes quickly. Keep business data on the server and use the view for temporary state only, as OpenAI advises. The server stays the source of truth, and the card reads from it.
• Write actions with no confirmation. An approve button that acts on the first press, with no statement of what changes, is the fastest way to lose a finance lead's trust. Claude also asks the user for permission before it displays an app (Anthropic's guide), but that permission is about showing the app, not about your action.
• Branding the host does not allow. Custom fonts, backgrounds and logos in the response run against the host's guidelines. Read them before you brief the design.
• Access that you cannot see. Team and Enterprise owners on Claude can disable the tool calls that render interactive elements, without switching off the connector's text. Your product has to work when they do.

Some products should ship tools with no interface

The specification makes the interface optional, so one honest answer to "should we build an MCP App?" is "not yet". If your valuable moments are a clear answer, a count or a status that the model can say in a sentence, then well-described tools and a well-shaped text result are the product in the chat. Add a view when a person must see something laid out, compare it or confirm it, and when a first release of tools has shown you which moments those are.

If you want a second view on which moments in your product pass the test, our work on AI copilots and agents starts from the same question: what does the person need to see, and what should stay where the full context lives.