Claude's tool catalog gets BM25 search while its memory API only offers a directory listing

One overflow problem, two different answers

A developer analysis published on dev.to draws attention to a design split inside the Claude Developer Platform: when there are more candidates than fit in context, the tool catalog and the memory store solve the problem in entirely different ways. Tools get ranked search. Memories get something closer to ls.

The observation matters because both surfaces hit the same wall. A tool catalog overflows when its definitions cost more context than the task justifies. A memory store overflows for the same reason, and the scale is documented: according to the Anthropic memory store guide cited in the post, a store can hold up to 10,000 memories, while a single List memories call returns at most 100 items per page, capped at 20 when items carry full content. Something has to pick which candidates reach the model.

The tool side ships ranked retrieval

On the tool side, the platform provides regex-based and BM25-based search tools out of the box, and Anthropic's advanced tool use documentation notes that developers can also build custom search tools using embeddings or other strategies. The API reference names two variants, tool_search_tool_regex_20251119 and tool_search_tool_bm25_20251119, with the BM25 variant letting Claude issue natural-language queries to find tools.

The mechanism defers definitions. Initially the context contains only the search tool itself plus any non-deferred tools; everything else arrives as a shortlist the API returns as tool reference blocks, up to five by default, with Claude able to raise the limit in its search input. The model never holds the full catalog.

The memory side ships a directory walk

The List memories endpoint takes exactly five query parameters: depth, limit, page, path_prefix and view. None of them is a search. Anthropic's own documentation supplies the file-system metaphor, describing depth of 1 as behaving like ls and an omitted depth as behaving like find. Ordering is described as stable and server-defined, which the dev.to post points out is not the same as relevant.

The client-side memory tool, which keeps files in infrastructure the developer controls rather than a managed store, lands in the same place: six documented commands covering view, create, edit and rename operations, with no search among them.

Naming is the retrieval design

The consequence, according to the analysis, is that path segments stop being organizational decoration and become the actual selection keys. Since path_prefix and depth are the only filters the endpoint offers, whoever invents the path scheme is doing the retrieval design.

Anthropic's own tool guidance makes this explicit for tools: search matches against names and descriptions, so descriptive definitions improve discovery, and consistent namespacing by service or resource lets one search surface a whole group. The memory best-practice guidance has no equivalent sentence about paths. It partitions one level higher instead, recommending smaller purpose-built stores, such as one per user, one for shared domain knowledge and one for project-specific context, while leaving the tree inside each store to whoever writes the paths. The full projection is also documented as the bulk-read path for export and sync, so bulk reads run over the same listing regardless of future API growth.

Why it matters

The split shapes how agents scale context. On the tool path, the platform does ranked selection and the model consumes a shortlist. On the memory path, the model reads a listing and decides relevance itself, which pushes retrieval quality onto path-naming discipline and onto the agent's own judgment. Builders assembling large memory stores may want to treat path design as a first-class engineering decision rather than an afterthought.

What the observation does not prove

The post is careful about scope. The endpoint is marked Beta behind a dated header, and all parameters were checked on 2026-09-07. A store attached to a session is also mounted inside the sandbox under /mnt/memory, where the agent reads and writes it with the standard toolset, so the gap is in one documented endpoint, not necessarily in the product. Nor does the post claim ranked search would be better for memory; that is an empirical question it does not test. The author also discloses working on Mnemoverse, a memory engine for AI agents, a competing interest readers should weigh when evaluating the argument.