Just have a route that describes your API endpoints in a machine readable format, eventually they'll come to some consensus and in the mean time this works well enough to allow LLMs to plan.
ages ago I tried using IPFS to more or less accomplish this, I imagined it to act more like a weights/training data network fs that everyone would be able to participate in.
The product isn’t meant for you or me it is for lawyers. If you can’t take on personal liability for a badly written contract then you shouldn’t be using it.
I'd expect they could indemnify you against hallucinations or similar if this gets good enough for that to be a very rare occurrence? Or you could buy insurance on it that's cheaper than hiring a lawyer (not a high bar to clear). I wouldn't rely on it currently, though.
I already use them for that, they are pretty excellent at it. Much better than the terms of use generator products that used to exist. That said, nobody cares to sue your business for the most part until you're big enough to be worth it. By that time, you'll have a team of legal analyst to assist you... or agents should I say.
Then again, nobody will have money to buy anything at this rate, so in all liklihood, this is a total non-issue.
We offer MCP and then consume it with our in-app assistant to go from a non technical prompt to a series of what is essentially API calls they can automate for themselves for repetitive tasks or things that require a few screens to accomplish can be done from the assistant widget itself, etc.
I agree with mostly all of this, but personally I wrote a toy LLM almost 5 years ago and while it never saw much use outside of boring my wife with a shitty command line demo with glee it did help me understand how they worked and how to apply them, played a lot with JAX and pytorch, ended up building a ghetto version of MCP and an LLM-Pool to proxy requests to my baby local models and so I didn't struggle to see the evolution of openrouter and MCP agentic workflows. The same way i'm really glad when I was younger I built a bad webserver by myself, a really painful SQLx type database, etc etc etc - none of these things led me to developing for Nginx or Oracle nor will knowing JAX get me a job at an AI research lab, but I do have a lot of depth in understanding how the technology works so that the flavors on top of them are easy to digest and make more use of immediately, and I think the same can be said for engineers coming into the field - if it's a spooky LLM box you aren't going to be squeezing the same amount of juice as the guy that knows how they work inside and out so having at least the understanding of a _babys first LLM_ is going to get you miles ahead of people who don't.
For anyone who wants to dork around there is https://github.com/rasbt/LLMs-from-scratch which is something amazing that I think anyone who wants to engineer things around LLMs should at least blast through and read.
Game cheating and reverse engineering MMO backends taught me a lot: databases, networking, securing a backend (and frontend), limitations of simpler languages when comparing them to more native options for building backends.
Agreed, I was very late to the game and was forced to learn VBA for excel sheets and that is how I finally broke into programming.
When I was a pre-teen I stumbled upon CD-rom hacking guide to bypass disc requirements on games, I remember opening up the file and the screen being filled with HEX code. I was so overwhelmed I just closed it and never touched programming after that for 15 years. My life would have been totally different if I had embraced the unknown instead of retreating.
Not nearly as sophisticated as myself who would mutter "When in doubt - Charlie out" before marking C.
reply