Persistent memory MCP server with typed memories, decay scoring, and token-aware context injection
memento-mcp demonstrates strong definition quality with comprehensive parameter schemas, detailed descriptions, and clear semantic intent across most tools. 19 tools are well-documented with explicit type definitions and action verbs. However, there are gaps in output schema documentation (not explicitly defined in the visible code), missing error handling guidance in descriptions, and no tool annotations (readOnlyHint/destructiveHint). The server follows good naming conventions (memory_*, decisions_*, pitfalls_*) and provides rich parameter descriptions with context hints. Descriptions average 150-250 chars, exceeding the 72-char baseline, slightly verbose but informative. All tools have clear purposes and well-scoped responsibilities. The main limitations are: (1) output schemas not documented in tool definitions, (2) no error recovery guidance in descriptions, (3) missing destructive operation warnings despite having WRITE and REVERSIBLE risk classifications.
Log a decision made during this session or a past session. Stores decision context, rationale, alternatives considered, and outcome. Searchable by `memory_search`. Useful for design reviews and post-mortems.
Report memory usage, token consumption, auto-capture stats, compression ratio, and dedup metrics over a time period. Optionally filter by project. Useful for understanding session efficiency and memory lifecycle.
Compress a project's memory cluster using LLM-assisted summarization (if enabled). Creates a new 'compression' memory that consolidates multiple related memories. Marks original memories as 'derived_from'.
Check if a memory is near-duplicate of existing memories before storing. Returns similarity score and matching ID(s). Use with `memory_store` dedup parameter to avoid redundancy.
Soft-delete a memory by ID (marks deleted without removing from DB). Can be undone with `memory_undelete`. Hard deletion is reserved for admin CLI commands.
Output schemas not documented. Tool definitions include input parameters with type/description, but visible code does not show documented return types or output field descriptions for any tool. LLMs cannot plan multi-step chains or extract required fields downstream without explicit output schema.
Missing tool annotations. Tools marked as WRITE (memory_store, memory_update, memory_pin, memory_link, memory_compress, memory_import, decisions_log, pitfalls_log) lack destructiveHint in schema; tools marked READ_ONLY lack readOnlyHint; none carry idempotentHint. Modern MCP (2026-07-28) spec requires these hints so agents understand tool semantics without parsing descriptions.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 75 | 2025-06-18+ | v2 |
Export memories to a JSON file (optionally filtered by project, type, or tag). Includes full content, metadata, and edge graph. Used for backup, migration, or external processing.
Retrieve a single memory by ID. Returns full content (minus redacted private blocks), metadata, and decay/utility scores. Use after `memory_search` to read a full memory.
Walk the directed memory graph starting from a given memory. Returns neighbors, distances, and paths. Useful for exploring related memories and finding knowledge clusters.
Import memories from a JSON file. Merges with existing memories using dedup logic. Optionally overwrites or skips duplicates. Used for bulk upload, recovery, or team sync.
Create a directed edge between two memories, indicating a relationship (derived, related, supersedes, etc.). Used for knowledge graph navigation and multi-hop retrieval.
List all memories (optionally filtered by project, type, or tag). Returns summary rows (title, type, age, importance, decay score, injection count). Useful for auditing and export workflows.
Find the shortest path between two memories in the knowledge graph. Returns the path nodes, edge types, and distances.
Mark a memory as pinned (always high priority for injection and ranking). Useful for frequently-needed context like coding standards or critical gotchas.
Find memories by text or semantic similarity (if embeddings enabled). Returns title, summary, context snippet, type, age, and injection utility. Ranked by relevance and decay. Supports optional session/project filter and offset-limit pagination.
Persist a fact, decision, lesson, or pattern so it can be recalled later by `memory_search`/`memory_get` or auto-injected into future sessions. Use for durable context (decisions, gotchas, preferences, recurring commands). For transient notes or duplicates, prefer `memory_dedup_check` first. Writes one SQLite row, queues an embedding (when enabled), and optionally creates/updates an Obsidian vault note. `dedup="strict"` refuses duplicates, `"warn"` stores with a warning, `"off"` bypasses.
Retrieve the modification history of a memory. Shows creation date, updates, and any decay/injection events. Useful for auditing stale or under-utilized memories.
Remove a directed edge between two memories. Reverses the effect of `memory_link`.
Update a memory's title, content, type, tags, or importance. Does not reorder or re-embed unless content changes. Useful for corrections and tag maintenance.
Log a pitfall or gotcha encountered during work. Records the issue, impact, context, and workaround or prevention strategy. Searchable as a memory. Used to avoid repeating the same mistakes.
No error recovery guidance in descriptions. Descriptions state what tools do but omit recovery steps for common failure cases. E.g., memory_delete says 'soft-delete' but does not hint what to do if memory_id is invalid. memory_analytics resolves project paths but description does not guide agent on path format expectations.
No confirmation/dry-run pattern for irreversible operations. memory_delete (soft-delete, reversible), memory_import (with overwrite=true), and memory_compress (LLM-based summarization) lack confirmation or dry-run modes. Agents making mistakes could trigger unintended data loss.
Parameter validation rules underspecified. memory_analytics 'period' param accepts 'last_7d', 'last_30d', 'last_90d', 'all' but enum constraint not visible in schema definition. memory_store 'importance' accepts 0 - 1 but no min/max constraint visible. memory_link 'edge_type' has default 'related' but allowable values not explicitly constrained.