Skybridge: a React framework for MCP Apps, read from the repository

The gap Skybridge is filling between MCP servers and MCP clients

A plain MCP server exposes tools that return data, and the client decides how to show it. MCP Apps change that: the README describes them as extending the Model Context Protocol with rich, interactive UI views rendered from MCP servers. Once a server ships its own UI, the conversational loop has three participants instead of two, and the user, the view and the model all have to stay in sync. The README is direct about why the existing tooling is not enough here, noting that the raw SDKs are low-level, with no hooks, type safety or HMR. Skybridge is the answer to that specific complaint. It is for TypeScript developers who already know React and want the same ergonomics they get from a normal web stack, applied to a server that a model talks to. It is not for someone writing a tool that returns a JSON blob and nothing else.

How the server, the model and the React view exchange data

The architecture page is where the mechanism lives, and the README points at it twice, under Fundamentals and Core concepts. What the README does state concretely is the shape of the type flow: tRPC-style inference runs from the MCP server tool definition through to the React view, so a change to a tool's input or output type surfaces in the frontend rather than at runtime. On the client side the hooks are described as React Query-style, which implies a request and cache model familiar to anyone who has used TanStack Query, though the README does not name the underlying library. Above that sits a compatibility layer: the framework abstracts implementation differences between MCP clients so the same app runs in Claude, ChatGPT, VSCode and other MCP Apps compatible clients. That abstraction is the core design bet. Rather than targeting one vendor's app SDK, Skybridge normalises the differences and renders one React tree. The README also mentions LLM context sync as a core concept, but the material does not explain the mechanism, so treat that as something to read up on in the docs rather than something this article can describe.

Bootstrapping a project and the two entry points

There are two ways in, and they are aimed at different readers. For a human, the README gives npm create skybridge@latest my-app, which scaffolds a project. For a coding agent, it gives npx skills add alpic-ai/skybridge -s skybridge, after which the README suggests asking the agent "What skills do you have?" to confirm the install, then prompting with tasks like "Create a new MCP app" or "Migrate my MCP server to the Skybridge framework". The migration prompt is worth noting: the project ships a migration guide at docs.skybridge.tech/guides/migrate, which implies the intended path for existing servers is to keep the tools and add the view layer, not to rewrite from scratch. Beyond that, the material does not list config keys, file names or environment variables, so anyone who needs the exact shape of a tool definition or the dev server options has to go to the Quickstart guide. The dev server itself is described as bundling a local emulator, hot module reload, and a permanent tunnel that connects a local app to Claude and ChatGPT. That tunnel is the part that changes day-to-day work: you are testing against the real clients rather than a mock.

Where the abstraction leaks and where Skybridge is the wrong choice

The same client-abstraction layer that makes one codebase possible is the main risk. When a framework normalises differences between Claude, ChatGPT and VSCode, the surface it exposes is the intersection of what those clients can do, and anything a single client adds later has to wait for Skybridge to model it. If your app depends on a capability that exists in exactly one client, you are working against the framework's purpose. There is a second, more mundane failure mode: the dev server holds a permanent tunnel to Claude and ChatGPT. That is excellent for iteration and awkward for anyone on a restricted network or behind a corporate proxy, and the README does not describe a fallback mode. Third, the project is moving. Releases listed are v2.0.0 on 2026-09-04, v1.4.1 on 2026-08-24 and v1.4.0 on 2026-08-11, with v2.0.0 arriving roughly three weeks after v1.4.1. A major version landing that soon after a minor suggests the API is still settling, and the material gives no compatibility or deprecation policy. Finally, if your server is text-only, none of this applies to you. A framework built around rendering React views adds a build step, a client bundle and a dev server to a problem that a few dozen lines of the base SDK would solve.

What the alternative looks like without a framework

The obvious alternative is the raw MCP SDK plus whichever app SDK the client ships, and the difference is not cosmetic. With the raw SDKs you get no hooks, no type inference across the server and view boundary, no HMR, and no emulator, which is exactly the list the README uses to justify the project. In exchange you get direct control: you target one client's app SDK precisely, you use its newest features the day they ship, and you carry no abstraction that has to be updated when a client changes. For a single-client app, that trade is often correct, because the abstraction is doing nothing for you. Skybridge earns its place when you genuinely need the same app in two or more UI-enabled clients and would otherwise maintain parallel view implementations. The README lists Datadog, Bitmovin, Evaneos, Touchstream and Cottages.com as companies that chose Skybridge, but the material gives no detail on what they built or why, so that list tells you the project is used in production and little more.

Maintenance cost, version churn and the MIT licence

The licence is MIT, per the repository metadata and the badge in the README. That is permissive: you can use, modify and redistribute the code, including in closed-source products, provided the copyright notice and permission notice are retained. This is a description of the licence text, not legal advice, and if the framework ends up inside something you distribute, have counsel read the LICENSE file rather than this article. The maintenance picture is the less comfortable half. Three releases in about five weeks, including a major, means upgrade work is a recurring line item rather than an annual one. The README does not describe a changelog policy, a support window for older majors, or a codemod for major upgrades, so the practical cost of moving from v1.4.x to v2.0.0 is not something the supplied material can tell you. Budget for reading release notes before every minor bump, and check whether the migration guide covers framework upgrades or only migrations from a hand-rolled MCP server, because the README presents it in the context of the latter.

Who should pick this up, and what to confirm first

Skybridge fits a TypeScript team with an existing React codebase and an MCP server that needs interactive views in more than one client. The type inference from tool definition to view is the feature that pays for the framework, because it removes a whole class of mismatch bugs between what the server returns and what the view expects. It does not fit a solo developer targeting ChatGPT only, and it does not fit a team that needs a client feature the abstraction has not modelled yet. Before adopting, verify three things. Run npm create skybridge@latest my-app and confirm the dev server's tunnel actually connects from your network to both Claude and ChatGPT, since a blocked tunnel removes most of the iteration benefit. Read docs.skybridge.tech/get-started/architecture and confirm the LLM context sync behaviour matches how your tools already manage conversation state, because the README names it as a core concept without explaining it. And check whether the v2.0.0 release notes describe breaking changes to the tool definition API, since that is the surface your existing server would have to adopt.

Editorial conclusion

Adopt Skybridge if you are a TypeScript and React team whose MCP server needs interactive views in more than one client, and you are willing to let a framework own the view layer in exchange for one codebase. Do not adopt it if your server only returns text, if you have already built a view layer against a vendor SDK, or if you cannot accept a pre-1.0-style version cadence on a project whose current major is v2.0.0. Before committing, run npm create skybridge@latest in a scratch directory, confirm the dev server's tunnel reaches both Claude and ChatGPT from your network, and check whether the generated tool definitions match the schema your existing server already exposes.

Official sources

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