Project-local memory layer for AI agents — a tool-driven memory system with remember/recall capabilities
Curion provides 2 tools (remember, recall) with basic but incomplete definitions. Both tools have clear verb_noun naming (remember_*, recall_*) and descriptions present, but descriptions are short (under 100 chars) and lack critical context about when/why to use each tool. Input schemas are properly defined with JSON Schema, but descriptions for parameters are minimal. No output schema is documented. Error handling is not visible in the provided code. Tool composition is sound (each does one thing), but lack of structured output documentation and missing error guidance reduce overall quality.
Query project-local memory for relevant information
Store text in project-local memory
Parameter descriptions are absent or minimal. The 'text' parameter in both tools has description 'Memory text to store (required, non-empty)' and 'Query text (required, non-empty)' respectively, these are bare constraint statements, not LLM-optimized descriptions explaining WHAT the parameter controls, WHEN to use it, and FORMAT expectations.
Tool descriptions are short (under 100 chars) and lack context. 'Store text in project-local memory' and 'Query project-local memory for relevant information' do not explain WHEN to call this vs alternatives, what the memory scope is (project-local? session-local? persistent?), or what downstream uses are enabled.
Output schema is not documented. Neither tool declares what it returns, users/LLMs must infer from tool behavior. recall should document whether it returns a list of memories, a single best match, structured snippets, or free text. remember should specify return confirmation structure. Without documented output, LLMs cannot plan downstream calls or validate responses.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2025-06-18+ | v2 |
No error handling guidance. If remember fails (disk full, invalid UTF-8), or recall finds no matches, the expected error responses and recovery paths are not documented. Per pattern:recovery-guide, errors should tell the LLM what to do next (retry? try a different query? ask the user?). Current code shows no visible error classification or recovery hints.
Parameter validation rules are not documented. The 'text' parameter is required and non-empty, but descriptions do not state: max length, character restrictions, encoding expectations, or what happens if an empty string is passed.
No pagination or result limits documented for recall. If recall returns 1000 memory entries, the response bloats the context window.