Claude's memory list hands back 20 full items per call against a 10,000-memory store

Call the BM25 tool search and the model never holds the catalog. The API reference says the context initially contains only the tool search tool and any non-deferred tools ^[8]. The rest arrives as a shortlist: "The API runs the search and returns the matching tools as tool_reference blocks (up to 5 by default; Claude can set a limit in its search input)" ^[7]. Two server-side variants are registered, tool_search_tool_regex_20251119 and tool_search_tool_bm25_20251119, and the docs describe the second as the one where "Claude uses natural language queries to search for tools" ^[5][6].

Call List memories and the shape is different. The block titled Query parameters lists exactly five, depth, limit, page, path_prefix and view, with no query and no search among them ^[9]. Ordering is documented as well: "Items are returned in a stable, server-defined order." ^[11] A dev.to analysis that probed both sets of docs on 7 September 2026 reads that as the whole distinction, because a stable order is not a relevance order, and deciding what matters falls to the model reading the listing ^[20]. The docs supply their own comparison for the two selectors that remain: "depth=1 behaves like ls; omitting depth behaves like find" ^[10].

The scale is documented too. A store holds up to ten thousand memories ^[1], and one List memories call returns between 1 and 100 items per page, capped at 20 when it carries content ^[2]. Ten thousand divided by twenty is five hundred calls to read a full store with content in it ^[19]. That path is by design: the full projection is documented as the way to "use this as the bulk-read path for export and sync" ^[17].

On the tool surface, Anthropic writes down the consequence for authors. The engineering post on advanced tool use says "Tool search matches against names and descriptions, so clear, descriptive definitions improve discovery accuracy" ^[13], and the tool search reference tells authors to "Use consistent namespacing in tool names: prefix by service or resource" ^[14]. The memory best practices partition one level higher, at the store: "Rather than one large general-purpose store, use smaller purpose-built stores: one per user, one for shared domain knowledge, and one for project-specific context." ^[16] They cover store count and volume, not what to call a path ^[15]. Since path_prefix and depth are the only selectors the endpoint offers, the path segments are the selection keys, and inventing them is the retrieval work ^[21].

The client-side memory tool, the one that stores files in infrastructure the developer controls, has the same gap. Search is not among its six documented commands: view, create, str_replace, insert, delete and rename ^[12].

There is a narrowing worth keeping in view before anyone reads this as a platform-wide verdict, and the dev.to writeup states it: the parameter list is the HTTP list endpoint ^[22]. A store attached to a session is mounted in the sandbox as a directory under /mnt/memory/, and the guide says "The agent reads and writes the store with the standard agent toolset" ^[18]. On the tool side, Anthropic's own framing points past the built-ins: "The Claude Developer Platform provides regex-based and BM25-based search tools out of the box, but you can also implement custom search tools using embeddings or other strategies" ^[4]. No equivalent sentence for memory appears in the material. What search the standard agent toolset offers over that mount goes unstated.