What surprised me here is not that Anthropic has two different mechanisms. It’s that the difference is so blunt. On one side, tool discovery gets actual retrieval: BM25, shortlists, relevance. On the other, memory looks like a directory walk. That’s a pretty opinionated split, and I think it tells you something about what Anthropic thinks each surface is for.
The tool side feels like they’ve accepted the obvious problem: a big tool catalog is useless if the model has to pay attention to all of it. So they let the platform do the narrowing. That seems sane. If you want Claude to choose from dozens or hundreds of tools, you probably do want a search layer, and BM25 is a decent pragmatic choice when you care about names and descriptions more than deep semantic recall. I’m not thrilled by BM25 as a universal answer, but for tool routing it’s hard to argue with. It’s cheap, transparent, and easy to reason about.
The memory side is more interesting because it does not try to pretend it’s a search engine. The listing behavior described here is basically “show me the tree and I’ll decide.” That can work fine if the tree itself is designed well, but that’s a big if. A stable server-defined order plus depth and path_prefix means the model is doing a lot of the retrieval work mentally. That’s fine for a small, disciplined store. It starts to smell risky when the store gets messy, because then “find the right memory” becomes “browse until the right path happens to look familiar.”
I think that’s the real takeaway: Anthropic seems to be separating ranked retrieval from structured navigation. Tools are content-addressable; memory is path-addressable. Those are different mental models, and they won’t age the same way. Ranked search gets you flexibility but also ambiguity. Path-based lookup gives you control, but only if you’re willing to design the namespace carefully. If you aren’t, you’ve basically offloaded the hard part to the agent and hoped for the best.
What I’d want to know next is whether this is just an API choice or a product philosophy. The article is careful not to overclaim, and I appreciate that. It does not prove there’s no memory search elsewhere in the stack. It only shows that the documented list endpoint is not doing retrieval in the way the tool catalog does. Still, that asymmetry is real, and I’d want to test it in practice before deciding whether it’s elegant restraint or an awkward gap.
Reference: The Same Platform Gives Its Tool Catalog BM25 and Its Memory Store ls
