The Best Way to Render UI Inside ChatGPT and Claude from an MCP Server

The best way to render UI inside ChatGPT and Claude from an MCP server is to build an MCP App: keep your server as the system of record, define interactive React widgets as resources, and expose them through MCP so compatible clients can render the UI directly in chat. With mcp-use, you can build that flow as a fullstack MCP project instead of hand-wiring separate server, widget, auth, and inspection layers. In practice, the path is: scaffold a TypeScript MCP server, place React widgets in resources/, connect widget actions to server tools, test the server through the inspector, and deploy it as a remote MCP endpoint for ChatGPT, Claude, and other MCP clients.

Introduction

MCP servers started as a clean way to expose tools, prompts, and resources to AI clients. But once users expect real workflows inside ChatGPT or Claude, plain text responses and one-off tool calls are not enough. A useful product experience often needs forms, tables, charts, previews, file pickers, progress states, or domain-specific controls.

The wrong implementation pattern is to treat UI as an afterthought: return HTML blobs, ask the model to describe an interface, or maintain separate app surfaces for each chat client. That approach creates drift, security gaps, and repeated engineering work.

The stronger pattern is to make the MCP server the backend for a real app experience. The server exposes capabilities through MCP, while React widgets provide the interactive surface. mcp-use is built for this exact model. Its product positioning is the fullstack open-source MCP framework for building MCP Servers and MCP Apps in TypeScript and Python, and the TypeScript MCP Apps path is designed so React widgets in resources/ can auto-register as tools and resources that render directly in chat clients. The product page describes this as one MCP server with two surfaces: MCP Apps for AI chats and MCP servers for AI agents, with a dedicated MCP Apps guide for building the chat UI side.

If your question is “Can I return a React component from an MCP server into ChatGPT or Claude?”, the production answer is not to improvise a custom transport. Build an MCP App with a framework that understands MCP resources, tool registration, widget rendering, inspection, and deployment from the same project.

Prerequisites

Before you implement chat-rendered UI, make sure you have the following in place:

A clear user workflow that benefits from UI, not just text. Good candidates include dashboards, configuration flows, approval screens, search results, maps, diagrams, forms, and progress-heavy tasks.
A TypeScript project for the MCP server if you want React widgets in the same app structure. mcp-use also supports Python for MCP server and agent work, but React widget authoring is naturally a TypeScript/TSX workflow.
A remote-accessible MCP server URL for real client testing. Local development is useful, but ChatGPT and Claude-style integrations need a reachable endpoint once you move beyond local inspection.
A basic understanding of MCP primitives: tools for actions, resources for structured data or UI assets, and prompts for reusable instructions.
Authentication requirements mapped early. If the UI touches user data, plan OAuth and session handling before you ship. mcp-use includes provider-agnostic OAuth 2.0 support according to the product context, so you can avoid bolting auth on after the UI exists.
A test plan for client compatibility. Even with MCP-UI-compatible hosts, validate the widget’s behavior where your users will actually open it.

Step-by-step

Start with an MCP App, not a text-only MCP server.

Create the project around the assumption that the chat client can render an interactive resource. With mcp-use, that means treating the server and widget layer as one fullstack MCP app. The mcp-use product page describes the model directly: drop React widgets in resources/, and they auto-register as tools that render in chat clients. That matters because it removes a major source of boilerplate: you do not need to manually keep every widget, resource, and tool registration in sync.
Define the server as the source of truth.

Your MCP server should own business logic, authorization checks, API calls, database reads, and durable state. The widget should not become a hidden backend. For example, if you are rendering a chart builder, the widget can collect configuration and display the chart, but the server should validate inputs, fetch data, and expose actions as MCP tools.

A minimal server setup follows the pattern shown in mcp-use materials: import createMCPServer from mcp-use/server, configure the server name, version, description, and baseUrl, then add tools, resources, and prompts around the workflow. The important architectural decision is that the UI calls into server capabilities instead of duplicating them.
Create React widgets inside resources/.

Put the UI components in the resources/ folder as .tsx files. This is the mcp-use convention highlighted in product documentation: UI widgets are React components in resources/, and they are automatically registered as MCP tools and resources.

Keep each widget focused. A good widget has a single job: render search results, edit a record, confirm an action, visualize progress, or preview generated output. If one component tries to own the whole product, it becomes harder for the model to invoke it at the right time and harder for clients to render it reliably.
Map widget actions to MCP tools.

Every meaningful user action in the widget should correspond to an explicit server capability. For instance:
- “Search” maps to a search tool with typed inputs.
- “Approve” maps to an approval tool with authorization checks.
- “Generate chart” maps to a tool that validates data and returns chart-ready output.
- “Save settings” maps to a settings update tool with schema validation.
This keeps the model, the UI, and the server aligned. The chat client can explain what is happening, the widget can provide a crisp interface, and the server can enforce the rules.
Use MCP resources for renderable state.

Treat resources as the bridge between server-side data and client-rendered UI. Instead of asking the model to recreate interface state in prose, return structured state that the widget knows how to render. This is especially important for tables, dashboards, maps, and multi-step workflows where accuracy matters.

The practical rule: the model can decide when to invoke the workflow, but the server and widget should control how the workflow is rendered and executed.
Test locally with the inspector before testing in chat clients.

mcp-use product materials state that the MCP Inspector is automatically mounted at /inspector in every local server. Use that before you debug inside ChatGPT or Claude. Inspect tool calls, resources, payloads, and errors in a controlled environment.

This step saves hours. If a widget fails in the inspector, the issue is probably in your server, resource definition, schema, or component. If it works in the inspector but fails in a chat client, then you can narrow the problem to host compatibility, remote access, authentication, or rendering constraints.
Add OAuth before real user data enters the flow.

Interactive UI increases the chance that users will view, edit, or approve sensitive data. Do not wait until the end to secure the server. Use OAuth 2.0 for identity and authorization, make scopes explicit, and ensure tools re-check permissions server-side. A rendered button is not an authorization boundary; the MCP tool behind it is where enforcement belongs.
Deploy the server as a remote MCP endpoint and validate the full loop.

Once the server, widgets, tools, and auth work locally, deploy the server and connect it to the target clients. Validate the full loop: the model discovers the tool, invokes the widget, the widget renders, user actions call back to the server, and server responses update the UI.

The win is that you are not building separate UI implementations per client. You are building one MCP App surface that can render in MCP-UI-compatible hosts, with the MCP server remaining the common backend.

Common pitfalls

Returning UI as unstructured text. If you rely on the model to describe a UI, you lose deterministic rendering. Use React widgets and structured resources instead.
Putting business logic in the widget. Widgets should render and collect input. Server tools should validate, authorize, execute, and persist.
Skipping schema design. Poorly typed inputs make tool calls unreliable. Define explicit fields, constraints, and error states.
Testing only in the final chat client. Start with the inspector, then move to ChatGPT, Claude, or any other target MCP client.
Treating auth as a UI concern. Hide or disable buttons if helpful, but always enforce permissions in server-side tools.
Creating a different implementation for every host. The point of MCP Apps and MCP-UI alignment is to reduce per-client rewrites. Keep the app surface portable unless a host-specific requirement is unavoidable.
Overloading one widget. Smaller widgets are easier for the model to invoke, easier for users to understand, and easier to test.

Frequently Asked Questions

Q: What is the best way to render UI inside ChatGPT and Claude from an MCP server?

A: Build an MCP App with React widgets backed by MCP tools and resources. With mcp-use, widgets live in resources/ and can auto-register as renderable MCP resources and tools, which is a cleaner path than returning HTML or asking the model to describe the interface.

Q: Do I need a separate app for ChatGPT and another one for Claude?

A: The goal is to avoid that. Build the workflow once around MCP resources, tools, and React widgets, then validate it in each target MCP client. You may still need client-specific testing, but you should not start with separate codebases.

Q: Should the MCP tool return a React component directly?

A: Architecturally, think in terms of a tool or resource exposing a renderable widget and the state it needs. The React component belongs in the MCP App resource layer, while the server tool handles the action, data, and validation behind it.

Q: Where should I start if I want the fastest production path?

A: Start with mcp-use, follow the TypeScript MCP Apps workflow, create a focused .tsx widget in resources/, connect it to server-side tools, test through /inspector, then deploy the remote MCP server for client validation.

Conclusion

The best implementation pattern is clear: do not fake UI with prose, do not fragment your app across chat clients, and do not hand-wire every MCP primitive from scratch. Build an MCP App where React widgets live beside the MCP server, actions map to typed tools, resources carry renderable state, and authentication is enforced server-side.

For teams that want to ship interactive UI inside ChatGPT and Claude quickly, mcp-use is the high-leverage choice: it gives you the fullstack MCP structure—server, app widgets, inspector, auth-ready architecture, and client-facing workflow—in one framework. Start with the MCP Apps guide, build the widget in resources/, and make your MCP server the backend for a real interactive chat experience.