Which clients support MCP Apps?

#Which clients support MCP Apps today

As of October 2026, MCP Apps render in Claude (web, desktop and mobile), ChatGPT, VS Code with GitHub Copilot, Microsoft 365 Copilot, Cursor, Goose, Postman and MCPJam, and the official client matrix also lists Archestra.AI and PostHog Code. Claude Code and other terminal agents do not render them: they call the tool and use its text. If you are new to the extension itself, start with What are MCP Apps.

One caveat before the table: the client matrix is maintained by the community through pull requests, and hosts ship changes often. Treat the list below as a snapshot with sources, and check the host's own docs before you promise a feature to anyone.

A client that supports the extension advertises it when it connects, under capabilities.extensions["io.modelcontextprotocol/ui"]. Your server does not need to check: hosts without support simply ignore the _meta.ui on your tools.

#Claude on the web, desktop and mobile

Claude was one of the first hosts, on the day the extension became official. On the web and in the desktop app, an MCP App appears as an inline card, an inline carousel or a full screen view, and the design guidelines set clear limits for inline cards: the height fits the content with no nested scrolling, at most two actions, and no menus or popovers that the host container could clip (design guidelines).

Points that catch people out:

• Mobile is a WebView, not an iframe. On iOS and Android, Claude renders apps in WKWebView and Android WebView. Apps on mobile have no camera, microphone or location access, and a connector must be added on web or desktop before it shows up on mobile.
• frameDomains is restricted. Embedding third-party iframes "is restricted in Claude pending security review". If your view embeds a video player or a map from another site, expect it to stay blank in Claude.
• Host style variables. Claude sends its colors, fonts and radii as CSS variables, in light and dark. A view that reads them looks native; one with a fixed palette looks pasted in. See theming MCP Apps.
• localhost is not reachable by URL. A server added by URL on claude.ai or in the desktop app is reached from Anthropic's infrastructure, so a localhost address does not work. Use a tunnel or a deployed server while you test, or run it through the desktop app's configuration file.

#ChatGPT, now with plugins

ChatGPT started rolling out MCP Apps the week the extension went stable, and OpenAI's changelog marks it "fully compatible with the MCP Apps spec" on 22 February 2026. On 28 May 2026 ChatGPT also started sending the standard host CSS variables.

Two things changed around it. First, OpenAI says new UI should use the shared MCP Apps fields and bridge, and window.openai only for capabilities the specification does not cover, such as checkout, modals, file uploads and saved widget state (MCP Apps in ChatGPT). The older keys (openai/outputTemplate, text/html+skybridge) still work as compatibility aliases. Second, on 9 July 2026 OpenAI replaced the App Directory with the Plugin Directory, and the developer docs moved under developers.openai.com/plugins. Apps keep working underneath plugins. The ChatGPT plugin UI guide covers the migration.

ChatGPT blocks nested frames by default, and plugin review checks the CSP you declare (ChatGPT UI docs).

#VS Code and GitHub Copilot

VS Code shipped MCP Apps in Insiders on 26 January 2026 and in Stable the following week, inside GitHub Copilot's agent chat. For developers this is the most convenient place to see a UI next to the code that produces it: you can run your server locally and connect it to VS Code without a tunnel.

#Microsoft 365 Copilot

MCP Apps support in Microsoft 365 Copilot Chat is generally available as of March 2026. Microsoft documents deployment through sideloading for tests, the Microsoft 365 admin center for organizations and the agent store, and its Power Apps team offers a preview skill, generate-mcp-app-ui, that writes widget HTML with Fluent UI tokens for a tool's JSON output (Microsoft Learn).

#Cursor

Cursor added MCP Apps in version 2.6, released on 3 March 2026, with interactive UI rendered in the agent chat (changelog). Its docs state the fallback plainly: "If a host cannot render app UI, the same tool still works through normal MCP responses" (Cursor docs).

#Goose, Postman and MCPJam

Goose supported MCP Apps on launch day, after being one of the early adopters of MCP-UI. Its docs describe apps that render inline in the conversation and apps that open in their own window, and mark the feature as experimental and in active development (goose docs).

Postman was an early MCP-UI adopter and appears in the client matrix as an MCP Apps host. It is handy for calling a server's tools by hand and checking what comes back.

MCPJam is an MCP inspector with an Apps Builder: a local emulator for MCP Apps and ChatGPT apps (MCPJam blog). It is a testing tool, not a chat you use day to day.

#Claude Code and other terminal agents

Claude Code does not render MCP Apps. Anthropic's quickstart says it directly: "Claude Code calls the tool as text and doesn't render the UI" (Claude docs). As of October 2026 a feature request to render ui:// resources is open (anthropics/claude-code#95149). Assume the same for any terminal agent that is not in the client matrix until its docs say otherwise.

Your tool still runs there. What the model gets is the tool result, so the result has to make sense without the view. The same quickstart notes one detail: when the tool returns structuredContent, Claude Code gives the model that JSON instead of your content text.

#How to write a good text fallback

Write both halves of the result for a reader who will never see the UI:

• Put a real summary in content. Say what the widget shows, with the numbers that matter: "Board Beta launch: 2 cards to do, 2 in progress (one due 5 Oct), 1 done." Not "Showing widget".
• Keep structuredContent readable. Clear key names (dueDate, not d), no presentation noise such as colors or pixel sizes, and units in the names or values. A model that only sees the JSON should still be able to answer "what's late?".
• Don't hide facts in the view. If the view computes a total or flags an overdue card, compute it on the server too and include it in the result.
• Describe the tool for the model, not for the UI. The tool description decides when the model calls it. "Shows a project board with columns and cards" works in every host.

return {
  content: [{ type: 'text', text: 'Board "Beta launch": 2 to do, 2 in progress (1 due 2026-10-05), 1 done.' }],
  structuredContent: data,
}

If you use Widgetry's export snippet, its handler returns a short Showing <title> line. That is fine for hosts that render the view; if your server is also used from terminal agents, build that line from the data as above.

#How to test a widget without every host

You won't keep accounts in ten hosts, and you don't need to for most of the work.

• A local host or inspector. MCPJam's Apps Builder emulates MCP Apps and ChatGPT apps locally. Several frameworks ship their own: sunpeak has local ChatGPT and Claude simulators, Skybridge has an emulator, mcp-use has an inspector, and FastMCP has fastmcp dev apps for Python servers.
• VS Code. Connect your local server to GitHub Copilot's chat and see the view without deploying.
• The Widgetry editor. If you build the widget in Widgetry, the preview is a real MCP Apps host built on the official SDK's AppBridge. It runs the same handshake, sends the tool data the same way, switches between light and dark, and applies the widget's image CSP, so a photo from an undeclared domain is blocked in the preview just as it would be in Claude.
• The hosted endpoint. Publish the widget and connect https://widgets.gonzaloverdugo.com/mcp to a real host: claude.ai and other clients that support OAuth sign in with your account, and coding agents use an API key as a Bearer token. You get one show_<slug> tool per published widget, so you can try it in Claude, ChatGPT or VS Code before you touch your own server. Then take it to your server.

Before you ship, test in at least two real hosts. The most common difference between them is the CSP: a policy that works in one host can leave the view blank in another (Claude restricts frameDomains, for example). The CSP guide has the checklist.