MCP's are toys for point-and-click devs that no self-respecting dev has any business using.

Case in point; I'm mostly a Claude user, which has decent background process / BashOutput support to get a long-running process's stdout.

I was using codex just now, and its processes support is ass.

So I asked it, give me 5 options using cli tools to implement process support. After 3 min back and forth, I got this: https://github.com/offline-ant/shellagent-tools/blob/main/ba...

Add single line in AGENTS.md.

> the `background` tool allows running programs in the background. Calling `background` outputs the help.

Now I can go "background ./server; try thing. investigate" and it has access to the stdout.

Stop pre-trashing your context with MCPs people.

People are just ricing out AI like they rice out Linux, nvim or any other thing. It's pretty simple to get results from the tech. Use the CLI and know what you're doing.

Yes, exactly this. But idiot VC funding (which YC is also somewhat engaged in I imagine) cries for MCP. Hence multi billion valuations and many million dollar salaries and bonuses being thrown around.

It's ridiculous and ties into the overall state of the world tbh. Pretty much given up hoping that we'll become an enlightened species.

So let's enjoy our stupid MCP and stupid disposable plastic because I don't see any way that we aren't gonna cook ourselves to extinction on this planet. :)

That's a great point, the reality is that context, at least from personal experience, is brittle and over time will start to lose precision. This is a always there, persistent way for claude to access "memories". I've been running with it for about a week now and did not feel that the context would get bloated.

While I totally agree with you, I also can see a world where we just throw a ton of calls in the MCP and then wrap it in a subagent that has a short description listing every verb it has access to.

I still do, but having this allows for strategies like memory decay for older information. It also allows for much more structured searching capabilities, instead of opening file which are less structured.

.md files work great for small projects. But they hit limits:

1. Size - 100KB context.md won't fit in the window 2. No search - Claude reads the whole file every time 3. Manual - You decide what to save, not Claude 4. Static - Doesn't evolve or learn

Recall fixes this: - Semantic search finds relevant memories only - Auto-captures context during conversations - Handles 10k+ memories, retrieves top 5 - Works across multiple projects

Real example: I have 2000 memories. That's 200KB in .md form. Recall retrieves 5 relevant ones = 2KB.

And of course, there's always the option to use both .md for docs, Recall for dynamic learning.

Does that help?

Memory features are useful for the same reason that a human would use a database instead of a large .md file: it's more efficient to query for something and get exactly what you want than it is to read through a large, ultimately less structured document.

That said, Claude now has a native memory feature as of the 2.0 release recently: https://docs.claude.com/en/docs/claude-code/memory so the parent's tool may be too late, unless it offers some kind of advantage over that. I don't know how to make that comparison, personally.

Some of the other similar tools just arbitrarily pick the 3,5 or 10 most relevant memory results, which seems awkward.

Totally, point taken. I'll dig a bit deeper into that.

I think that's a great point really. There is not 1 size fits all, different people will have different strategies that better suit their workflow.

Yeah this is what I do, you want the knowledge in md files , but currently you don't want to stuff up the context with everything you know every time. I may be wrong here but my impression is the way that "context" is special and very limited in size vs "things the LLM is trained on" is still an unsolved problem getting AI to act like an "assistant" , AFAICT.

Who should own the context?

Imagine having 20 years of context / memories and relying on them. Wouldn't you want to own that? I can't imagine pay-per-query for my real memories and I think that allowing that for AI assisted memory is a mistake. A person's lifetime context will be irreplaceable if high quality interfaces / tools let us find and load context from any conversation / session we've ever had with an LLM.

On the flip side of that, something like a software project should own the context of every conversation / session used during development, right? Ideally, both parties get a copy of the context. I get a copy for my personal "lifetime context" and the project or business gets a copy for the project. However, I can't imagine businesses agreeing to that.

If LLMs become a useful tool for assisting memory recall there's going to be fighting over who owns the context / memories and I worry that normal people will lose out to businesses. Imagine changing jobs and they wipe a bunch of your memory before you leave.

We may even see LLM context ownership rules in employment agreements. It'll be the future version of a non-compete.

They do, new feature, not available in claude code but via API headers. https://docs.claude.com/en/docs/agents-and-tools/tool-use/me...

Yes I did, I worked on this a while back, before it was availabale I believe. I'll have another check. Thanks for the heads up

> This will reduce token size, performance & operational costs.

How? The models aren't trained on compressed text tokens nor could they be if I understand it correctly. The models would have to uncompress before running the raw text through the model.

Absolutely! But this is not a replacement of those files, this is a different (better?) way to navigate through those learnings instead of having to read whole files.

I've been experimenting with that in the last couple of days. I added to CLAUDE.md a directive on how and when to use recall and he's autoamtically calling the tool for store and fetch

I've been building exactly this. Currently a beta feature in my existing product. Can I reach out to you for your feedback on metaprompting/grammarly aspect of it?

Totally get what you're saying! Having Claude manually call memory tools mid-conversation does feel intrusive, I agree with that, especially since you need to keep saying Yes to the tool access.

Your approach is actually really interesting, like a background process watching the conversation and deciding what's worth remembering. More passive, less in-your-face.

I thought about this too. The tradeoff I made:

Your approach (judge/watcher): - Pro: Zero interruption to conversation flow - Pro: Can use cheaper model for the judge - Con: Claude doesn't know what's in memory when responding - Con: Memory happens after the fact

Tool-based (current Recall): - Pro: Claude actively uses memory while thinking - Pro: Can retrieve relevant context mid-response - Con: Yeah, it's intrusive sometimes

Honestly both have merit. You could even do both, background judge for auto-capture, tools when Claude needs to look something up.

The Grammarly analogy is spot on. Passive monitoring vs active participation.

Have you built something with the judge pattern? I'd be curious how well it works for deciding what's memorable vs noise.

Maybe Recall needs a "passive mode" option where it just watches and suggests memories instead of Claude actively storing them. That's a cool idea.

I think that's a great point. I will experiment with different approaches. I started with redis mostly because it's something I have experience with and was a quick setup win, but having different strategies I think it could make sense.

Yeah it still uses context but way more efficiently, instead of injecting a 50KB context.md every time, Recall searches 10k memories and only injects the top 5 relevant ones (maybe 2KB), so you can store way more total knowledge.

Yeah people do that but it doesn't scale, after a while your "restart prompt" is 50KB and won't fit, plus you're stuck copying stuff manually instead of just asking "what did we say about Redis" and getting the relevant bits automatically.

I've been using it for a while now, personally. I've found that I have less issues with context, I can easily recall (pun intended) after a context compact, etc.

That's a great point! And also works really well for shared context between claude instances, for example, we use that for our business model in the company, all business rules and model is stored as memories in a central redis that the mcp connects to. The way that memories are stored are specific to a folder or global (similar to CLAUDE.md home directiory), but with this approach you can have an external redis where multiple claudes read and write into as a shared almost hive like memory.

Yep! Valkey should work fine.

Recall just uses basic Redis commands - HSET, SADD, ZADD, etc. Nothing fancy.

Valkey is Redis-compatible so all those commands work the same.

I haven't tested it personally but there's no reason it wouldn't work. The Redis client library (ioredis) should connect to Valkey without issues.

If you try it and hit any problems let me know! Would be good to officially support it.

Yep, me too. I've taken the reference memory mcp that anthropic release and bolted on pgsql, but with a bunch of other features that are specific to the app I'm building. Like user segmentation/isolation with RLS (app is multiuser) and some other entity relationship tracking things.

No particular specific reason. I was working with another project that also had redis and decided to start with it. It can be changed to other tool, which one would you recommend?