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!
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👏
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 :)
This is the split I was hoping existed. Tool responses carrying the receipt, while UI-only state stays out of model context, feels like the right boundary.
The open question is whether hosts will treat those receipt fields consistently, or every app has to invent its own convention.
Skybridge
@blah_mad to be honest, some are already inconsistent, and a lot of ink was used on the matter already. If you like some reading, I recommend deep diving the issue of structuredContent vs content vs _meta and SEP-1624 usage across host.
The divergence is quite contained at the moment. But if host don't remain mostly compatible with each other, we'd still be able with Skybridge to remap response fields per host implementation. The advantage of being fullstack is the ability to change response tool payload before it reaches the host backend on invocation without having userland code impacted by this kind of details.
We'll keep app implementor free from the hassle of worrying about this ;)
@fredisterik That remap layer feels like the right pragmatic move. Standards will lag host behavior, so one stable app-side receipt plus Skybridge adapting the host payload is cleaner than making every app learn each host quirk. I’d still want the remap visible enough to debug when a host changes. Is that exposed to app implementors?
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.
Recently released our MCP server at CodSpeed. Didn’t know about Skybridge at the time but will definitely take a look. I used @modelcontextprotocol/server directly.
Why would I gain by switching to Skybridge, what would I lose?
And how difficult the transition would be?
Skybridge
Hey @adriencaccia , great and very legitimate questions! I believe you released an MCP server that doesn't feature apps, so you may not have run into the problems Skybridge is best at solving. If you decide that one of your MCP server's tools should send back an App (meaning an interactive UI) along with its responses, you'll have to build the machinery to make it work (exposing the resource, making sure the configuration is correct, etc.).
Skybridge handles all the heavy lifting here, so you can focus on developing the app itself. We also provide devtools that are really useful for previewing an app and getting it right across all the different possible host parameters : user language, light/dark theme, display settings, and so on. Skybridge also ships with a tunnel that lets you test your local app directly in ChatGPT/Claude, a playground to test it against a real LLM, and an audit check that makes sure your app is properly configured for the stores (which is no trivial thing!).
To migrate, it's easy: just install the Skybridge skill and ask your favorite LLM to do the migration for you. Here's the migration docs with all the details. It works surprisingly well!
And don't hesitate to ping me if anything comes up!
Skybridge
@adriencaccia The transition is almost instant! You can just use our Skill and ask it to migrate to Skybridge
Descope
Congratulations on the launch of Skybridge! How are you handling the identity building blocks involved in this? MCP auth spec, credential storage, etc.?
Skybridge
@abhishekiyer52 we rely on the standard ts mcp sdk for low-level protocol spec, and have built vendor-specific providers to make it super easy to integrate your favorite Idp. Descope is one of them!
Skybridge
@abhishekiyer52 Hey Abhishek, authentication has notoriously been one of the hardest parts of building an MCP app, and making it as smooth as possible is definitely part of the Skybridge mission. So far we'd only been relying on what the official TypeScript SDK provides, but we realized that wasn't enough. Over the last few days we've been working on a handful of carefully crafted branded providers to make setting up authentication almost plug-and-play for Skybridge users. This initiative will go along with a revamp of our docs, with detailed guides for the providers Skybridge supports natively. Of course, an escape hatch and the underlying SDK will still be available, so users with an exotic config can still set up authentication on their MCP server.
I also have to mention that the Descope team has been extremely helpful in integrating it into our collection of branded providers. It's definitely one of the smoothest integration options for our users :)
Descope
Thank you for the replies! It's great to see your team caring about the nitty-gritties of identity and security. These are strong indicators of Skybridge's substance and sustainability. Looking forward to seeing what folks build with this!
Skybridge
@abhishekiyer52 Identity is one of the most important concern and advantage around MCP. With oauth you can create some really nice experience. We are building now example with all major oauth providers
Mailwarm
How do you handle differences between ChatGPT and Claude clients, like UI components that only one supports?
Skybridge
Hey @karimbenkeroum, we constantly monitor the APIs to check what's working on which client. In the Skybridge engine, we detect the runtime at load time and for features only one host supports, the unified API gracefully degrades. That way you don't have to branch on the client yourself you build against one API and Skybridge handles the gaps between them.
Skybridge
@karimbenkeroum that is one of the motivation of Skybridge. Creating abstraction layer on top of openAI and Anthropic APIs, so developers don't have to worry about it. We are working on the same for Vibe from Mistral and Gemini whenever they get the support (or a bridge with A2A if they stick with it)
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 😉