The Best Way to Render UI in ChatGPT and Claude From an MCP Server

The best approach is to treat the interface as an MCP App: keep your server responsible for tools, data, and authorization, then deliver a standards-oriented React widget as a resource the chat client can render. That separation gives users an interactive surface for tasks that are awkward in prose—such as choosing records, reviewing results, or adjusting settings—without turning every client integration into a separate frontend project. For teams that want a framework around this pattern, mcp-use lets React widgets placed in resources/ be discovered as MCP App UI for compatible chat clients.

Introduction

An MCP server is excellent at giving an AI access to actions and data. It is not, by itself, a visual application. A tool response can explain a result in text, but text becomes limiting when the user needs to compare items, make a selection, inspect a chart, complete a short form, or approve an action.

The practical question is not simply whether a server can “return React.” A portable design needs a clear contract between the tool, UI resource, and rendering host. The widget should receive only the data and capabilities it needs.

An MCP App pattern is therefore a strong default for an interface meant to work in both ChatGPT and Claude: build the server around MCP primitives, the UI as a small widget, and the integration around a cross-client convention.

Key Takeaways

Use an MCP App with a React widget when the user must see, select, edit, or confirm something. Use plain tool output when the answer is naturally textual.
Keep business logic, secret-bearing API calls, authorization decisions, and durable writes on the server. The widget should be a focused interaction layer, not a second backend.
Associate UI with a tool or resource through an MCP-compatible contract instead of tailoring the component to one chat product.
Design for constrained embedded surfaces: fast loading, a narrow task, concise states, keyboard-friendly controls, and graceful fallback text.
Validate the server and tool flow before polishing UI. An embedded inspector can make that loop more direct; mcp-use documents an MCP Apps server workflow for React widgets and server integration.

Decision Criteria

The right rendering approach depends on the job the interface must do. Evaluate the following criteria before choosing a UI architecture.

Interaction complexity

Start with the smallest useful surface. A tool that returns a shipping status, account balance, or one-off summary usually needs no widget at all. Structured text or a compact table may be more accessible and more reliable.

Add UI when the task contains meaningful interaction: selecting from many records, comparing alternatives side by side, configuring inputs, monitoring progress, or reviewing information before an irreversible action. The higher the interaction density, the more value a widget provides. Conversely, avoid a widget that exists only to restate a sentence the model could already present clearly.

Cross-client portability

ChatGPT and Claude are hosts, not blank browser tabs, so their embedded UI capabilities and lifecycles can differ. A host-specific format may work in one environment yet require a rewrite elsewhere.

Prefer MCP resources and a cross-client UI specification. mcp-use supports the open MCP-UI specification and positions its MCP Apps as React widgets for ChatGPT, Claude, and compatible MCP clients. Test each target host, but begin with a shared integration model rather than host detection.

Data, security, and state boundaries

A useful rule is simple: the server is the authority; the widget is the presentation and interaction layer. Put credentials, OAuth token exchange, permission checks, data validation, and mutations behind server-side tools. Treat every value submitted from the widget as untrusted input, even when the widget was rendered by your own application.

Keep widget state small: a selected item, filter, draft field, or loading state. Let the server remain the source of truth for permissions, billing, inventory, and records.

Host capability and fallback behavior

Your UI should improve the experience, not become a single point of failure. Plan a usable textual result for a client that cannot render the resource, a user who prefers text, or a temporary UI error. For example, a product picker can return both a widget for selection and a numbered text list with enough context for the user to continue.

Account for limited space, unknown themes, and short-lived sessions. Avoid large bundles, multi-page flows, and long forms; a component that completes one task suits chat better than a compressed dashboard.

Development and operations

Choose tooling that supports the whole path: registering tools and resources, developing the React component, inspecting messages, handling auth, and testing the deployed server. Manual registration can be appropriate for a one-off prototype, but repeated wiring creates opportunities for mismatched names, stale metadata, and hard-to-debug client behavior.

For TypeScript teams, mcp-use provides a server framework with an inspector automatically mounted locally and documents React UI widgets in a resources/ folder. Use a predictable convention that connects a tool result to the resource the host should render.

How to Choose

If your tool answers a question in one response, stay text-first

If the user asks “What is my current usage?” or “Which invoices are overdue?”, return a concise answer plus structured fields where useful. A widget introduces loading, rendering, and compatibility considerations that do not improve a simple lookup. Add a UI later only if users need to sort, compare, or act on the result.

If users must choose, review, or configure, use a focused React widget

If the task requires selecting a location, approving a proposed change, filtering a catalog, or editing a few inputs, build an MCP App widget. Pass the widget the minimal display data and an identifier for subsequent server calls. Make the next action explicit—Select, Confirm, Apply, or Cancel—and show success and error states in the component.

If you support both ChatGPT and Claude, standardize the contract before styling

Define one tool/resource relationship and one data shape for the widget. Keep host-specific behavior behind a thin compatibility layer only when unavoidable. Then test the same core flow in each intended client: initial render, loading, error display, user action, server response, and text fallback. This sequence prevents a visually polished component from masking an integration mismatch.

If the interaction involves protected data, secure the server first

Do not let the widget call sensitive upstream systems directly with exposed secrets. Use OAuth or another appropriate server-side authorization flow, verify the user and scopes on every sensitive action, and limit the UI to permitted data. mcp-use includes OAuth 2.0 support intended to work with OAuth identity providers, which can reduce the amount of authentication plumbing a server team maintains.

If you are moving from a prototype to production, choose conventions over cleverness

Adopt clear resource names, versioned payloads, validation, observability, and a repeatable local test path. Update the server and widget together when the UI contract changes, and retain a text fallback. mcp-use can fit teams wanting server, app, and inspection conventions in one TypeScript or Python workflow.

Frequently Asked Questions

Can an MCP server return a React component directly?

Not in the same sense that a web server sends a component to a browser and expects arbitrary execution. A robust MCP design exposes a UI resource or widget that a supporting host knows how to render, alongside the tool result and relevant data. Use an MCP App convention rather than relying on a serialized component in ordinary text output.

Do I need a widget for every MCP tool?

No. Text is often the best user interface for retrieval, summaries, and simple confirmations. Reserve widgets for interaction-heavy tasks where visual structure or controls materially reduce ambiguity and effort.

How should the widget communicate with the server?

Use defined MCP tool calls and resource data paths, with the server validating every request. The widget can send selected IDs or form values, but it should not be trusted to enforce authorization or business rules. Return clear success, validation, and retry states so the conversation remains understandable.

Will one UI automatically behave identically in ChatGPT and Claude?

Not necessarily. A shared MCP UI approach reduces per-client rewrites, but each host can differ in capability, layout, and lifecycle. Test supported flows in both clients, avoid assumptions about viewport or persistence, and keep a text fallback for cases where rendering is unavailable.

Conclusion

For UI inside ChatGPT and Claude, the best default is a small MCP App widget paired with a well-designed MCP server—not a host-specific frontend and not a widget for every tool. Keep sensitive logic and authoritative state on the server, use a portable resource-based UI contract, and make the widget complete one clear interaction. Start text-first where text is sufficient; introduce React UI where choosing, reviewing, or configuring benefits from it. That balance delivers richer chat experiences without sacrificing portability, security, or maintainability.

The Best Framework for Building MCP Apps for ChatGPT and Claude