A durable memory and recall system for AI agents, with clustering, heat-based activation, reminders, and semantic search over stored facts.
Alexandria has well-structured tool definitions with clear naming (verb_noun pattern) and comprehensive descriptions. All 13 tools have input schemas with typed parameters. However, several tools lack parameter descriptions, output schemas are not documented, and error handling guidance is minimal. Descriptions are generally strong (100-300 chars, well above the 10-char minimum), but parameter-level documentation is inconsistent. The server demonstrates good intent around memory management and session tracking but falls short of production-grade polish in schema completeness and error recovery patterns.
Cancel a scheduled reminder by ID.
Check for due reminders and mark them as delivered. Returns reminders that are due now, optionally filtered by project scope.
Soft-delete a memory by ID. Use when the user explicitly says a stored memory is wrong, outdated, or should be forgotten — prefer update_memory for corrections that should be preserved as lineage.
Mark a session as complete and trigger final memory extraction and clustering.
Retrieve metadata and statistics for a session, including memory count, cluster health, and activation state.
Import a document or text file as memories, splitting it into chunks and embedding them for semantic search.
Output schemas not documented. Tools like retrieve_memories, recall, get_session, and list_sessions return structured data but lack documented response schemas. LLMs cannot plan downstream tool calls or extract fields without knowing the response structure.
Parameter descriptions missing or minimal. 'scope' in recall, 'project' in set_reminder/check_reminders, and 'session_id' in get_session/finalize_session lack descriptions explaining their format, constraints, or valid values. LLMs cannot infer parameter semantics from names alone.
No error handling guidance. Tools lack descriptions of failure modes, recovery steps, or actionable error messages. E.g., what happens if a memory ID doesn't exist? What should the LLM do next?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | <=2025-11-25 | v2 |
List reminders with pagination. Returns delivered, pending, and cancelled reminders.
List all sessions with pagination.
Broad semantic recall of memories relevant to a topic, with optional scope filtering. Returns clustered facts organized by relevance.
Search for memories semantically similar to a query. Returns the top-k most relevant facts with their similarity scores and metadata.
Schedule a reminder with a cron expression or absolute datetime. Reminders are delivered once and escalate to project scope if not consumed within the escalation window.
Persist a durable fact, decision, preference, or correction so future sessions/agents can recall it. Call this proactively whenever you learn something worth remembering — a user preference, an architectural decision and its rationale, a resolved bug's root cause, a gotcha you just discovered — not only when explicitly told to 'remember this'. Cheap and idempotent-ish (dedup happens via clustering); prefer storing over losing context. Write content as a standalone statement that makes sense without the current conversation. If the response carries `truncated: true`, the content was longer than the embedding sees and only its head is searchable: split it into shorter memories.
Update an existing memory with new content, preserving lineage. Use for corrections that should maintain history.
Pagination parameters lack constraints. list_reminders and list_sessions accept 'limit' and 'offset' but do not specify min/max bounds. Unbounded numeric parameters allow LLMs to pass absurd values (limit=999999) that break performance.
retrieve_memories min_similarity parameter lacks format guidance. Described as '0.0-1.0' but no indication of whether 0.5 is a reasonable default or if the LLM should always specify it. No guidance on when to use min_similarity vs relying on limit.