DEV Community: Julien Vallini

Skybridge V1.0: THE framework for building MCP apps

Julien Vallini — Tue, 19 May 2026 15:05:32 +0000

Building an MCP App is a genuinely new problem. You're not building a website or a standard API; you're building something that runs inside an AI assistant, interacts with a non-deterministic model, and renders UI within a chat. A year ago, none of that existed. Today, MCP Apps run reliably in Claude and ChatGPT, the official SDK has matured, and +1,000 apps are present in the public app stores.

Earlier this year, we open-sourced Skybridge, a full-stack TypeScript framework for building MCP Apps. It handles the plumbing: the MCP server, view rendering, CSP configuration, dev tools, client compatibility, and the connection between your server logic and your UI components. The goal is to let you focus on what your app does, rather than how to wire it all together.

The response was bigger than we expected. Skybridge now has 100k monthly downloads and powers over 10% of apps on the Claude and ChatGPT stores, with teams ranging from Fortune 500 companies to early-stage startups. That adoption is what's driving this release.

Today we're thrilled to introduce Skybridge 1.0, a first-class framework with a stable API, a complete developer toolchain, and a clear commitment to the MCP Apps ecosystem. If you're building an MCP App, this is the foundation to build on.

Simpler, type-safe API

The goal of Skybridge has always been to abstract away underlying implementation details. In v1, that means one entry point: server.registerTool(config, handler). It replaces the old split between plain tools and tools with a view: include a view in the config if you need one, and Skybridge wires it up. The Vite plugin handles component discovery and bundling automatically. Less boilerplate, fewer wiring mistakes, and a cleaner mental model overall.

Think of Skybridge as the React Native of MCP App development: one codebase, compatible with every environment.

Notably, we're the first framework to include strongly typed tool-to-component binding, which is particularly useful when building with agents, where small mistakes are difficult to track down. We've also standardized on the term "views" across the framework and docs.

A (really) complete dev loop

One of the hardest things about building MCP Apps has always been the feedback loop. You make a change, tunnel your local server, switch to ChatGPT or Claude, test, and repeat. For every small UI tweak or logic fix, that cycle compounds fast.

In V1, the dev tools have been redesigned from the ground up. They launch automatically when you run skybridge dev, with a layout reflecting how you actually work: views are now first-class in the interface, with a dedicated panel that makes it easy to see what your view looks like and how it responds to tool calls. There's a mobile preview mode for easy small-screen viewing.

Most importantly, the dev tools are now a unified control panel for your entire development workflow. From the dev tools header, you can:

Open a tunnel to test against a live AI client: Alpic Tunnel exposes your local server via a stable, authenticated URL that works with any MCP-compatible client.
Test your app in the Alpic playground, a production-like environment that avoids having to add your app to ChatGPT or Claude. It's the fastest way to iterate on tool behavior and UI together.
Audit your app with Beacon, a full compliance scan of your app against the Claude Connector Directory & ChatGPT App Store. Beacon catches the things that are easy to miss in local testing: CSP misconfigurations, missing tool descriptions, client-specific quirks.
Deploy directly to Alpic or wherever your stack lives once you're ready to ship.

We believe these devtools really combine everything a developer needs to build a production-grade MCP app with no platform or iteration friction.

Deploy everywhere

Lastly, we've long believed that a framework's value shouldn't come from locking you in.

1.0 makes good on that. Your app ships with a Dockerfile in the template, and the framework is now compatible with Cloudflare Workers. Alpic Cloud remains the fastest path to production if you want zero infrastructure work, but it's a choice, not a requirement.

In a similar vein, we've exposed the Express server giving you full control over the application and the ability to extend it with custom routes or middleware.

Getting started

If you're migrating an existing project, check out (or hand your coding agent) our release notes at:

https://github.com/alpic-ai/skybridge/releases/tag/v1.0.0

For new projects:

npm create skybridge

What's next?

V1 is a foundation, not a finish line, and it's a project we're investing more time into with every release. On the roadmap:

Dev tools: continued improvements, especially around CSP and auth debugging
Deployment: broader platform coverage
Protocol: simplified auth configuration & expanded client support
Agent-friendliness: programmatic devtool APIs, better plugins, and more

Is there something you'd like to see? Open an issue or find us on Discord!

Check out our latest Code with Fred to see the dev tools live in action.

Designing a CLI for Both Humans and Agents

Julien Vallini — Wed, 15 Apr 2026 10:03:17 +0000

We recently released the Alpic MCP and CLI, giving users two new interfaces with which they can interact. Designing the Alpic CLI for both humans and agents surfaced a set of challenges and tradeoffs worth writing down!

Why does building for agents matter?

Interfaces and layouts were designed for humans, i.e. to be easy to understand, and actions easy to perform. At Alpic we believe that agents are becoming the new interface: instead of directly interacting with a system, humans interact with an agent that interacts with the system. The human-agent interaction has been solved by LLMs — naturally, as agents have been trained mainly on human content, they are very good at understanding humans.

With the Alpic engineering team we're committed to solve the remaining challenge: the agent-system interface. In other words, how to give agents the capabilities to perform the same actions as humans do. Besides MCP, which has been designed exactly for this purpose, CLIs happen to be a surprisingly good connector. They were designed in the first place for humans to interact with machines in a textual way, so they naturally work well for agents too, which are heavily text-driven. On top of that, CLIs are composable and well-represented in training corpora, with lots of examples of how they should be used.

But designing a system (here a CLI) for both humans and agents comes with different requirements. This blog post explores these.

How are agents and humans different?

When it comes to CLIs, humans and agents behave surprisingly similarly: both will try calling a command with the --help flag to be guided toward the right usage.

The first difference is the context window: as an agent executes subsequent commands, it fills its context window, meaning that every additional call adds to token costs. This means verbose output is expensive — a command that dumps 200 lines of logs costs real money in an agentic loop.

Agents are also quite bad at polling. A human starting a deployment with a CLI will intuitively wait a minute or two before checking the status, expecting a final state (either deployed or failed). Agents won't wait around doing nothing; unless the command they executed blocks until completion, they'll immediately poll again and again.

Another difference is the inability for agents to handle interactive CLIs. This may improve in the future, but at the moment, agents are far more efficient sending non-interactive one-shot commands and getting the result as parsable JSON.

The Alpic CLI secret sauce

`--non-interactive`

All our commands implement a --non-interactive flag, which allows users to automatically accept confirmation prompts such as "Are you sure you want to…". The goal is to reduce context usage and prevent agents from being blocked by interactive prompts.

We also chose not to provide a JSON output format for now. Our tests show that agents are fully capable of understanding output intended for human users, and since JSON is a relatively verbose format, it adds unnecessary overhead to context usage. Additionally, dynamic console artifacts (such as loading spinners) tend to fill the agent's context with noise and should be avoided.

That said, this space is evolving quickly, and our perspective is still forming. We'd love to hear how others are approaching these tradeoffs. Feel free to share your experiences on our Discord!

Use only named parameters

We noticed that agents (and actually humans as well!) struggle with positional parameters in commands. By enforcing all parameters to be named, we reduce the risk of confusion by a lot. We also avoid a round trip to the documentation or to the --help flag.

No `--cwd` flag to avoid working directory confusion

We decided not to provide a way to choose the working directory of a command. For example, when creating a project with a relative root-dir: is it relative to the current working directory or to something else? Agents are good at navigating between folders, but bad at checking in which folder they execute a command, so removing --cwd reduces ambiguity.

We also added checks on deployment, for example to fail early if the directory the deploy command has been executed from is obviously a wrong one (e.g. an empty directory).

Commands better wait than returning early

Humans are fine with retrying a command every few seconds. Agents are not — they'll either poll aggressively (wasting tokens) or miss the final state entirely. Making commands block until completion is a much better fit for agentic workflows. Of course, when possible, it's even better for commands to return quickly, as this gives control back to the agent to decide what to do next.

In practice, this means our alpic deploy command doesn't return until the deployment has either succeeded or failed. Of course if something snags, our CLI gives up and returns an explicit error rather than leaving the agent waiting forever.

Explicit command names, not abbreviated

Unlike humans, agents don't mind typing a few more keystrokes. To reduce ambiguity, all of our commands and parameters use full words. We chose for example to name our command alpic environment-variable instead of alpic env which could be mislead as a command to manage environments and not environment variables. We understand that this added verbosity slightly increases token usage, but our tests show it's a worthwhile tradeoff, favoring clarity over minimal token usage.

Being stateless (not relying on implicit server state)

Humans know their own context: they may know, for example, whether they've already deployed their project successfully. An agent doesn't carry that context between sessions. Calling a command such as alpic deployments inspect without any parameter — expecting it to return the latest deployment — requires an implicit knowledge about what's on the server that agents can't reliably track.

For example, inspecting a deployment requires explicitly passing either a --deployment-id or an --environment-id, and these are mutually exclusive. Even retrieving the "latest deployment" must be scoped to a specific environment via --environment-id, rather than relying on hidden defaults.

We thus chose to always enforce explicit variables, ensuring that every command is deterministic and does not depend on implicit or session-specific context.

We also state explicitly in the console when a flag has been deduced from a linked project. This helps agents understand what happened, and it's actually better for humans too.

Conclusion

Most of the optimisations we made were actually aiming to reduce ambiguity and ensure that CLI output and parameters make the fewest assumptions possible. The result is that humans may need to type a few more keystrokes, but that's a fair price compared to the self-documenting side-effect of providing clear, full-word, named parameters and commands.

Our goal — which is also how we measure our CLI's agent-readiness — is to make sure we can develop, deploy, and monitor apps while only interacting with an agent. If the agent is the only interface our users need to interact with Alpic and the experience is smooth, we consider our CLI successful.

While our understanding of agent usage is still evolving and our experiments may shift our perspective over time, we're committed to building our CLI as a reference system where both agents and humans are treated as first-class citizens. Models are improving, and new agentic frameworks and systems are appearing every day — we look forward to keeping our CLI at the forefront and in step with these emerging use cases.

Head to our documentation to give the Alpic CLI a try.