OpenClaw was never meant to be a tool that could do things you couldn't do without it.
Also, whenever someone points out you could accomplish something without it, he underestimates the effort needed. In the examples I'm thinking of, someone simply asked OpenClaw to do something, had a few back and forths with it, and it was done. I have yet to see someone say "Oh, I can do that without OpenClaw" and go ahead and do it within 10 minutes.
Not once.
OpenClaw is flawed, but the convenience is an order of magnitude higher than anything else.
> the convenience is an order of magnitude higher than anything else.
You offered nothing to support this. My openclaw is realistically just an agent in discord versus the CLI. That's not an "order of magnitude" more convenient. Anthropic already has a tool for it https://code.claude.com/docs/en/remote-control
You've got it inverted. My point is the people saying "You could have done that just as easily with ..." are the ones not supporting it. The commenter has already built that thing with OpenClaw. If someone is saying it could easily have done without it - well, demonstrate it!
What a bizarre article. The morality of recreational torture is not a matter of factual correctness. Burden of proof is not a concept that makes any sense when there’s a disagreement over morality. You can make arguments for your position and those arguments may involve factual claims which can be proven or disproven, but the underlying morality can’t.
And then it ends with that sudden left turn into denouncing atheists as inherently irrational and evil. WTF?
Congratulations on bringing an argument so terrible that I’m actually more convinced of my position after having read it than I was before.
If you look at my comment history, you'll see what seems to be someone defending OpenClaw (even though I stopped using it).
I have some issues with the article, but I agree with some of the conclusions: It's great tinkering with it if you have time to spare, but not worth using weeks of your time trying to get a perfect setup. It's just not that reliable to use up so much of your time.
I will say, it's still amongst the best tools to do a variety of tasks. Yes, each one of those could be done with just a coding agent, but I found it's less effort to get OpenClaw to do it than you writing something for each use case.
Very honest question: One of the use cases I had with OpenClaw that I'm missing now that I don't use it: I could tell it (via Telegram) to add something to my TODO list at home while I'm in the office. It would call a custom API I had set up that adds items to my TODO list.
How can I replicate this without the hassle of setting up OpenClaw? How would you do it?
(My TODO list is strictly on a home PC - no syncing with phone - by design).
(BTW, the reason I stopped using OpenClaw is boring: My QEMU SW stopped working and I haven't had time to debug).
> I could tell it (via Telegram) to add something to my TODO list at home while I'm in the office. It would call a custom API I had set up that adds items to my TODO list.
All the existing, commodity todo list apps on the market can't address your use cases?
At least I can't tell there is anything you can't do on your personal phone.
> I could tell it (via Telegram) to add something to my TODO list at home while I'm in the office. It would call a custom API I had set up that adds items to my TODO list. How can I replicate this without the hassle of setting up OpenClaw?
The general idea is make a simple deterministic program that runs on your PC at home in a never ending loop. Every minute or so, check Telegram for a new message. If a message is received, then the program runs "claude -p" with a prompt, whatever MCP tools or CLI permissions it needs, and the contents of your Telegram message. Just leave the program running on your home computer while you're out, and you're done.
I don't use Telegram, so coding the part to check Telegram would be the hard part. I use email instead, and have the program check every minute for new mail (I leave my email program running and check the local inbox file). I'd already coded up a local MCP server to manage my ToDo list (Toodledo) so Claude just calls the MCP tools to add the task.
For things like TODO, I guess an email will suffice.
However, it was really nice being able to use Telegram and get quick validation. I also had a flow set up where I could send a voice memo. It would take the audio file (ogg), run Whisper, and then pass through an LLM for cleanup, and follow the instructions in my message. Really handy to use while I'm walking around.
I guess I want to create my own OpenClaw like agent, but not with its crazy broad access: Just limited to the functionality I allow, and with the convenience of using Telegram. I don't care about memory, soul, etc.
I did the exact same voice memo thing too, except I had Claude make an Android app to record the file and send it to Whisper. In the end I had the app just email the transcription & trigger Claude that way (ie receiving the email triggers my PC to wake up Claude), rather than sending Claude the audio file directly.
My reverse audio reply loop is convoluted - I have Claude generate its TTS file from Whisper/Mistral, and upload them to a server with an RSS file it updates, so I can play them in my podcast app (AntennaPod), then send me a notification via Pushover that the reply is waiting. I ended up building out an MCP tool for that workflow, so Claude really just calls the MCP tool with the text of what it wants to say, everything else is a deterministic program doing the work.
Memory is really useful to have - it can just be a bucket of searchable Markdown files. It's also useful to have a "reminders to self" Markdown file that Claude reads each time, and that Claude can update. I don't continue the same context window, and that "reminders to self" plus the ability to read previous emails in the conversation seems to be enough to keep the context going for me.
You'll feel better if you know exactly how your Claw is locked down. Mine doesn't have the open email access others are granting, not at all. Claude gets a bit grumpy about that and keeps begging for more access :)
I felt pretty clever until (1) I found a repo where they used this trick to create a full OpenAI compatible API endpoint[0] (lmao, the VC money distortion field spawning truly comical Rube Goldberg machines), and (2) they started banning "unauthorized" usage of the Claude sub, which trend unfortunately seems to be accelerating recently as their lower value consumers have grown in both number and usage.
I think shoving claude -p in your bash script / cronjob / messaging app bot of choice counts as "unathorized 3rd party harness", but your guess is as good as mine...
(claude -p with per-token billing (i.e. paying 7x more) is allowed though, of course)
-- There's also an Agents SDK (formerly Claude Code SDK?) which is basically just claude -p but with more typing, as far as I could tell.
> Very honest question: One of the use cases I had with OpenClaw that I'm missing now that I don't use it: I could tell it (via Telegram) to add something to my TODO list at home while I'm in the office. It would call a custom API I had set up that adds items to my TODO list. How can I replicate this without the hassle of setting up OpenClaw? How would you do it?
What you are looking for is an orchestration platform such as n8n or windmill.dev. You can still have a telegram bot and still use LLM for natural language interaction, but it's much more controlled than OpenClaw. I do exactly what you describe, add todos to my todoist account from telegram.
Basically all modern models can do that, in _any_ conversation. Write a skill that teaches it how to use your API and where the endpoints are. Local models will need a harness (look up pi), but any frontier model can do this out of the box.
Writing a script to make a POST request is something assistants have been able to do for quite a while now.
And if you have a Claude subscription, you can use Dispatch to directly write to your PC's drive, no API needed.
I'd use Obsidian with the sync. Or you can vibe code a telegram bot that calls that API for you in like 50 lines or something.
You can do anything if you believe!
Re: QEMU: For the sandboxing I realized what I actually wanted was "it can't read/nuke my files", so I made a non-privileged linux user and added myself to its group. So I can read/write its files, but not the reverse.
> It would call a custom API I had set up that adds items to my TODO list
You can use anything to call this API right? I have multiple iPhone shortcut that does this. Heck, I think you can even use Siri to trigger the shortcut and make it a voice command (a bit unsure, it’s been a while since I played with voice)
The API is on my home PC and not exposed to the outside world. Only OpenClaw via Telegram was. So my question is about the infrastructure:
How do I communicate with something at home (it could be the API directly) using a messaging app like Telegram? I definitely want an LLM in the mix. I want to casually tell it what my TODO is, and have it:
- Craft it into a concise TODO headline
- Craft a detailed summary
- Call the API with the above two.
I'm not asking in the abstract. What specific tools/technologies should I use?
Expose the API to the outside world using tailscale. Run your telegram bot on n8n or windmill.dev. You can absolutely use an LLM, both n8n and windmill.dev support AI agentic workflows. google "n8n LLM telegram bot" and you'll find tons of examples.
I've always wondered: Doesn't the fact that the MCP input/output is more structured lead to higher reliability? With MCP you declare the types for input (string, int, list, etc) and output.
As part of our product, we have an MCP server. Since many of our MCP tools are expensive, for our tests we simply give the LLM all the tool descriptions (but in text form, not structured) and ask it which tool it would call for a given query and assert on the response.
The tests are flaky. In practice, I've always seen the LLM make the right tool call with the proper formatting of args, etc. In the tests (same LLM model), it occasionally makes mistakes on the argument types and it has to try again before it gets it right.
My assumption was that the structure MCP provides was the reason there was a discrepancy.
Tool discovery is only one very small part of the “context problem”. The bigger problem is the outputs. You can’t compost them. Ever watch Claude code run some crazy shit through python and jq to take some input, transform it in some crazy way and output exactly what it needs back into its context? You simply can’t do that with mcp. It’s basically forced to accept the exact shape of the mcp output into its context and then take that intermediate output and dump it right back into another tool. That is incredibly wasteful!
If your lucky the mcp might expose a way to ship its output into a text file so at least the agent can have a go at it with CLI tools.
In the US, libraries are often part of a network, and we have access to all the materials in the network. So if my local library doesn't have it, I simply request it from another library. They ship it to mine and I pick it up (and return to mine).
Then we also have a larger inter-library loan, where I can request things from libraries far, far away (even in another state). It takes much longer, though, and if it is deemed a popular/useful item, my local library may decide to purchase it and give that one to me rather than use ILL.
You may want to check if your local library has something similar.
> These people aren’t doing bash loops, they’re regular non-technical people who just want to use an AI Agent to access services and aggregate data.
Over the last few months, this pattern of discussion has become pervasive on HN.
Point.
Counterpoint.
(Not finding a flaw with the counterpoint) "Yeah, but most people aren't smart enough to do it right."
I see it in every OpenClaw thread. I see it here now.
I also saw it when agents became a thing ("Agents are bad because of the damage they can do!") - yet most of us have gotten over it and happily use them.
If your organization is letting "regular non-technical" people download/use 3rd party MCPs without understanding the consequences, the problem isn't with MCP. As others have pointed out in this thread, you can totally have as secure an MCP server/tool as a sandboxed CLI.
Having said that, I simply don't understand yours (and most of others') examples on how CLI is really any different. If the CLI tool is not properly sandboxed, it's as damaging as an unsecured MCP. Most regular non-technical people don't know how to sandbox. Even where I work, we're told to run certain agentic tools in a sandboxed environment. Yet they haven't set it up to prevent us from running the tools without the sandbox. If my coworker massively screws up, does it make sense for me to say "No, CLI tools are bad!"?
My basic point is: why don't major multimillion dollar companies provide us with a way to limit MCP access? "With this ID, this specific MCP connection can only access database X in read-only mode" or "With this ID, this MCP connection can create new pages under this page, but cannot delete anything or modify pages it didn't create". Very very basic stuff.
I _can_ make a custom CLI, a custom MCP wrapper and whatever else to limit the things agents can access. But why do I need to? Am I the only one in the world who doesn't want to let ChatGPT run wild on our internal Notion without any hard limitations? We pay them ungodly amounts every month for the service and basic safeties aren't included unless we build them in.
Indeed, ever since MCPs came out, I would always either wrap or simply write my own.
I needed to access Github CI logs. I needed to write Jira stories. I didn't even bother glancing at any of the several existing MCP servers for either one of them - official or otherwise. It was trivial to vibe code an MCP server with precisely the features I need, with the appropriate controls.
Using and auditing an existing 3rd party MCP server would have been more work.
> that MCP description is going to totally rot your context and make your model dumb, and there's no mechanism for progressive disclosure of parts of the tool's abilities,
Completely false. I was dealing with this problem recently (a few tools, consuming too many tokens on each request). MCP has a mechanism for dynamically updating the tools (or tool descriptions):
We solved it by providing a single, bare bones tool: It provides a very brief description of the types of tools available (1-2 lines). When the LLM executes that tool, all the tools become available. One of the tools is to go back to the "quiet" state.
That first tool consumes only about 60 tokens. As long as the LLM doesn't need the tools, it takes almost no space.
As others have pointed out, there are other solutions (e.g. having all the tools - each with a 1 line description, but having a "help" tool to get the detailed help for any given tool).
Libraries are the single reason I got back into video games after a multi-decade hiatus.
I played very few games from 2002 to 2017. Didn't want to keep buying new computers, and did not want to bother with consoles (graphics was better on PC than a non-HD TV).
In 2010 I bought a PS3, but only to watch Blu-Ray, Netflix and stream from my PC to TV. Did not play games on it.
Then in 2016/2017, on a whim, I decided to check out a game from the library. I Googled some good games, and picked Telltale's The Living Dead.
Oh wow. One of the best games I've ever played. For the next 2 months I kept checking out games and playing them.
Then for some reason I stopped. I started again in 2022 and haven't looked back. Seriously cut down my TV watching so I can play the games. I don't use the library any more - I just buy the games.
reply