Memory Server
The memory server (servers/memory/) provides persistent, searchable memory across AI sessions.
Tools
This page documents the core memory tools. The server registers 24 tools in total — the rest cover behavioral context (crow.md sections), schedules, notifications, proactive recall (crow_deep_recall), embeddings maintenance, and memory-health analysis (crow_dream); see the per-category action list in Context Management.
crow_store_memory
Store a new piece of information in persistent memory.
| Parameter | Type | Required | Description |
|---|---|---|---|
content | string | Yes | The information to remember |
category | string | No | Category: general, project, preference, person, process, decision, learning, goal |
context | string | No | Additional context about when/why this was stored |
tags | string | No | Comma-separated tags for filtering |
source | string | No | Where this information came from |
importance | number | No | 1-10 importance score (default: 5) |
crow_search_memories
Search memories using full-text search (FTS5).
| Parameter | Type | Required | Description |
|---|---|---|---|
query | string | Yes | Search query |
category | string | No | Filter by category |
min_importance | number | No | Minimum importance threshold (1-10) |
limit | number | No | Max results (default: 10) |
crow_recall_by_context
Recall memories relevant to a given context. Uses FTS5 ranking to find the most relevant memories.
| Parameter | Type | Required | Description |
|---|---|---|---|
context | string | Yes | The context to match against |
limit | number | No | Max results (default: 5) |
crow_list_memories
List memories with optional filtering and sorting.
| Parameter | Type | Required | Description |
|---|---|---|---|
category | string | No | Filter by category |
tag | string | No | Filter by tag (partial match) |
min_importance | number | No | Minimum importance threshold (1-10) |
sort_by | string | No | Sort order: recent, importance, accessed (default: recent) |
limit | number | No | Max results (default: 20) |
crow_update_memory
Update an existing memory.
| Parameter | Type | Required | Description |
|---|---|---|---|
id | number | Yes | Memory ID to update |
content | string | No | New content |
category | string | No | New category |
tags | string | No | New tags |
importance | number | No | New importance score |
crow_delete_memory
Delete a memory by ID.
| Parameter | Type | Required | Description |
|---|---|---|---|
id | number | Yes | Memory ID to delete |
crow_memory_stats
Get statistics about stored memories. No parameters — returns counts by category, tag distribution, and total memory count.
Resources
memory://categories
Returns the list of valid memory categories.
Database
Memories are stored in the memories table with a companion memories_fts FTS5 virtual table for full-text search. SQLite triggers keep the FTS index in sync on insert, update, and delete.
Version history
Every change to a memory, and to the other content Crow keeps, is recorded by database triggers in item_versions (project files in a separate per-project store). That is not part of this server's tools. See the History, Trash and Undo guide for what is kept, Restore, Undo this job, the Trash and the size line, and servers/shared/history/ for the code.
Cross-instance sync
Every server-side write that needs to reach paired instances — including this server's own calls in servers/memory/server.js — goes through emitOrQueue (servers/shared/sync-emit.js): it is the only legal emit path for server code. When a live, feeds-enabled InstanceSyncManager is available, emitOrQueue passes the write straight through to emitChange; when there is no manager at all, or the manager is feeds-disabled (a --no-auth companion, or a stdio-mounted process that was booted with sync explicitly disabled), it durably queues the write into the sync_outbox table instead of dropping it, after checking the same SYNCED_TABLES/shouldSyncRow syncability gate the live path uses. This does not yet cover every stdio mount: the repo's crow-sharing stdio mount currently constructs a full, feeds-enabled InstanceSyncManager, so its emits still go live-shaped and can park unappended rather than reach the outbox — see "Scope of the success criterion" in the stdio-sync-outbox design spec for that remaining gap and its fix direction. The gateway process that owns the sync feeds drains sync_outbox (servers/sharing/sync-outbox-drain.js, started from servers/gateway/boot/mcp-mounts.js) in preserve-mode: each queued row is re-emitted through emitChange carrying its original queued lamport_ts rather than a freshly minted one, and a row is deleted only once every currently paired peer has a real, durable append recorded against it.