Persistent, encrypted memory for AI agents with 25 tools spanning episodic recall, knowledge graphs, hybrid search, session management, and operational controls.
Memory Management – Remember, recall, and forget facts (L4 CoreMemory) with importance scoring; separate user/agent layers.
Sessions & Episodes – Start/end sessions (L2), save/recall emotional episodes (L3) with tags and weight.
Knowledge Graphs – Epistemic and temporal graphs: add/query nodes (facts, decisions, errors) and edges.
Hybrid Search – FTS5, semantic (MIB), or combined search across RAG and Wiki entries, with ITS novelty scoring.
Context & Stats – Compressed context summaries for prompt injection, plus memory statistics.
Wiki System – Manage user/agent wiki pages stored as markdown, indexed with FTS5.
Administration – API key management, automated backups/restores, data import/export, sagas with rollback, deduplication/cleanup, emergency purge, and replica sync.
Security & Transport – Envelope encryption, authentication, rate limiting, Prometheus metrics, real‑time dashboard; stdio and HTTP transports; installable via npm, pip, or Docker.
Integrates with Hermes Agent to offer memory capabilities including episodic recall, knowledge graphs, and hybrid search for agent identity and learning.
Exposes a Prometheus-compatible metrics endpoint for monitoring server performance, memory usage, and request rates.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-ariel-memory remember that my favorite color is blue"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Your AI agents forget. a-memory makes them remember. 4-tier agent memory with hybrid search and a real knowledge graph — all in plain SQLite files. Zero cloud. Zero external APIs.
Also available on PyPI:
pip install a-memory— optional extras:a-memory[embeddings]for real multilingual embeddings.
Every other memory server sends your agent's data through a cloud API or requires a separate vector database.
a-memory stores everything in SQLite files on your machine.
Zero infrastructure. No Docker, no database server, no embedding API keys.
Zero data leaving your network. Works air-gapped.
Layer-isolated by design. User facts and agent identity never share a namespace.
One directory = entire memory. Back up with cp, sync with rsync.
Related MCP server: ContextStream MCP Server
Three problems a-memory solves:
① Agent self-evolution — your AI stops repeating mistakes between sessions. It remembers decisions, errors, and corrections in a dedicated agent layer, and an hourly consolidation sweep promotes what matters into long-term facts.
② User persona persistence — your agent knows who it's talking to even after weeks of silence. Preferences, history, emotional context live in the user layer, isolated from agent identity.
③ Project continuity — project tracks per-project context: decisions with rationale and outcomes, artifact maps, a graphify-powered code index — so a fresh session picks up where the last one left off.
pip install a-memory
a-memory # MCP server on stdio — connect from any MCP clientPoint your MCP client at it:
{
"mcpServers": {
"a-memory": {
"command": "a-memory"
}
}
}HTTP transport with dashboard:
a-memory --transport http --port 8000 --dashboardOr run from source:
git clone https://github.com/Cipher208/a-memory.git
cd a-memory
uv sync
uv run ariel-memoryAgents see exactly five tools — one verb per intent, no tool-choice paralysis:
Primitive | Intent | What it does |
| remember | Routes content to the right layer (L4 facts / L3 episodes / wiki / graph) based on importance, emotion, and relations |
| recall | Hybrid search across ALL layers (FTS5 + binary embeddings + wiki + graph), returns a token-budgeted digest |
| let go | Context-aware deletion with Shadow Bin archival (exact / fuzzy / recent) |
| grow | Records personality/rules evolution for the agent |
project | continue | Per-project identity, decision log, artifact map, code index |
Quick demo — Python MCP client:
# think — routed to the right store automatically
await session.call_tool("think", {"text": "User prefers dark mode", "layer": "user"})
# dream — finds it across every store, a week later
res = await session.call_tool("dream", {"query": "dark mode preference"})
print(res["summary"])65 fine-grained operations exist in total, grouped into coherent opt-in tiers: the 6 primitives are exposed by default; add context (recall protocol, /new session recap, smart context budget, steering hints, tool-output compression), insight (Memory Query DSL, provenance fact-blame, quality loop, reflections, stats), write (typed memory schemas, declarative rules engine, scratchpad, counterfactuals, episodes), plus wiki, brief, and review (staged mutations) — e.g. ARIEL_EXPOSE=primitives,context,insight,write,wiki,brief,review (65 tools), or everything via ARIEL_EXPOSE=all.
⚠️ Env sanitization gotcha (stdio): MCP clients pass a sanitized environment to stdio servers — setting
ARIEL_EXPOSEin your shell profile does nothing. Define the tier set in your MCP client config (theenvblock of the server entry — see configuration guide). The server logs its resolved surface at startup (tool exposure: 65/65 tools) — if your agent reports seeing only the primitives, check that line first, then restart the client session (tool lists are cached per session).
Category | What's inside |
🧠 Memory | L1 Reflex (atomic persistence) → L2 Sessions → L3 Episodic → L4 Core, importance scoring, typed memory kinds with TTL policies, layer isolation; 65 tools including |
🔍 Search | FTS5 + MIB binary embeddings + hybrid RRF ranking, multi-source merge (RAG + Wiki + Episodic + Core + Graph), ACT-R activation scoring with memory-kind weights, embedding-path circuit breaker (graceful hash-fallback), dream digest |
🕸️ Graph | Epistemic knowledge graph + temporal timeline, typed nodes and edges, BFS traversal, 1-hop GraphRAG expansion |
📁 Projects | Decision log (what/why/outcome), artifact map, graphify code index — survives between sessions |
⚡ Auto-Hooks | Push-model memory: a per-agent daemon tails the conversation and ariel saves what matters on its own — importance thresholds, staged mutations (proposal → review → apply → revert), |
🎯 Skills | Skill = Memory: agent-read Markdown pages (first-class |
🔐 Security | NaCl |
🛠️ Ops | Auto-backup cron, saga rollback pattern, Prometheus metrics, read-only replica, hourly self-maintenance (decay + consolidation + auto-VACUUM) |
🌐 Wiki | FTS5-indexed markdown files — edit in Obsidian/VS Code, search from MCP, 6 analytical perspectives ( |
graph TD
A[LLM Agent] -->|MCP Protocol| B[mcp_server]
B --> C{Importance Scoring}
C --> D[L1: ReflexBuffer]
D --> E[L2: SessionStore]
E --> F{EmotionTrigger?}
F -->|high emotion| G[L3: EpisodicMemory]
F -->|normal| H[L4: CoreMemory]
B --> I[RAG Engine]
I --> J[FTS5 Search]
I --> K[MIB Binary Search]
I --> L[Hybrid RRF Ranking]
B --> M[Wiki System]
M --> N[.md Files]
M --> O[SQLite Index]
B --> P[Knowledge Graphs]
P --> Q[Epistemic Graph]
P --> R[Temporal Graph]
B --> S[Project Store]
S --> T[Decisions / Artifacts / Code Index]
U[Hourly Sweep] -->|consolidate| G
U -->|promote| H
U -->|auto-VACUUM| V[(SQLite)]a-memory | mem0 | letta (memgpt) | chroma | |
MCP native | ✅ 5 primitives | ❌ no MCP server | ❌ | ❌ |
Layer isolation | ✅ User vs Agent namespaces | ❌ | ❌ | ❌ |
Local-only (no cloud) | ✅ SQLite — 0 infra | ⚠️ API or self-host Docker | ❌ needs LLM API | ✅ local OSS + Cloud option |
Own semantic search (no API) | ✅ FTS5 + MIB binary hybrid | ⚠️ BM25+entity (LLM-dependent) | ❌ LLM-only | ⚠️ hybrid on Cloud only |
Knowledge graph | ✅ Typed nodes + edges + temporal timeline | ⚠️ entities only | ❌ | ❌ |
Envelope encryption (secrets) | ✅ NaCl SecretBox (auth/saga secrets; memory data is plaintext SQLite) | ❌ | ❌ | ❌ |
Lifecycle hooks | ✅ 19 names, per-layer, config-gated | limited | limited | none |
Self-maintenance | ✅ Hourly consolidation + auto-VACUUM | ❌ | ❌ | ❌ |
Backup / restore | ✅ Auto-cron + saga rollback | ❌ | ❌ | ❌ |
Notes (Sep 2026): mem0 now ships a self-hosted Docker image and a managed cloud with hybrid BM25+entity search; chroma is 29k★ and added hybrid+FTS5 to its Cloud tier (OSS server remains vector-only). What still differentiates a-memory: zero-infra SQLite (no Docker), NaCl-encrypted auth/saga secrets, layer isolation, hourly self-maintenance, and the temporal graph timeline.
4-layer memory hierarchy with layer isolation
Hybrid search (FTS5 + MIB binary embeddings)
Knowledge graphs (epistemic + temporal)
Hourly consolidation sweep + DB self-maintenance
mcp 2.x native SDK
Repo renamed to Cipher208/a-memory; PyPI package live (pip install a-memory)
Temporal timeline wired end to end (think/evolve/project events + dream recent digest)
Dream-cycle inject + auto-generated CONTEXT.md snapshot (curated context + 6 wiki perspectives + recent episodes, per-layer, per-agent)
Phase C — auto-hooks keystone (push-model memory: per-agent conversation daemons, external event dispatcher, importance-gated auto-save, staged mutations with review/revert, dream markers, session-start inject, gap reports; guide)
Phase D — compaction-aware rehydrate (drift log + salvage into the summarizer + one-shot rehydrate blocks; MiMoCode plugin / Hermes native MemoryProvider / CowAgent hooks — integration guide)
Phase D — /recall protocol (multi-axis proportional recall: markers → session → semantic → expand → day; drives Hermes per-turn prefetch)
Phase D — Skill = Memory (Markdown skills as a first-class wiki type, progressive disclosure wiki_list → wiki_search → wiki_read, 4KB lint cap, promotion pipeline, shared SSOT sync, usage-driven evolution — skills guide)
Phase D — working memory + meta-memories (agent scratchpad re-injected at session start, deterministic reflections, smart context budget with weighted floors, counterfactual notes, was_useful quality feedback loop)
Phase D — memory tools D1.2-D1.9 (session continuity recap + steering hints, tool-output compression + recall verification, provenance fact-blame, Memory Query DSL, typed memory schemas, declarative rules engine; coherent ARIEL_EXPOSE tiers: context / insight / write)
Phase E — hardening & closure (18 items across 3 waves): durability — atomic L1 persistence (temp→fsync→os.replace) + per-instance ring files, a circuit breaker guarding the embedding model path (3 failures → open 30s → hash-fallback keeps recall serving), least-privilege wiki roots + traversal-safe backup restore; operations — memory_diagnose/memory_heal (DB/migrations/L1-files/breaker checks + remigrate/reset-breakers/purge), integrity score in the report card, <cache:break> markers + stable-first inject ordering for provider prompt caches; retrieval — faceted tag queries (dimension:value, same-dim OR / cross-dim AND), memory-kind weights in ACT-R scoring, disclosure triggers («when X, surface Y» recall-side rules); wiring — real context_threshold/memory_pressure emitters (Hermes plugin + autohooks daemon), on_turn_end event, wiki_write staged mutations with revert, transition-level consolidation revert, causal-link producer on memory_graph_add; validation — DREAM markers anchored to message start (document-fragment false positives eliminated), post-compaction semantic audit (episode coverage by the L4 set)
Screenshot / asciinema demo in README
LLM-assisted consolidation on top of the deterministic sweep
Stage 2 — tool-surface redesign (slot system, URI keys, inject/key consolidation — planned with the A-remainder)
PRs welcome! See CONTRIBUTING.md.
MIT © Cipher208
⭐ If this project helps you, star it on GitHub.
Universal Primitive: Hybrid search across ALL layers (L3, L4, Wiki, Graph) with context construction.
| Name | Required | Description | Default |
|---|---|---|---|
| layer | No | user | |
| limit | No | ||
| query | Yes | ||
| intent | No | balanced | |
| user_id | No | default |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It does disclose the core behavior: hybrid search across multiple layers and context construction. However, it does not reveal side effects, permissions, rate limits, or what 'context construction' concretely entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact single sentence that front-loads the main behavior. The phrase 'Universal Primitive' is somewhat vague and adds little, but overall there is no unnecessary verbiage or buried structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool with five parameters, no annotations, and no parameter documentation. It does not explain how to choose intent, layer, limit, or user_id, nor does it offer enough context to differentiate dream from its siblings. The presence of an output schema reduces some burden, but invocation guidance remains inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the five parameters (query, layer, limit, intent, user_id). The mention of layers refers to L3/L4/Wiki/Graph, not the 'user'/'agent' values of the layer parameter, so it provides no practical parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a hybrid search across all layers (L3, L4, Wiki, Graph) and that it constructs context. This is a specific action with a defined scope, though it does not explicitly contrast itself with sibling tools like think or forget.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The tagline 'Universal Primitive' gestures at broad applicability, but there is no explicit guidance on when to use dream versus think, forget, evolve, or project. No exclusions, prerequisites, or alternative selection criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Universal Primitive: update agent personality and triggering evolution.
| Name | Required | Description | Default |
|---|---|---|---|
| user_id | No | default | |
| instruction | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing side effects. 'Update agent personality and triggering evolution' names the effect at a high level but never states whether the change is permanent, whether it overwrites existing personality, or what 'evolution' entails. For a mutation-style tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is appropriately brief, but the 'Universal Primitive:' prefix carries no information and 'and triggering evolution' is grammatically awkward and vague. The word budget could be far better spent clarifying the instruction parameter or the meaning of evolution; this reads as under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the tool mutates agent state and the description fails to clarify the meaning of 'evolution', the expected content of the required instruction parameter, or how this relates to sibling tools like forget. Even for a small two-parameter tool, an agent cannot reliably decide the correct input or predict the outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so neither user_id nor instruction has any schema-level explanation. The description does not mention either parameter — especially the required 'instruction' — leaving the agent to guess what content, format, or length an instruction should take. It adds essentially no meaning beyond the parameter names themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb and resource ('update agent personality'), giving a baseline sense of the operation. However, the 'Universal Primitive' prefix is vague framing and 'triggering evolution' is undefined jargon — an agent cannot tell what an evolution is, how it manifests, or how this differs from sibling tools like forget or project. The core action is discernible but the overall purpose is muddled.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No sentence or clause addresses when to call evolve versus its siblings (think, dream, forget, project). There are no conditions, exclusions, or alternative routing. An agent must guess whether evolve is for permanent trait changes, one-off mental operations, or something else entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Universal Primitive: context-aware forgetting with Shadow Bin support.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| layer | No | user | |
| scope | No | exact | |
| minutes | No | ||
| user_id | No | default | |
| shadow_bin | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only hints at 'context-aware forgetting' and 'Shadow Bin support.' It does not describe what gets deleted, whether Shadow Bin makes deletion recoverable, how scope affects behavior, or what side effects occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than efficiently concise. The phrase 'Universal Primitive' wastes space without adding useful guidance, and no structured detail about behavior or parameters is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, two enums, defaults, no annotations, and no parameter descriptions, a single-tagline description is far from complete. While an output schema exists, the agent still lacks enough context to understand scopes, layers, the Shadow Bin mechanism, or what 'recent' forgetting with minutes means.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only loosely maps to shadow_bin and context-awareness. It adds no concrete meaning to key, layer, scope, minutes, or user_id beyond what the parameter names and enum values already imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the operation as context-aware forgetting with Shadow Bin support, which points to a memory-removal primitive rather than just restating the tool name. However, 'Universal Primitive' is vague branding and does not specify what resource is being forgotten or how this differs from the sibling tools beyond the verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus think, dream, evolve, or project. There is no indication of use cases, preconditions, or scenarios where the tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fire one external lifecycle event (session_started, new_message, ...).
Args: event: one of KNOWN_EVENTS (session_started, session_ended, new_message, auto_save_candidate, context_threshold, memory_pressure, post_context_compression). payload: event body. Recognized keys per event: session_ended: {"summary": str}; new_message/auto_save_candidate: {"text": str}; post_context_compression: {"query": str}; session_started: {"text": str?, "budget": int?}. layer: "user" (default) or "agent". user_id: subject user (bound to API key on HTTP transports). ctx: MCP context (injected).
Returns: Handler results dict; unknown event raises ValueError (MCP error).
| Name | Required | Description | Default |
|---|---|---|---|
| event | Yes | ||
| layer | No | user | |
| payload | No | ||
| user_id | No | default |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and does a solid job: it lists all KNOWN_EVENTS, defines recognized payload keys per event, documents layer/user_id defaults, states the return type, and calls out the ValueError for unknown events. It does not fully describe side effects of firing the event, but the event list and error behavior provide substantial disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring is organized with Args and Returns sections, front-loaded with the core action, and every line contributes useful information. The only minor redundancy is the event list appearing both in the opening and in the event arg, but the details justify it.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations, the description is complete: event vocabulary, payload schema, defaults, auth-bound user_id, context injection, return shape, and error handling are all covered. The stated output schema and return description together make calling this tool unambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 0%, so the description must explain the parameters, and it does. It enumerates all valid event values, documents the payload structure by event type, and clarifies defaults for layer and user_id. This goes well beyond the bare schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a clear verb and resource: 'Fire one external lifecycle event' and enumerates the exact event names. This is specific enough to know what the tool does, but it doesn't explicitly position itself against sibling tools (think, evolve, dream, forget, project), so it doesn't fully achieve sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use memory_hook versus think, evolve, dream, forget, or project. The event list implies use cases (session_started, new_message, etc.), but there is no explicit condition or exclusion such as 'use X for internal reasoning'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Universal Primitive: managing project-specific context and file mapping.
Projects are global (keyed by name). Structured data (identity, decisions, artifact map, code index) lives in projects.db; large documents go to the Wiki as project_spec pages.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| path | No | ||
| role | No | ||
| layer | No | user | |
| action | Yes | ||
| status | No | ||
| details | No | ||
| outcome | No | ||
| user_id | No | default | |
| decision | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does disclose non-obvious behavioral traits: projects are globally keyed by name, structured data persists in projects.db, and large documents go to the Wiki as project_spec pages. However, with no annotations present, the description carries the full burden and still does not explain action-specific consequences such as whether init overwrites, archive mutates, or recall reads.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads the storage model with minimal filler, but the opening label 'Universal Primitive' is not informative. The brevity is achieved by omitting essential operational semantics rather than by condensing them.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, two enums, no annotations, and no schema-level descriptions, the description only covers the persistence model. It does not tell an agent how to invoke init, update, archive, mapping, audit, decision, or recall, so the definition is materially incomplete for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only hints at 'name' via global keying and at 'decision' via the mention of decisions in projects.db. The seven action enum values, layer enum, and most optional fields like role, status, outcome, and details are left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Universal Primitive: managing project-specific context and file mapping' identifies a clear resource and a general activity, but 'managing' is vague and does not convey the specific operation the tool performs. The action enum spans seven distinct behaviors like init, archive, and recall, yet the description does not summarize what the tool actually does at a callable level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the sibling tools think, dream, forget, or evolve, nor does it explain when to choose one action over another. The statement that projects are global is a scoping fact, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Universal Primitive: routing thoughts to correct memory layers based on importance and content.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| layer | No | auto | |
| user_id | No | default | |
| wiki_type | No | ||
| wiki_title | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only offers the abstract notion of 'routing'. It does not say whether this persists data, how layers are chosen, what side effects occur, or what the agent should expect when calling it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and compact, but the prefix 'Universal Primitive' adds little value and the rest is abstract rather than information-dense. It is not bloated, yet it does not use its brevity to deliver clarifying detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A single conceptual sentence is insufficient for a tool with 5 parameters, no parameter descriptions, and no annotations. The agent lacks enough information to correctly populate fields like `user_id`, `wiki_type`, and `wiki_title`, or to know the exact behavior of the `auto` layer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds only a loose connection between 'thoughts' and `text` and between 'memory layers' and `layer`. It does not explain `user_id`, `wiki_type`, `wiki_title`, or how importance/content maps to the `layer` enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific action ('routing thoughts') and a resource ('memory layers'), adding selection criteria ('based on importance and content'). It is clear enough as a high-level purpose, though it does not explicitly distinguish itself from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus dream, forget, evolve, or project. Calling it a 'Universal Primitive' only weakly implies general applicability, but no conditions, exclusions, or alternative selection rules are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.9.0memory_hookv1.8.0dreamevolveforgetmemory_api_keymemory_backupmemory_cleanupmemory_contextmemory_context_injectmemory_datamemory_episode_getmemory_episode_listmemory_episode_recallmemory_episode_savememory_forgetmemory_graph_addmemory_graph_edgesmemory_graph_nodesmemory_graph_querymemory_lucidity_purgememory_recallmemory_remembermemory_sagamemory_searchmemory_session_endmemory_session_listmemory_session_startmemory_statsmemory_sync_replicaprojectthinkv1.4.0memory_api_keymemory_backupmemory_cleanupmemory_contextmemory_context_injectmemory_datamemory_episode_getmemory_episode_listmemory_episode_recallmemory_episode_savememory_forgetmemory_graph_addmemory_graph_edgesmemory_graph_nodesmemory_graph_querymemory_lucidity_purgememory_recallmemory_remembermemory_sagamemory_searchmemory_session_endmemory_session_listmemory_session_startmemory_statsmemory_sync_replicaEach tool has a different core function—event ingestion, thought routing, search, forgetting, personality update, project context—but memory_hook and think both serve as write/ingestion paths, making it unclear which to use for a new piece of information. The one-line 'Universal Primitive' descriptions don't clarify these edge cases.
The set mixes a prefixed, compound name (memory_hook) with five bare metaphorical verbs (think, evolve, dream, forget, project), with no consistent verb_noun or domain convention. 'project' is also ambiguous as a noun or verb, further weakening the pattern.
Six tools is a reasonable size for a memory service, and each addresses a broad concern such as ingestion, retrieval, forgetting, personality evolution, or project context. The count is not bloated, though the overlap between think and memory_hook makes the set feel slightly less refined.
The surface covers writing (think/memory_hook), searching (dream), and deleting (forget), but there is no explicit update, direct retrieval by identifier, listing, or memory inspection across layers. This will force agents to use awkward workarounds like forget-then-write to alter existing memories.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Persistent memory for AI agents. EU-hosted, privacy-first, hybrid recall, contradiction detection.
Universal memory for AI agents and tools. Save, organize and search context anywhere.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Cipher208/a-memory'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
