Launching today
MCP apps are the new website: they're real, interactive apps that run right inside AI assistants like ChatGPT and Claude. The tooling to build them didn't exist, so we built it. Meet Skybridge, the React framework that handles the infrastructure and the dev loop so you can focus on your features: MCP server, view rendering, client compatibility, testing tunnel, and more. Code once, ship everywhere. Already +500K downloads and dozens of apps in the stores!
Skybridge
👋 Hey Product Hunt!
The internet is going headless. More and more, people don't open a website or an app, they just ask an assistant. That's making MCP Apps the new UI: real, interactive apps that run right inside Claude, ChatGPT and the rest. We think it's one of the biggest shifts in how software gets built and used right now.
While building these apps at Alpic, we kept hitting the same wall: every host (Claude, ChatGPT, Cursor…) has its own quirks, and writing the plumbing to support all of them is painful. So we built Skybridge. It is an open-source framework to build MCP apps, from idea to the official app stores. Code once, ship everywhere.
It abstracts away the implementation differences, so your app runs the same in Claude, ChatGPT, VS Code and any MCP-compatible client. It bundles a full local emulator, Hot Module Reload and an instant tunnel to connect your local app to Claude and ChatGPT. Agents are first-class users too: Skybridge gives your coding agent everything it needs to build an MCP app end-to-end.
Want proof the hard parts work? Have a look at our showcase page. You'll find many of the apps the community and us made with Skybridge and published to the stores. Skybridge already powers dozens of apps live in the stores.
What's happening in the MCP world right now is wild, and we can't wait to see what you build with it 💫
Huge👏 congrats @julienvallini on the release, the headless web framing is spot on. love it's a open source, qq. do we have to deploy to alpic cloud to get the store auditing features or can we run the full beacon compliance scan locally via the cli?
Skybridge
Hey @priya_kushwaha1, thanks for the support! :)
Your MCP server doesn't need to be hosted on Alpic to run the compliance check. Any public MCP server can be audited, wherever it's hosted.
If you want to give it a try : https://beacon.alpic.ai/
Thanks, Perfect appreciate the answer👏
One challenge I've seen with MCP apps is maintaining a consistent UX across different hosts. How much control does Skybridge give developers over host-specific behavior when they actually want to customize the experience?
Skybridge
Hey @yagnaveena , thanks for your question. Skybridge provides low-level API access to host-specific implementations in order to still be able to customize app based on a specific host. You can for exemple use both useAppsSdkContext and useMcpAppContext to customize your app based on host protocol.
@fredisterik Thanks for the clarification! Makes sense to expose host-specific context rather than forcing a lowest-common-denominator abstraction.
Skybridge
👋 Hey Product Hunt! I'm Fred, co-founder and CTO of Alpic, and core maintainer of Skybridge!
When ChatGPT Apps launched in October 2025, the OpenAI Apps SDK was just a page of documentation. No runtime, no tooling, nothing. So we built the missing SDK ourselves. That was Skybridge, day one.
But the deeper frustration was the feedback loop. Hot Module Reload, instant iteration, host context mocking (like locale, theme, or screen size), things web developers have taken for granted for a decade, mostly natively supported in modern browsers, simply didn't exist for AI Apps. Every change meant a full restart, a metadata refresh, and manually reconnecting to your conversational agent. The stack was brittle at best. When your feedback loop takes ages, you stop experimenting. You stop building.
So the DevTools became a core pillar of Skybridge: a local-only environment where you can iterate freely on your app before ever connecting it to Claude or ChatGPT. Tight loop, no friction.
Fully open-source. Because foundational tooling for this new layer of the web should be built in the open.
Since then, we've seen the number of apps built with Skybridge skyrocket! We've made the DevTools both human- and agent-friendly, enabling development loops we couldn't have even dreamed of 6 months ago. Can't wait to see what experiences people will bring to life with Skybridge.
If you want to give it a go yourself, check out our getting started guide!
Easop 2.0
@fredisterik Product looks really well made for developers! I can't wait to test it 💪
Skybridge
Thanks @thierreasop , feel free to share your thoughts after trying it out! Always on the lookout for ideas on how to help make Skybridge a better tool to build app with!
Congrats on the launch. The “MCP apps as the new UI” framing feels right.
The thing I’d want standardized early is the action boundary: when an app moves from rendering UI to taking an external action, does Skybridge expose a receipt/approval surface back to the host, or is that left to each app?
Skybridge
Hey @blah_mad, really appreciate it!
Today the action boundary is left to each app rather than standardized by the framework. Skybridge gives you MCP tool annotations that hint side effects to the host/model but enforce nothing. We provide a hook useRequestModal() to drive host-native confirmation surfaces from the UI though.
Skybridge
Hey @blah_mad , thanks for your question.
Standard way to provide action to an MCP app, wether it's directly invoked by the underlying model as part of the conversation, or through UI action taken by the user, is tool exposed by the MCP server (the "backend" of the MCP app). Each tool call response is entirely customizable using Skybridge, so you can put anything you want in the receipt/approval sent back to the host.
You can also use Skybridge to split between what's shared with the model as part of this response, and what's only shared with your UI views in order for you to update the state and reflect the action result to the user, without injecting anything in the conversational agent context. This gives you the added benefit of asymmetric information, and can be leveraged to build games for exemple, where UI and model don't share the same knowledge :)
Congrats on the launch. Curious when Claude supports a capability that ChatGPT doesn't, how does Skybridge handle graceful degradation across hosts?
Skybridge
Hey @crystalmei , thanks for your question.
We implemented per-host implementation of each API exposed in Skybridge to build functionalities. Host that lacks specific features (like Claude missing the view state storage across conversation rendering) are shimmed with the best possible alternative (in this exemple, browser local storage API) to make it easy for developers.
When a feature can't be shimmed to enable similar functionality, the docs mentions it 😉
The local emulator with hot reload is the part that stands out to me, the rebuild and reconnect loop for MCP apps has been rough. Does the tunnel handle auth flows when testing against Claude, or is that still manual? Congrats on shipping.
Skybridge
Hi @i_sanjay_gautam, thanks! Glad the hot-reload loop hits home, that was exactly the pain we set out to kill. On auth, Skybridge does most of the work: it auto-adapts the OAuth metadata to the public URL (the server infers the resource origin from forwarded headers), and discovery + JWKS verification are automatic, so testing against Claude just works. The only manual bit is registering the tunnel URL as a connector and enabling DCR in your IdP. Happy to share the exact setup if useful!