MCP Apps: shipping interactive UI inside MCP tool responses
Official repo for spec & SDK of MCP Apps protocol - standard for UIs embedded AI chatbots, served by MCP servers
At a glance
- What is it?
- The ext-apps repository holds the specification and TypeScript SDK for MCP Apps, a protocol extension that lets an MCP server return a UI instead of plain text. It is worth adopting if your tool output needs a chart, a form or a dashboard, and it is the wrong choice if your client does not implement the extension.
- Who is it for?
- Adopt MCP Apps if your MCP server's tools currently return text or structured data that users must mentally reassemble into a chart, form or dashboard, and if the clients you target appear on the repository's supported clients list. Do not adopt it for a server whose consumers are headless agents, scripts or any host that does not implement the extension, because the UI payload has no defined fallback there.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap MCP Apps fills in a tool response
A standard MCP tool returns text and structured data. The README states that this works for many cases but not when an interactive element is needed. The concrete failure is a tool whose useful output is a shape rather than a sentence: a time series that should be a chart, a set of parameters that should be a form, a group of metrics that should be a dashboard. Today the model receives the data and re-describes it in prose, or the user copies it somewhere else to look at it properly. MCP Apps defines a way for the MCP server itself to serve a UI that renders inline in the chat client, so the chart is the tool result. The audience is MCP server authors who already have a tool and want its output to be manipulated rather than read, plus teams with an existing web app who want the same surface reachable from inside a chat client. The repository is the official home for both the specification and the SDK, which matters if you are deciding whether to build against a draft or a maintained extension.
Server serves the UI, client renders it inline
The architectural inversion is the part worth internalising. In the usual web model the browser fetches from your backend. Here the MCP server is the origin of the UI, and the chat client is the renderer. A tool call that would previously have returned a JSON blob instead carries an app, and the client displays it inline in the conversation. The README frames this as UIs "served by MCP servers" and rendered in Claude, ChatGPT and other compliant chat clients. The repository does not spell out the full wire format in the README itself; that lives in specification/2026-01-26/apps.mdx, and the API reference is published at apps.extensions.modelcontextprotocol.io/api/. Treat the spec file as the source of truth for message shapes and lifecycle, because the README is orientation material rather than a protocol description. One consequence of this model is that the client is a runtime you do not control. Its capabilities, its sandboxing and its update cadence all sit between your server and the user, which is the trade you accept in exchange for not building a separate front end.
Getting a scaffold running with the Agent Skills plugin
The repository's fastest documented path is not a CLI generator but four Agent Skills shipped in plugins/mcp-apps/skills/. They are create-mcp-app, migrate-oai-app, add-app-to-server and convert-web-app, and the README describes what each does: scaffold a new app, convert an existing OpenAI App, add UI to an existing MCP server's tools, and turn a web app into a hybrid web plus MCP App. Installation for Claude Code is two commands from the README:
/plugin marketplace add modelcontextprotocol/ext-apps /plugin install mcp-apps@modelcontextprotocol-ext-apps
For other agents, docs/agent-skills.md covers manual installation. The README gives a verification step that is easy to skip and worth doing: ask the agent "What skills do you have?" and confirm the four skill names appear in the list before asking it to build anything. The package itself is published on npm as @modelcontextprotocol/ext-apps, and the quickstart is at apps.extensions.modelcontextprotocol.io/api/documents/quickstart.html. If you would rather not route scaffolding through an agent, the SDK page in the README and the API reference are the direct entry points.
The client support matrix is the real constraint
The README carries a note that MCP Apps is an extension to the core MCP specification and that host support varies, pointing to the clients page at modelcontextprotocol.io/clients. The supported clients section links documentation for ChatGPT, Claude, VS Code, Goose, Postman, MCPJam, mcp-use and Alpic. That list is the boundary of the project's usefulness. An MCP server that returns an app payload to a host which does not implement the extension is not degraded gracefully in any way the README describes; the material does not state what a non-compliant host does with the payload. If your server is consumed by headless agents, CI scripts, or a host absent from that list, MCP Apps adds a surface you cannot exercise. This is the case where it is the wrong tool, and it is not a hypothetical: extension adoption across chat clients is uneven by definition, which is why the repository separates the core specification from this one.
Where MCP Apps sits next to the OpenAI Apps SDK
The most direct comparison is the one the repository itself makes. One of the four skills, migrate-oai-app, exists to convert an existing OpenAI App to use MCP Apps, and the README's trigger phrase for it is "Migrate from OpenAI Apps SDK". The difference in approach is portability. An app built against a single vendor's SDK targets that vendor's client; an app built against MCP Apps targets the extension, and the supported clients list spans ChatGPT, Claude, VS Code, Goose and several inspectors. That breadth is the reason the migration skill exists at all, and it is also the cost: you are writing against a specification plus an SDK rather than one company's product surface, so you inherit the extension's versioning and the client-by-client variance in how compliant each host actually is. If you only ever intend to ship inside one client, the vendor SDK is the shorter path and the migration skill is not for you.
Versioning, maintenance and the licence question
The release history shows v2.0.0 published on 2026-09-08, v1.7.5 on 2026-07-23 and v1.7.4 on 2026-06-05, with the repository's last push on 2026-09-09. A major version bump one day before the last recorded push is the kind of signal that should change how you pin dependencies: check the release notes for v2.0.0 before upgrading from 1.7.x, and pin an exact version rather than a caret range if you are shipping a server that others depend on. On cost, the honest answer from the available material is that this is a specification and SDK, not a hosted service, so there is no infrastructure bill attached to it. The maintenance burden is the one you would expect from a protocol extension: spec revisions, SDK releases, and the need to re-verify behaviour against each host as hosts update. On licensing, the repository's metadata reports NOASSERTION for the licence field, while the README's badge and the LICENSE link both indicate Apache 2.0. Those two signals disagree, and the discrepancy is worth resolving against the LICENSE file itself before you rely on either. I am not in a position to give legal advice on what that means for your distribution; the point is simply that the machine-readable field and the badge do not match, so read the actual file.
What to check before you commit a sprint to it
Start with the spec file at specification/2026-01-26/apps.mdx and confirm that the lifecycle it describes matches what your target host implements. Then take the quickstart at apps.extensions.modelcontextprotocol.io/api/documents/quickstart.html and build the smallest possible app against your real host, not an inspector, before investing in a full UI. The inspectors (MCPJam, mcp-use, Alpic's playground) are useful for iterating on the app itself, but they will not tell you whether the client your users actually open behaves the same way. The README's own demo is Excalidraw running in Claude, which is a useful existence proof and not a compatibility guarantee for your host. If the smallest app renders, the Agent Skills route (create-mcp-app for new work, add-app-to-server for a tool you already have) is the documented way to scale up from there. If it does not render, you have learned that before writing the chart component, which is the cheapest possible time to find out.
Editorial conclusion
Adopt MCP Apps if your MCP server's tools currently return text or structured data that users must mentally reassemble into a chart, form or dashboard, and if the clients you target appear on the repository's supported clients list. Do not adopt it for a server whose consumers are headless agents, scripts or any host that does not implement the extension, because the UI payload has no defined fallback there. Before writing code, verify three things: that your target host is listed as a supported client, that the specification version under specification/2026-01-26/apps.mdx matches the host's implementation, and that the SDK version you install is v2.0.0 or later given the major bump from v1.7.5.
Community notes