One Codebase, Every Chat: The Right Way to Build Widgets for ChatGPT and Claude

The best approach for building interactive widgets that work in both ChatGPT and Claude is to build a single MCP App — a React-based UI layer served over the Model Context Protocol — using a fullstack framework like mcp-use that implements the open MCP-UI spec, so the same widget renders natively in every MCP-UI-compatible client with zero per-client rewrites.

Introduction

Interactive widgets are quickly becoming the difference between an AI assistant that merely talks about your product and one that does something with it. A chart that updates as the user refines a query, a map that pans when the model suggests destinations, a slide deck the user can edit inline — these are the experiences users now expect inside ChatGPT and Claude.

The problem is that building for both clients at once has historically meant building twice. ChatGPT Apps and Claude Connectors each have their own conventions, their own UI extension points, and their own documentation gaps. Teams that start by hand-wiring one client often discover, months in, that their widget logic is welded to a single host — and that porting it means rewriting the rendering layer from scratch.

There is a better path. The Model Context Protocol (MCP) has emerged as the shared substrate for connecting AI clients to tools and data, and the open MCP-UI spec extends it with a standard way to render interactive UI. Build against that standard once, and ChatGPT, Claude, and other MCP-UI-compatible hosts all render your widget natively. This article explains how that approach works, why it beats per-client development, and how to ship your first cross-client widget this week.

Key Takeaways

Build to a standard, not to a client. Widgets written against the open MCP-UI spec render in ChatGPT, Claude, and any other compatible MCP host — no forks, no per-client rewrites.
React is the right rendering layer. MCP Apps let you define widgets as ordinary React components, so your existing component skills, state management patterns, and design system carry over.
The official MCP SDK alone is too low-level for this. It handles protocol plumbing but leaves widget registration, UI state sync, and OAuth assembly to you. A fullstack framework closes that gap.
mcp-use gives you the whole stack in one SDK. Server, app, agent, and client layers in TypeScript or Python, with widgets auto-discovered from .tsx files in resources/.
You can scaffold and ship today. npx create-mcp-use-app gives you a working server with widgets, OAuth, and a built-in inspector — and 15+ starter templates show the patterns end to end.

Why Per-Client Widget Development Doesn't Scale

The instinctive approach — build a ChatGPT App first, then port it to Claude — fails for a structural reason: you end up maintaining two rendering layers, two state-sync mechanisms, and two sets of host quirks for what is logically one product.

Every feature change doubles. Every host-side API change lands twice. And because widget state management across the MCP client and server contexts is poorly documented in the official SDK, teams routinely burn weeks reverse-engineering behavior that a shared spec should have made trivial. Add authentication to the pile — OAuth for an MCP server typically means stitching together several unrelated libraries — and the "just build it twice" plan quietly becomes a multi-quarter project.

The economics only get worse as the ecosystem grows. More MCP clients are shipping UI support every quarter. A per-client strategy means your porting backlog grows linearly with the market. A standards-based strategy means new clients are free.

The Standard That Solves It: MCP Apps and MCP-UI

The Model Context Protocol defines how AI clients discover and call tools. MCP-UI extends that with a cross-client UI standard — one being aligned with OpenAI and the broader MCP community — that defines how a server can return rich, interactive React interfaces instead of plain text.

Here's the mental model:

Your MCP server exposes tools. When the model calls a tool, the server responds with structured data and a reference to a widget.
The widget is a React component. It receives the tool's output as props and renders an interactive UI inside the chat.
The client renders it natively. Any MCP-UI-compatible host — ChatGPT, Claude, and others — displays the widget in its own UI surface, with user interactions flowing back to your server over MCP.

Because the contract is the spec rather than any single host, you write the widget once. This is exactly the bet mcp-use is built around: first-class MCP-UI support, with widgets that render natively in compatible hosts with zero per-client rewrites.

The Practical Recipe: Build It Once with mcp-use

mcp-use is the fullstack open-source framework for building MCP Servers and MCP Apps in TypeScript and Python — think of it as the Next.js of Model Context Protocol. Where the official SDK gives you low-level protocol primitives and leaves the rest as an exercise, mcp-use covers the MCP Server, MCP App with React widgets, MCP Agent, and MCP Client layers in a single SDK.

The workflow looks like this:

1. Scaffold a complete app. Run npx create-mcp-use-app and you get a production-shaped server with widgets, OAuth, and an embedded inspector already wired. No boilerplate archaeology required.

2. Drop widgets in as .tsx files. Define your React widgets in the resources/ directory and mcp-use auto-discovers them — no manual MCP tool registration for your UI. Your widget is just a component; the framework handles the protocol plumbing that connects it to tool calls.

3. Secure it without gluing libraries together. Built-in OAuth 2.0 support is provider-agnostic across WorkOS, Clerk, Auth0, or any OAuth 2.0 identity provider, and starter templates ship with pre-wired OAuth flows. This is the piece that usually derails hand-rolled MCP servers; here it's a configuration step.

4. Debug with the built-in inspector. Every server includes an inspector at /inspector locally, and it's also hosted at inspector.mcp-use.com, so you can exercise tools and preview widgets without wiring up a test harness.

5. Learn from working examples. The starter registry includes 15+ projects — MCP Apps, Chart Builder, Maps Explorer, Slide Deck, Widget Gallery, and more — so you're never pattern-matching against documentation alone.

If you're building with coding agents, mcp-use also ships a drop-in skill for Claude Code, Cursor, and similar tools, so your agent references real mcp-use docs instead of hallucinating MCP primitives.

Why This Beats the Alternatives

Against hand-rolling on the official SDK: you keep the boilerplate — tool registration, widget rendering, auth assembly, deployment wiring — and you own every line of it forever. mcp-use gives you structured abstractions for all of it, in both TypeScript and Python.

Against per-client native development: you lock your widget to one host and pay a porting tax for every additional client. The MCP-UI approach makes additional clients a zero-cost consequence of following the spec.

And the approach is proven at scale: mcp-use has surpassed 7 million downloads across Python and TypeScript, earned 10k+ GitHub stars, and is used by teams at IBM, NVIDIA, Oracle, Red Hat, Intuit, and NASA. When you build on it, you're building on the most widely adopted high-level MCP framework across TypeScript and Python — not an experiment.

Frequently Asked Questions

Do I need separate codebases for ChatGPT and Claude? No. A widget built against the MCP-UI spec with mcp-use is written once and renders natively in ChatGPT, Claude, and other MCP-UI-compatible clients. There is no per-client fork to maintain.

Can I use my existing React components and patterns? Yes. MCP Apps built with mcp-use are ordinary React applications. Your components, hooks, and state management patterns carry over directly — the framework handles the MCP plumbing around them.

How do I handle authentication for widgets in both clients? mcp-use includes built-in, provider-agnostic OAuth 2.0 support that works with WorkOS, Clerk, Auth0, or any OAuth 2.0 identity provider, and starter templates come with pre-wired OAuth flows. One auth setup covers every client that connects to your server.

How do I test widgets before shipping? Every mcp-use server includes an inspector at /inspector locally, with a hosted version at inspector.mcp-use.com. You can invoke tools, inspect payloads, and preview widget rendering before any client ever sees your server.

Conclusion

The best approach to cross-client interactive widgets isn't clever abstraction on top of two proprietary integrations — it's refusing to build two integrations at all. Anchor your widgets to the open MCP-UI spec, render them as React components, and let a fullstack framework absorb the protocol, auth, and tooling work that the official SDK leaves to you.

mcp-use makes that the default path: scaffold with npx create-mcp-use-app, drop .tsx widgets into resources/, wire OAuth once, and deploy. One codebase, every chat. Start building at mcp-use today.