Skybridge: a TypeScript framework for building MCP Apps and ChatGPT Apps

What Skybridge actually solves for MCP server authors

The Model Context Protocol gives you tools and resources. It does not give you a UI. MCP Apps extend the protocol with interactive views rendered from the server, and the README is explicit that the raw SDKs are low-level: "no hooks, type safety, HMR, etc." Skybridge is the layer that fills that gap. It targets developers who have an MCP server and now want a rendered interface inside Claude, ChatGPT, VS Code, or another client that supports MCP Apps. The framework's pitch is that the client differences are abstracted, so a view written once runs in each of them. The secondary audience is unusual and worth naming: coding agents. The README describes the project as "agent-ready", with a skill, a CLI and programmatic dev tool APIs, and it ships AGENTS.md and CLAUDE.md at the repository root. That is a deliberate bet that a meaningful share of MCP apps will be scaffolded by an agent rather than typed by hand.

Server, model and UI: the data flow Skybridge wires together

The architecture is a monorepo of packages rather than a single library. The root package.json defines workspace overrides for skybridge, @skybridge/vite-plugin, @skybridge/devtools and @skybridge/test, so the runtime, the build integration, the local dev server and a test package are separate installable units. The type safety is described as tRPC-style inference: you define a tool on the MCP server, and the React view infers the types of that tool's input and output, so the boundary between server and frontend is checked at compile time. On the client side the README promises React Query-style hooks for state management. The docs point to a fundamentals page covering what it calls server, model and UI data flows plus LLM context sync, which is the part that matters when the model needs to know what the user did in the view. The dev server adds a local emulator, hot module reload, and a tunnel that connects a local app to Claude and ChatGPT. That tunnel is the piece most frameworks leave to you.

Installing Skybridge and getting a first app running

The README gives two entry points, one for humans and one for agents. For a new project, bootstrap with the create command. It is interactive, so run it in a directory where you are happy to have a new folder appear.

npm create skybridge@latest my-app

After the scaffold finishes you have a working MCP app with a server and at least one view. The README points to the Quickstart guide at docs.skybridge.tech/get-started/quickstart for the full instructions, and the repository ships a large examples directory if you would rather read working code than a guide.

If you are driving this from a coding agent instead, the README documents a skill install. The command below adds the Skybridge skill, and the README says to ask your agent "What skills do you have?" afterwards to confirm it landed.

npx skills add alpic-ai/skybridge -s skybridge

With the skill installed the README suggests prompts such as "Create a new MCP app", "Migrate my MCP server to the Skybridge framework" and "Add a new view to my MCP app". The migration path is the one to note: if you already have an MCP server, the skill is the documented route for converting it rather than starting over.

Where Skybridge gets in your way

The framework is opinionated about React. If your MCP server serves a Python backend, a Go service, or a frontend that is not React, the type-safe inference from tool definition to view does not apply to you, and you would be adopting a build system for a language you are not writing. That is a real boundary, not a small one. The second constraint is version churn. The release history shows v1.4.0 in August 2026, v1.4.1 later that month, and v2.0.0 on 2026-09-04, a major bump roughly three weeks after the previous minor. A major version inside a few weeks of the prior release means migration work for anyone who adopted earlier. The README does not document a rollback path or a compatibility policy between majors. Third, platform abstraction has a cost: when Claude or ChatGPT changes how it renders a view, you are waiting on a framework release rather than adapting your own code. The README lists the supported clients but does not describe what happens when a client ships a feature the abstraction does not yet expose. If your app depends on a client-specific capability, check whether the abstraction surfaces it before you commit.

Skybridge compared with writing directly against the MCP SDKs

The honest alternative is the raw Model Context Protocol SDK plus whatever UI mechanism the target client provides. That approach gives you the protocol surface exactly as specified, no intermediate layer, and no dependency on a framework's release cadence. It also means writing the client-difference handling yourself, wiring your own hot reload, and building your own tunnel for local testing against Claude and ChatGPT. Skybridge's README frames the trade directly: the raw SDKs are low-level, and the framework exists to add hooks, type safety and HMR. So the choice is between a dependency that owns the boring parts and direct control over the protocol. For a single-client app with a small view, direct SDK use is defensible. For an app that must run in several clients and has a nontrivial React interface, the abstraction is doing work you would otherwise repeat per client. The examples directory, which includes auth integrations for Auth0, Clerk, Stytch, WorkOS, AuthPlane and Descope, plus apps for flight booking, ecommerce and generative UI, is the fastest way to judge which side of that line your project falls on.

Licence, maintenance and what an upgrade costs

The repository is MIT licensed, and the README carries an MIT badge. MIT is permissive: you can use it commercially, modify it and redistribute it, provided the copyright notice and permission notice are preserved. That is the general shape of the licence and not legal advice; read LICENSE in the repository for the binding text. Note one wrinkle: the root package.json declares "license": "ISC" for the monorepo package itself, while the project and its LICENSE file are MIT. For a consumer of the published skybridge package this is unlikely to matter, but if you vendor the monorepo, the discrepancy is worth resolving with the maintainers rather than assuming. On maintenance: the last push was on 2026-09-10, and the repository is not archived. The commit history is not visible here, so treat the push date as the only signal available. The upgrade cost is the thing to budget for. With v2.0.0 landing on 2026-09-04 after v1.4.1 on 2026-08-24, a project started on 1.x will need a migration pass. The repository has a CONTRIBUTING.md and a SECURITY.md, and renovate.json plus a bump script in scripts/, which suggests dependency updates are automated on the maintainer side.

Editorial conclusion

Adopt Skybridge if you already ship an MCP server and want React views in Claude or ChatGPT without hand-writing the client differences. Skip it if you only need headless tools, or if you cannot accept a framework sitting between you and the MCP specification. Before committing, check the Quickstart at docs.skybridge.tech, run npm create skybridge@latest in a scratch directory, and read the v2.0.0 release notes for breaking changes, because the README does not document a rollback path.

Frequently asked questions

Official sources

1. alpic-ai/skybridge on GitHub
2. License: MIT
3. Project website
4. README
5. Releases