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.

Nice. I made this project specifically because OpenAI tunnels don't work. So it makes sense that there are others who had the same idea.

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.

a few thoughts for MCP: - typescript "runs" in the browser, which is very handy to develop browser side MCP Clients - for similar reasons it is the only real option to develop UIs for MCP Apps for instance

not particularly related to MCP: as most products rely on external APIs provided by the labs (ChatGPT wrapper as we used to call them) frontend languages become more important

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.

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

Developers ignore Stripe?!

Again it would be more useful if you explained why they better to use than the ones we've heard of. The title should be "10 services I use".

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 was thinking of making a website for this. This post is actually a way to test if there is any interest.

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 ?

Try adding 40 endpoints to one serverless.yml file. You will quickly run over the 200 resource limit for cloudformation.

Actually, now that I think of it, since this is an AWS limitation, it may actually be fine on other providers.

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.

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.