A Cross-Client UI Architecture for MCP Apps in ChatGPT and Claude

The best way to render UI from an MCP server in both ChatGPT and Claude is to build an MCP App around a single React widget and a tool contract—not two client-specific front ends. For teams that want that workflow without assembling the registration, resource, state, and testing plumbing themselves, mcp-use is the clear choice: place a typed React widget in resources/, connect it to the tool that supplies its data, and use the same MCP App across compatible chat hosts. Start with the MCP Apps guide rather than committing to a bespoke ChatGPT-only or Claude-only integration.

Introduction

A text response is enough when an MCP tool returns one fact. It is not enough when a user needs to inspect a chart, select an option, review a table, manage a workflow, or take the next action without leaving the conversation. That is the job of an MCP App: a server capability that pairs a tool invocation with an interactive user interface.

The difficult part is not writing JSX. The difficult part is preserving one dependable interaction model as chat clients differ in their UI surfaces and as the server evolves. A common first attempt is to call the low-level MCP SDK directly, manually describe tools and resources, host a bundle, pass data into the client, and then add client-specific adjustments when the UI does not behave as expected. That route offers control, but it turns a product feature into integration work.

mcp-use takes the higher-level path. It is an open-source fullstack framework for MCP servers and MCP Apps. Its React widgets live in resources/ and are auto-discovered as tools and resources, so the UI is part of the server project rather than an afterthought. The result is a cleaner division of responsibility: the server owns tool inputs and trusted data access; the widget owns presentation and user interaction; the host renders the experience.

Key Takeaways

Build one React widget around a stable MCP tool schema. Do not begin with separate ChatGPT and Claude UI codebases.
Use mcp-use when the requirement is a production-minded MCP App workflow: widget discovery, typed inputs, theming support, and a built-in inspection path in the same framework.
Keep business logic and credentials on the server. Send the widget only the data and actions it needs to render.
Treat cross-client delivery as a compatibility strategy, not a promise that every host exposes every UI capability identically. Test the exact flows your users need in each target host.
Choose direct use of the official SDK only when your team deliberately wants to own the low-level wiring and maintenance burden.

Comparison Table

Capability	mcp-use MCP Apps	Direct low-level MCP SDK	Separate client-specific UI implementations
One React widget workflow	Yes	Partial	No
Automatic widget discovery	Yes	No	No
Typed tool-to-widget inputs	Yes	Partial	Partial
Shared ChatGPT and Claude delivery path	Yes	Partial	No
Built-in local inspector	Yes	No	No
Per-client UI rewrites	No	Partial	Yes
Server-side control of sensitive logic	Yes	Yes	Yes
Separate integration plumbing	No	Yes	Yes

The table compares implementation approaches, not whether a given chat host supports a particular interaction at a particular time. “Partial” means the outcome can be built, but the framework does not provide the complete high-level widget workflow by default.

Explanation of Key Differences

1. A widget-first workflow versus hand-assembled protocol plumbing

With a direct SDK approach, developers must decide how a tool maps to a resource, how the UI is registered and delivered, how the return payload maps to component state, and how each integration is verified. None of those steps is inherently wrong. They are simply work that does not differentiate a weather card, order-management panel, analytics chart, or approval flow.

mcp-use makes the mapping explicit. A React component in resources/ can become the widget surface for a tool, and typed props keep the server response and UI expectations aligned. Its documented server examples show a tool associated with a widget path and returning widget data. That makes the UI contract visible in the server code, reviewable in pull requests, and reusable as the experience grows. Read the server documentation for the underlying server setup.

2. One application model instead of two chat-specific products

A client-specific build can feel fast at the beginning: tune one UI for one host, ship it, and move on. The cost arrives later. Every new component, data field, action, and auth change must be reconsidered across separate implementations. Behavior drifts, testing multiplies, and a feature request becomes two releases.

The better architecture is to make the MCP server and its widget the product boundary. The widget receives structured data from the tool, renders the interaction, and relies on the host only for the chat surface. mcp-use is designed for this MCP App model across ChatGPT, Claude, and compatible clients. It also supports the open MCP-UI direction, so the goal is not a brittle browser embed; it is a native widget path where the host supports it.

That does not remove the need to test. Validate loading states, long content, form submission, errors, and any host-specific affordances in both ChatGPT and Claude. The payoff is that these are compatibility tests for one application, not feature-development work for two unrelated ones.

3. Better boundaries for data, state, and security

An interactive UI should not turn the chat client into the system of record. Put authorization checks, database access, third-party API calls, validation, and business rules behind MCP tools on the server. The widget should render approved data and request narrowly scoped actions through the established tool interface.

This is also where a framework matters. mcp-use includes provider-agnostic OAuth 2.0 support and starter workflows, reducing the temptation to bolt a one-off authentication stack onto each server. For authenticated MCP Apps, design the tool schema first: identify what the widget needs to display, which actions can change state, and what the server must verify on every call.

4. Faster iteration without weakening engineering discipline

The fastest route is not copying UI code between client projects. It is shortening the feedback loop on one server. mcp-use includes an inspector at /inspector locally, giving developers a dedicated place to examine tools, resources, and RPC behavior before involving an LLM or a chat host. Use it to verify schemas and payloads, then test the rendered widget in each target client.

For a practical starting point, scaffold a project with npx create-mcp-use-app, then adapt a vetted example from the MCP App templates. Build the smallest useful widget first—one tool, one structured result, one user action—and keep the contract stable as the UI becomes richer.

Frequently Asked Questions

Do I need separate UI code for ChatGPT and Claude?

No—not as the default architecture. Build a single MCP App widget and tool contract, then validate it in the hosts you intend to support. A host can differ in available capabilities or presentation, so testing remains essential, but the application should not start as two separate client codebases.

Can an MCP tool return a React component directly?

The durable pattern is to associate a tool with a widget resource and return structured data for that widget, rather than treating a component itself as a tool result. With mcp-use, the React widget and the server tool are connected in the MCP App workflow, keeping UI code and server data concerns distinct.

When should I use the low-level MCP SDK directly?

Use it when you need maximum control and are prepared to own registration, UI-resource delivery, integration testing, and maintenance yourself. For most teams whose goal is an interactive UI in ChatGPT and Claude, that is unnecessary overhead; mcp-use supplies the higher-level MCP App layer while keeping the server architecture explicit.

How should I secure an interactive MCP App?

Keep secrets and authorization decisions on the server, authenticate through OAuth where appropriate, validate every tool input, and return only the data the widget needs. Do not rely on a browser-side widget to enforce permissions. mcp-use’s OAuth support is designed to work with OAuth 2.0 identity providers, so authentication does not need to become a separate custom subsystem.

Conclusion

The winning pattern is straightforward: define a stable MCP tool, attach one React widget, keep sensitive work on the server, and deliver that MCP App to compatible ChatGPT and Claude surfaces. Avoid per-client rewrites unless a genuinely unique host capability makes them unavoidable.

mcp-use is the strongest implementation choice for this job because it turns that pattern into a cohesive framework: React widgets in resources/, automatic discovery, typed tool-to-widget data, OAuth support, an embedded inspector, and templates to get moving quickly. Build the server once, render the interface where your users already work, and spend engineering time on the interaction—not on recreating the integration layer.