harijoe

MCP Apps are the only way to build a connector that's actually usable from inside the Claude and ChatGPT apps. They return chunks of UI alongside the tool result, so a CLI simply can't provide the same functionality.

And you can't expect an average user to install a CLI on their machine just to search for flights or do shopping for example.

I work at Alpic, where we build Skybridge, a framework for developing MCP Apps. Our users have apps published on the ChatGPT and Claude stores, and they've seen traffic quietly growing over the last few months. Traffic isn't massive yet, but it costs little to stake out ground on a new channel and be ready if it takes off.

The Skybridge framework also ships with an easy-to-use tunnel if you'd like to give it a try. It does require a signup, to avoid spam.

You may want to have a look at Skybridge, a TypeScript framework designed to build MCP servers and MCP Apps, with a recent emphasis on making authentication easy.

Why did you choose to introduce a --llm flag instead of simply detecting that the command is being run by an agent using a library such as @vercel/detect-agent and outputting the tool-formatted output automatically? We recently worked on optimizing our CLI for agents at Alpic and discovered that agents often forget to use the --json flag.

Hi HN, core maintainer here. We packed a lot into this release, including an integrated tunnel, new DevTools, and an audit feature to help prepare your app for ChatGPT and Claude store submissions. I’d be happy to answer any questions.

Sure comparisons would be very interesting to list as well, maybe for a next post! This one is more beginner-oriented and I think it already brings value to some readers.

I realized many developers ignore these services. That's why I find it useful to share.

I was thinking of making a website for this. This post is actually a way to test if there is any interest.

I guess the limit could be avoided by using only one endpoint and use the path and HTTP method to decide which logic to execute though.

The serverless framework does not offer the best developer experience out of the box, that's why serverless boilerplate exists.

I did not know that, could you share a proof to back this statement ?

That's unfortunately not true. Everything the boilerplate provides is both necessary to get a nice developing experience and not provided by default by serverless.

Actually handly is just here to allow a single import on every serverless handler. I haven't worked much on the readme yet, but the idea is to gather all the "mandatory" middy middlewares as well as some middlewares I find necessary into a single dependancy.

I guess the difference is that a micro startup's goal is to find a market to become startup whereas a hobby project is not meant to evolve