MCP Apps: shipping inline UIs for MCP tools in Claude, ChatGPT and VS Code

The gap MCP Apps fills: tools that return text where a UI belongs

A plain MCP tool answers with text or structured data. That is enough for a lookup, a search, a status check. It is not enough when the useful artifact is a budget allocator, a cohort heatmap, a sheet-music editor or a 3D scene. The README puts the problem plainly: MCP tools return text and structured data, which "works for many cases, but not when you need an intera" (the sentence is cut off in the published README). MCP Apps is the extension that closes that gap. The audience is server authors who already speak MCP and now want their tool result to appear as a rendered view inside the conversation, rather than as a wall of JSON the user has to interpret. The repository ships both the specification and the SDK that implements it, which matters: you are not reverse-engineering a vendor's private protocol, you are building against a document in specification/2026-01-26/apps.mdx.

How an MCP App reaches the chat window

The architecture in the repository is a triangle. On one side is an MCP server, which owns the tool and the data. On another is a host, the chat client that the user is actually looking at. In between is the app itself, a bundle of HTML, JavaScript and CSS that the server hands to the host, which renders it inline. The SDK reflects that split in its export map: the package exposes a server entry at ./server for the MCP server side, an app entry at . for the UI side, a ./react entry for React-based views, and ./app-bridge plus ./schema.json for the plumbing and the generated protocol schema. The examples directory mirrors the same split, with examples/basic-host/ on the host side and a row of server-plus-UI examples for Preact, React, Solid, Svelte, Vue and vanilla JavaScript. That row is the clearest statement of intent in the repository: the protocol is meant to be framework-agnostic, and React is a convenience, not a requirement. The schema is generated by a script (npm run generate:schemas) rather than hand-written, so the wire format and the TypeScript types come from one source.

Installing the SDK and running a first example

The package is published as @modelcontextprotocol/ext-apps and declares Node >= 20 in its engines field, so check your runtime before anything else. The repository is a workspace root: the examples are npm workspaces under examples/*, and npm start aliases npm run examples:dev, which is the intended way to see something on screen without writing code first.

node --version
npm install @modelcontextprotocol/ext-apps

To work from the repository itself rather than from the published package, clone it and run the examples workspace. The start script is defined in package.json as npm run examples:dev, and examples/run-all.ts exists to drive more than one example at a time.

npm install
npm start

If you would rather let an agent scaffold the app, the README documents four Agent Skills and gives the Claude Code install path verbatim. Note that these are plugin marketplace commands typed inside Claude Code, not shell commands.

/plugin marketplace add modelcontextprotocol/ext-apps
/plugin install mcp-apps@modelcontextprotocol-ext-apps

The README says to verify the install by asking the agent "What skills do you have?" and checking that create-mcp-app, migrate-oai-app, add-app-to-server and convert-web-app appear in the list. The other three skills are the interesting part of that table: migrate-oai-app converts an existing OpenAI App, add-app-to-server attaches a UI to tools on a server you already run, and convert-web-app turns a standalone web app into a hybrid. If you are coming from the OpenAI Apps SDK, the migration skill is the shortest path and the README names it as such.

Where MCP Apps is the wrong choice

Host support is the hard boundary, and the repository says so itself. A note under the client list states that MCP Apps is an extension to the core MCP specification and that host support varies, pointing readers to the clients page for the full list. The supported-client badges cover ChatGPT, Claude, VS Code, Goose, Postman, MCPJam, mcp-use and Alpic. That is a respectable set and still a subset of everything that speaks MCP. If your users live in a client outside it, the app you build has no renderer, and you are back to whatever the tool returns as text. The second boundary is subtler: an embedded UI is not a web app. It runs inside someone else's surface, under that surface's layout and security rules, and the repository's own examples lean on a basic-host to stand in for a real client during development. If your interface needs its own routing, its own auth flow or its own navigation chrome, the README's convert-web-app skill exists precisely because that shape does not map cleanly onto an inline view. Third, this is a young protocol with a dated specification directory, specification/2026-01-26, and a v2.0.0 release. Treat the wire format as something that can move between spec revisions.

MCP Apps against the OpenAI Apps SDK, and against plain MCP tools

The nearest alternative is the OpenAI Apps SDK, and the difference is scope rather than features. An OpenAI App targets one vendor's client. MCP Apps targets the MCP extension surface, and the repository's client list spans ChatGPT, Claude, VS Code, Goose and several inspectors and playgrounds, which is why a migration skill from the OpenAI SDK sits in the repo at plugins/mcp-apps/skills/migrate-oai-app/SKILL.md. The trade is real: writing to one vendor's SDK gives you that vendor's guarantees and its rendering behaviour, while writing to an extension gives you reach across clients at the cost of depending on each host to implement it. The other alternative is to not use a UI at all. A plain MCP tool returning structured data is simpler, testable without a browser, and works in every MCP client by definition. Reach for MCP Apps when the interaction itself is the product, a chart the user manipulates, a form they fill in, a dashboard they read at a glance. Reach for plain tool output when the answer is a value.

Maintenance, releases and what the licence actually says

The repository is not archived and the last push was on 2026-09-09, eight days before this writing, so it is being worked on. The release history is worth reading as a signal about churn: v1.7.4 on 2026-06-05, v1.7.5 on 2026-07-23, then a jump to v2.0.0 on 2026-09-08. A major version bump two months after a patch release is the kind of thing you plan for rather than discover. The repository contains a RELEASES.md, which is where the upgrade path for that jump should be documented; read it before pinning a version in a server you ship to users. On licensing, the two sources disagree in a way you should resolve yourself. The package.json declares "license": "MIT", while the README's badge and the repository metadata both say Apache 2.0, and the LICENSE file is the authoritative text. Since MCP Apps ships both a specification and an SDK, the spec and the code may not carry the same terms. This is not legal advice; if you are redistributing the SDK or implementing the spec in a commercial product, read LICENSE and have someone qualified confirm which terms apply to which artifact.

Editorial conclusion

Adopt MCP Apps if you already run an MCP server whose tool output is a table, a chart or a form that text cannot carry, and if your users are on a client the README lists as supported. Do not adopt it if you need a UI everywhere: the README states host support varies, and a client that does not implement the extension will fall back to whatever the tool returns as text. Before writing code, verify the exact package version your client expects, and read specification/2026-01-26/apps.mdx in the repository, because that document, not the README, is what a host implementer will hold you to.

Frequently asked questions

Official sources

1. Issues
2. modelcontextprotocol/ext-apps on GitHub
3. Project website
4. README
5. Releases