MCP-UI: A TypeScript SDK for Rendering Tool Interfaces Over the Model Context Protocol
UI over MCP. Create next-gen UI experiences with the protocol and SDK!
At a glance
- What is it?
- MCP-UI is an SDK that implements the MCP Apps standard, letting MCP hosts fetch and render HTML UIs linked to tools. This review covers its architecture, setup, and the trade-offs of adopting it.
- Who is it for?
- Adopt MCP-UI if you are building an MCP host that needs to render tool-supplied HTML interfaces, or a tool server that wants to provide such UIs, and if you can accept the security burden of sandboxing arbitrary HTML. Do not adopt it if your tools only need plain text output or if your hosts cannot handle the `_meta.ui.resourceUri` link and the `text/html;profile=mcp-app` MIME type.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 70 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
What MCP-UI Solves and Who It Is For
MCP-UI addresses a gap in the Model Context Protocol: tools can return text, but they cannot easily present rich, interactive web interfaces. The README explains that MCP-UI pioneered the concept of interactive UI over MCP and that its patterns influenced the MCP Apps specification. The project now implements that specification, providing SDKs in TypeScript, Ruby, and Python. The primary audience is developers building MCP hosts, such as chat clients or agent frameworks, that want to display tool results as HTML widgets, and developers building MCP servers that want to offer such widgets. If you are on either side of that exchange, MCP-UI gives you a standard way to link tools to their UIs.
The MCP Apps Pattern: Linking Tools to UIs via _meta
The core mechanism is the MCP Apps pattern. A server creates a UI resource with `createUIResource` from `@mcp-ui/server`, then registers it with `registerAppResource`. The tool itself is registered with `registerAppTool`, and crucially, the tool's `_meta` field contains a `ui.resourceUri` that points to the UI resource. When a host calls the tool, it sees this URI, fetches the resource via `resources/read`, and renders it. This indirection means the UI is not embedded in the tool result but is fetched separately. That separation allows the same UI to be reused across multiple tool calls and keeps the tool result payload small. The README shows the wire format: a `UIResource` with a `uri` using the `ui://` scheme and a MIME type of `text/html;profile=mcp-app`. Content can be plain text or Base64-encoded HTML in a `blob` field.
Client Rendering: AppRenderer and UIResourceRenderer
On the host side, the `@mcp-ui/client` package offers two components. `AppRenderer` is for MCP Apps hosts. It takes props such as `client`, `toolName`, `sandbox`, `toolInput`, and `toolResult`, and it handles fetching the UI resource automatically if you pass an MCP client. It also accepts `onOpenLink` and `onMessage` callbacks for UI requests. `UIResourceRenderer` is for legacy MCP-UI hosts that embed resources directly in tool responses. It takes a `resource` object and an `onUIAction` callback that handles tool, prompt, link, notify, and intent actions. There is also a Web Component version, `<ui-resource-renderer>`, which you can use without a framework. The README notes that HTML content is rendered inside an `<iframe>` via an internal component, which is a deliberate isolation choice.
Getting Started: Installation and Configuration
The README does not give a full installation command sequence, but the badges point to npm packages: `@mcp-ui/server` and `@mcp-ui/client`. You would install the server package in your MCP server project and the client package in your host project. The code examples show imports from `@modelcontextprotocol/ext-apps/server` for `registerAppTool` and `registerAppResource`, so you also need that dependency. For the server side, you call `createUIResource` with a URI and content, then register a resource handler. For the client side, you render `<AppRenderer>` with the required props. The `sandbox` prop is critical: it takes an object with a `url` field, which is a proxy URL for the iframe. The README does not explain how to set up that proxy, which is a gap you must fill from other documentation. The Python and Ruby packages (`mcp-ui-server` and `mcp_ui_server`) exist for server-side resource creation, but the README gives no usage examples for them.
Security and the Sandbox: The Central Trade-Off
The most significant limitation is the security model. The SDK renders HTML inside an iframe, but arbitrary HTML from an MCP tool can contain scripts. The README mentions a `sandbox` prop with a proxy URL, but it does not describe what the proxy does or what protections it offers. Without a properly configured sandbox, a malicious or buggy tool could inject scripts that run in the host's origin. The README's security section is listed but not included in the material, so the exact guidance is unknown. This is not a tool for hosts that cannot afford to sandbox third-party HTML. If you are building a host that connects to untrusted MCP servers, you must verify that the iframe sandbox attributes and the proxy actually prevent script execution. The documentation's brevity on this point is a reason for caution.
Alternatives: MCP Apps Specification vs. Legacy MCP-UI
The main alternative is not a competing SDK but the underlying MCP Apps specification itself. MCP-UI's README states that the `@mcp-ui/*` packages implement that standard, and that the client is recommended for MCP Apps hosts. If you are building a host from scratch, you could implement the MCP Apps spec directly rather than using MCP-UI's renderer. That approach gives you full control over rendering and sandboxing, but it requires you to handle the `_meta.ui.resourceUri` detection, resource fetching, and iframe management yourself. MCP-UI's value is that it packages those steps into `AppRenderer`. For legacy MCP-UI hosts that do not follow the MCP Apps spec, `UIResourceRenderer` serves as a compatibility layer, but the README notes that this is for hosts that embed resources in tool responses, which is an older pattern. The choice is between adopting the standard library versus hand-rolling the same logic.
Maintenance and Upgrade Considerations
The repository shows recent activity with releases up to `client/v7.1.1` in May 2026, indicating active maintenance. The version numbers suggest a mature project that has gone through breaking changes, as v7.0.0 came in March 2026. The README claims full compliance with the MCP Apps specification and production readiness, but you should verify that claim against the spec's current state. The MCP Apps specification is still evolving, as evidenced by the linked `ext-apps` repository, so the SDK may need updates when the spec changes. The dual renderer design (`AppRenderer` for MCP Apps, `UIResourceRenderer` for legacy) means you may need to support both paths if you have mixed hosts. The license is Apache-2.0, which permits commercial use and modification, but you should review the full terms for attribution and patent clauses. The README does not discuss upgrade costs, so you should inspect the changelog between v7.0.0 and v7.1.1 before adopting.
Editorial conclusion
Adopt MCP-UI if you are building an MCP host that needs to render tool-supplied HTML interfaces, or a tool server that wants to provide such UIs, and if you can accept the security burden of sandboxing arbitrary HTML. Do not adopt it if your tools only need plain text output or if your hosts cannot handle the `_meta.ui.resourceUri` link and the `text/html;profile=mcp-app` MIME type. Before committing, verify that your target host supports the MCP Apps specification, confirm the sandbox proxy URL works for your deployment, and audit the SDK's Apache-2.0 license terms against your project's obligations. The repository shows active releases through v7.1.1, but you should check the changelog for breaking changes between minor versions.
Community notes