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

Design is inspired but the website is not related

I tried to address this problem some months ago with a chrome extension. Feel free to try and provide feedback to it : https://chrome.google.com/webstore/detail/oh-hi-mark/fcmdkga...

Not yet, I choose not to prioritise it. It could be the next feature if that's something people want though. I can propose you to create a topic and vote for it on https://productpains.com/product/oh-hi-mark. This is where I keep track of the next features.

Thanks DigitalSea!

I did a search and gave a try to Pocket. It's a nice app but not quite what I was looking for. I wanted something blazing fast and extremely simple to use.

For example, to retrieve a page in Pocket, you have to open the app (at least 1 click, probably 2 for most people), click the search icon, type your request. This was way too much for me. With Oh, hi Mark!, you press alt+O and type your request. You can even navigate to one of the result without removing your hands from the keyboard with navigation and enter keys. I think it's actually the fastest way to get to the result.

Another thing about Pocket, it only searches in the title apparently. Oh, hi Mark! indexes quite smartly what he can find on the page, giving different weights to the different strings extracted. This gives the search function way better results I believe.

All in all, Oh, hi Mark! is far from being as mature as Pocket, but I have a feeling it has its place in the hearts of the users preferring a simplicity/ease-of-use solution compared to a more feature-complete one :-)

I met a lot of people — mostly developers, including myself — whose chrome bookmark became so messy that on day, they just stopped using it. But bookmarks are awesome, they must be considered as a personal bookshelf for web articles. A reference to readings of the past. A couple of months ago, it was so frustrating when someone asked me about this good flexbox tutorial I told him about, but it took me 10 minutes to find it because they are tons of flexbox articles out there and I really wanted to give him this particular one I knew was good. 10 damn minutes whereas it should have taken 5 seconds.

Oh, hi Mark! was born :-)

I would be more than happy, if sometimes you share the same feeling, that you gave it a try. I hope it will eventually help other people like me.

I didn't know it. It seems indeed very powerful. I will try it and if it is as fast as elasticlunr, use it. Thanks :-)

This weight is mostly explained by the dependencies. Oh, hi Mark! relies notably on elasticlunr as a search engine and unfluff to scrape saved pages. There is definitely space for optimization here, but I chose to rather focus on features until now.

What an irony to use twitter bootstrap to make a FLOSS twitter :)