Skip to main content
Glama
ricoaiproject-cmd

engram-global

by ricoaiproject-cmd
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

日本語版 → engram

engram — Human-like memory for AI agents (MCP server)

Persistent memory shared by Claude Code, Codex, and Antigravity (Gemini CLI). The more a memory is used, the easier it is to recall; unused memories sink but never disappear — the same dynamics as human memory.

This is the international edition: all documentation, the setup wizard, CLI messages, and agent-facing instructions are in English, and the default embedding model is intfloat/multilingual-e5-small (100+ languages, ~470 MB download) — so your memories themselves can be written in English or almost any other language. A fully Japanese edition tuned for Japanese (Ruri-v3 embeddings) lives at engram.

Quick start

Option 1: one-line install

Windows (PowerShell):

irm https://raw.githubusercontent.com/ricoaiproject-cmd/engram-global/main/install.ps1 | iex

macOS / Linux:

curl -LsSf https://raw.githubusercontent.com/ricoaiproject-cmd/engram-global/main/install.sh | sh

This single line installs uv, installs engram, and runs the setup wizard. (macOS: git is required — run xcode-select --install first if you don't have it.)

Option 2: manual install in three commands

Windows (PowerShell):

# 1. Install uv (skip if you already have it)
irm https://astral.sh/uv/install.ps1 | iex

# 2. Install engram
uv tool install --python 3.12 git+https://github.com/ricoaiproject-cmd/engram-global.git

# 3. Run the setup wizard
engram setup

macOS / Linux:

# 1. Install uv (skip if you already have it)
curl -LsSf https://astral.sh/uv/install.sh | sh

# 2. Install engram (force a uv-managed Python — see note below)
UV_PYTHON_PREFERENCE=only-managed uv tool install --python 3.12 git+https://github.com/ricoaiproject-cmd/engram-global.git

# 3. Run the setup wizard
engram setup

Why a uv-managed Python? engram needs a Python whose SQLite supports loadable extensions (for sqlite-vec). uv-managed Python provides this; system / python.org builds on macOS do not, and uv would otherwise prefer them when present — hence UV_PYTHON_PREFERENCE=only-managed (install.sh sets it for you). engram doctor has a check row for this.

The setup wizard automatically:

  • creates the config file (~/.engram/config.toml)

  • initializes the memory folder

  • downloads the embedding model (first run only, ~470 MB)

  • registers engram with Claude Code / Codex / Antigravity

  • registers the hooks for auto-encoding and proactive recall (Claude Code)

Related MCP server: cell-mem

After installation

Just talk to your agent

Your agent performs every engram operation on its own. You simply have normal conversations, and memories accumulate and get used automatically.

Take the onboarding interview first (recommended)

Ask your agent:

Read ~/.engram/ONBOARDING.md and interview me.

Seeding your working style, preferences, and background makes the memory useful from day one.

Check your environment

engram doctor

Shows Python version, config file, model cache, embedding backend (ONNX / torch), install health (detects leftover ~ngram-style remnants of a failed pip reinstall that break import engram), per-agent registration status as [OK] / [NG] / [--], FTS5 availability (whether SQLite's full-text search extension is loaded, since keyword search silently degrades without it), and a perf summary section that surfaces recent MCP tool-call and startup timings recorded to data_dir/perf/perf_log.jsonl (see below) so a "something feels slow" complaint can be diagnosed from data rather than guesswork.

Re-run setup (e.g. after installing a new agent)

engram setup

Safe to run any number of times (idempotent). Only unregistered agents are added.

Choose which agents to register

Even with multiple agents installed, you can connect engram to just the ones you want.

# Register with Claude Code only
engram setup --agents claude

# Register with both Claude Code and Codex
engram setup --agents claude,codex

Valid names: claude / codex / gemini (antigravity is an alias for gemini). Without --agents, interactive mode lists the detected agents and lets you pick by number (Enter selects all); --non-interactive registers all detected agents as before.

Choosing a different embedding model

The engine is model-agnostic. Set embed_model (and, for prefix-style retrieval models, query_prefix / doc_prefix) in ~/.engram/config.toml, then rebuild the index:

# Example: a small English-only model (no prefixes)
embed_model = "sentence-transformers/all-MiniLM-L6-v2"
query_prefix = ""
doc_prefix = ""
engram reindex       # re-embed all memories with the new model
engram export-onnx   # optional: regenerate the ONNX fast path

Note: the built-in mean pooling matches models such as MiniLM, E5, and Ruri; CLS-pooling models (e.g. bge) are not supported by the ONNX path.

Faster startup with ONNX

Since v0.11, engram setup (which the one-line installer runs for you) exports the model to ONNX automatically, so no manual step is needed — it is skipped when already exported (idempotent). Use the manual command only when you want to re-export, e.g. after switching embedding models:

engram export-onnx

This converts the embedding model to ONNX (no extra dependencies — the already-installed torch does the one-time conversion) and the server starts using it automatically (embed_backend=auto). Startup drops from 12–24 s (torch import) to ~2 s, and no MCP client timeout tuning is needed anymore.

Safety: the export verifies that the ONNX embeddings match the torch path on a set of sample texts (min cosine ≥ 0.999, including a long text that crosses the sliding-window boundary of ModernBERT-based models) and refuses to install a drifted model — a silently drifted embedding space would corrupt recall against your existing index.db.

embed_backend in config.toml (or ENGRAM_EMBED_BACKEND) selects the runtime: auto (default; ONNX if exported, else torch), onnx (forced; errors if not exported), torch (forced fallback).

Startup mode (ENGRAM_PRELOAD)

The default is auto (v0.10.0+): if the ONNX model has been exported, engram picks background (handshake responds immediately); on the torch fallback it picks blocking. No tuning is normally needed, and clients whose MCP startup timeout settings have no effect (seen in the wild: Codex Desktop 26.707) connect out of the box.

Value

Behavior

auto (default)

background if the ONNX model is exported, else blocking.

blocking

Load the model on the main thread before answering the handshake. Every recall after connect responds instantly. On the torch path this takes ~12–24 s warm / 50+ s cold, so raise your client's MCP startup timeout to 120 s or more (for Claude Code: MCP_TIMEOUT=120000).

background

Respond to the handshake immediately and load the model in a background thread. Safe on the ONNX path (the first tool call just waits a few seconds; measured ~5 s even off the main thread). Not recommended on the torch path: on Windows, importing torch on a non-main thread while the asyncio event loop is running is pathologically slow (measured ~184 s vs ~20 s on the main thread), so the first recall can exceed the client's tool timeout.

off

No preload; the model loads lazily on the first tool call.

If engram fails to connect at startup on the torch fallback, raise the client's MCP startup timeout (for Claude Code: MCP_TIMEOUT=120000) or run engram export-onnx, rather than forcing background — on torch that only converts a visible startup timeout into a 3-minute first recall.

Multiple processes and memory (ENGRAM_IDLE_UNLOAD_SEC) (v0.12.0+)

MCP clients do not necessarily start just one engram process. Seen in the wild: Codex Desktop (26.810) spawns one stdio MCP process per execution host and leaves them running afterwards, so the ~1.1 GB ONNX model piles up once per process — on a 16 GB-class PC free RAM runs out and the whole machine starts stuttering (four simultaneous processes observed on a real machine). v0.12.0 adds a two-part defense:

  1. Preload suppression at Codex registration — engram setup writes ENGRAM_PRELOAD = "off" into the engram block of ~/.codex/config.toml (existing users get it appended just by re-running setup; a manually set value is left untouched). Processes that never use a tool no longer load the model at all.

  2. Idle unload — if no tool is called for ENGRAM_IDLE_UNLOAD_SEC seconds (default 600 = 10 minutes), the model is released from memory. Even when a process that did use tools lingers, the memory comes back later. The model reloads automatically on the next tool call (a few seconds on ONNX) and no memories are lost. Set 0 to disable. ONNX path only (the torch path is excluded because of its slow-reload pathology).

More like real memory (new in v0.3)

Auto-encoding — sessions become memories by themselves

When a Claude Code session ends, a hook summarizes the conversation and saves it as an episode memory (engram setup registers the hook for you). Even if the agent forgets to call remember, "what we did yesterday" is preserved. Disable with auto_encode = false in config.toml.

Proactive recall — memory speaks up on its own

Every time you say something, a hook runs a lightweight search (a fast path that never loads the embedding model) for related memories. The mode is set by surface_mode in config.toml:

Mode

Behavior

active (default)

Actually injects strongly related memories into the agent's context

shadow

Injects nothing; logs "this is what I would have surfaced" (for observation and tuning)

off

Does nothing

The log lives at ~/.engram/surface/surface_log.jsonl. If unrelated memories keep surfacing, raise surface_min_relevance or switch to shadow to observe via the log only. Use engram surface "some text" to check manually what would surface.

Tuning parameters: surface_threshold (score threshold, default 0.45) / surface_min_relevance (relevance floor, default 0.25 — a gate that keeps even important memories from surfacing when they are unrelated to what you said) / surface_max_items (max items per prompt, default 2).

Memory rooms — separating work and personal contexts

Every memory carries a room label. Map folders to rooms in config.toml and the room is resolved automatically from the working directory:

[room_paths]
'C:/Users/you/work-projects' = 'work'
'C:/Users/you/personal' = 'personal'

  • Unmapped folders and pre-existing memories are all common

  • recall searches only "current room + common" (room="*" searches across all rooms)

  • Auto-encoding and proactive recall respect rooms too, so work memories never leak into personal contexts (and vice versa)

Sharing memories across machines

The Markdown store can live on a synced folder (e.g. a cloud drive) shared by several machines, but index.db is per-machine and local — so a memory written on one machine isn't searchable on another until that machine indexes it. The MCP server checks this at startup via startup_index_check in config.toml: auto (default) reindexes when it detects a markdown/index mismatch, warn logs a notice, off disables it. You can also run engram reindex any time.

How the memory works

Core design

Embeddings (where a memory sits in meaning-space) stay fixed; a separate axis — activation — modulates search ranking. Meaning = where it is, activation = how easily it comes to mind.

The same properties as human memory

  • The more you use it, the easier it is to recall — ACT-R activation model; every use by the agent reinforces it automatically

  • Unused memories sink but never disappear — power-law decay; deep recall can always reach them through associative links

  • Memories from striking contexts are engraved deeply — initial encoding boost by importance + slower decay = flashbulb memory

  • Corrected mistakes are engraved deepest of all — the correct tool records the error together with the fix = hypercorrection effect

Memory dynamics in brief

  • Activation: B = ln(Σ w_j·(now−t_j)^(−d_i)), normalized to 0..1 with a sigmoid; computed on the fly from the access log

  • d_i = clamp(0.5 − 0.2·(imp−5)/5, 0.3, 0.6) — higher importance forgets slower

  • create event weight 1 + 2·(imp/10) — critical memories start strong

  • merely recalled: weight 0.3 / actually useful (reinforce): weight 1.0×strength

  • Memories reinforced together get co_recall links (Hebbian learning), growing an associative network that deep recall's spreading activation can traverse

Search

Vector neighbors (sentence-transformers embeddings) + BM25 full-text search merged with RRF, then re-ranked by 0.6·relevance + 0.25·activation + 0.15·importance.

Hybrid recall: exact tokens no longer sink

Candidate relevance blends the two search paths instead of collapsing FTS hits onto the vector similarity scale: vector hits keep their cosine similarity, and FTS hits get a lexical relevance 1 - exp(bm25) derived directly from BM25 (0 for bm25 >= 0). When an id is hit by both, the higher of the two wins. Rare, decisive lexical matches — memory IDs, file paths, error codes, other exact tokens — push bm25 deep negative and surface lex near 1.0, clearing the narrow band into which dense-retriever cosine similarities tend to compress (with the Japanese model Ruri-v3, for example, 0.8–0.87). Previously, FTS-only hits were assigned the minimum vector similarity among the candidate pool, which buried exact-match results at the bottom of the ranking even when they were the obviously correct answer.

Short queries are covered too (v0.7.1). The FTS5 trigram tokenizer cannot index terms shorter than 3 characters, so 2-character terms (common in CJK text) used to be invisible to lexical search, and mixed queries containing any short token returned zero rows because of the implicit AND. The MATCH expression is now built from tokens of 3+ characters only, and when no such token exists the search falls back to LIKE substring matching with an IDF-based pseudo score (lex = N/(N+df): rarer terms score higher).

Memory types

type

Contents

knowledge

Insights, solutions to problems, how to use tools

preference

The user's preferences, style, patterns in instructions

project

Goals, constraints, history, and background of the work

episode

A summary of what happened in a session

File layout

~/.engram/
  config.toml        Config file (generated by engram setup)
  index.db           SQLite index (rebuildable from Markdown via reindex)
  MEMORY_PROTOCOL.md Agent operating instructions (imported into each agent's instruction file)
  ONBOARDING.md      Initial interview script
  surface/           Proactive recall log and session state
  hooks.log          Hook activity log
  consolidation_state.json  Candidate-cluster count + last-nudge timestamp (consolidation nudge)
  perf/perf_log.jsonl       Timing log for MCP tool calls and startup (when perf_log = true)

<memories_dir>/      Source of truth: Markdown (opens and edits fine in Obsidian)
  knowledge/
  preferences/
  projects/
  episodes/YYYY/MM/
  _trash/

memories_dir defaults to ~/.engram/memories, but pointing it at a Google Drive or OneDrive synced folder gives you backup and multi-device sharing. The SQLite index always stays local, so there is no sync-conflict risk.

MCP tools

Tool

When to use

recall(query, mode, limit, type, room)

At task start. fast = normal / deep = explores associative links, cold tier, and episodes / exhaustive = relevance-only full scan, ignoring activation, to dig up sunk memories

remember(content, type, importance, tags, related_ids, room)

When you learn an insight, preference, context, or event. importance 1–10 scores how critical the context is

reinforce(ids, strength)

At task end, report which memories actually helped (the nutrient for consolidation)

correct(id, corrected_content, reason)

When a memory was wrong. Use this, not forget (engraves the mistake itself deeply)

link / forget / stats / reindex

Auxiliary operations

consolidation_candidates / mark_consolidated

Consolidation (below)

Consolidation (the sleep of the system)

Clusters old episode memories and distills them into knowledge. The server only returns candidates; the summarization is done by the LLM (your agent). Example nightly run:

claude -p "Call engram's consolidation_candidates, summarize each cluster with remember (type=knowledge or project, related_ids=the source episodes), finish with mark_consolidated, then report stats."

Automatic nudge cycle

On top of the cron-style nightly run above, engram nudges the agent to consolidate on its own, without any scheduled job:

  1. SessionEnd counts how many consolidation-candidate clusters currently exist (via consolidation_candidates) and stores the count in data_dir/consolidation_state.json.

  2. UserPromptSubmit (the same lightweight hook that powers proactive recall) checks that state on the next session and, if enough clusters have piled up and enough time has passed since the last nudge, injects an additionalContext message asking the agent to run consolidation_candidates → remember → mark_consolidated at a natural pause in the conversation. The nudge fires even when surface_mode = "off" — it is independent of proactive recall.

Controlled by three settings (in config.toml or as ENGRAM_* environment variables):

Setting

Default

Meaning

consolidate_nudge

true

Master switch for the nudge cycle

consolidate_nudge_min_clusters

3

Minimum candidate clusters before nudging

consolidate_nudge_interval_days

7.0

Minimum time between nudges

For developers

Setting up to develop in this repository (run at the repo root):

# Virtual env (for development; distribution uses uv tool install)
python -m venv "$env:USERPROFILE\.engram\venv"
& "$env:USERPROFILE\.engram\venv\Scripts\python.exe" -m pip install -e ".[dev]"

Tests and verification

$py = "$env:USERPROFILE\.engram\venv\Scripts\python.exe"

& $py -m pytest                          # all tests
& $py -m pytest tests\test_setup.py -q   # setup logic only
& $py scripts\simulate.py                # simulate access patterns (30 days)
& $py scripts\check_mcp_e2e.py           # MCP end-to-end check

Diagnostics / CLI (for manual checks)

$engram = "$env:USERPROFILE\.engram\venv\Scripts\engram.exe"

& $engram doctor
& $engram remember "content" --type knowledge --importance 7
& $engram recall "query" --deep
& $engram surface "utterance text"
& $engram stats

Project structure

src/engram/
  config.py        Settings (defaults < config.toml < env vars) + room resolution
  engine.py        The memory engine
  store.py         Markdown source-of-truth store
  db.py            SQLite index (sqlite-vec + FTS5)
  dynamics.py      ACT-R activation model
  embedder.py      RuriEmbedder / FakeEmbedder
  server.py        MCP server (stdio)
  cli.py           CLI entry point
  setup.py         Setup wizard & doctor & hook registration
  hooks.py         Hook entry points (auto-encoding / proactive recall)
  transcript.py    Deterministic transcript summarization (auto-encoding)
  surface.py       Lightweight search path for proactive recall (no model)
  templates/       MEMORY_PROTOCOL.md / ONBOARDING.md
tests/
  test_setup.py    Setup pure-logic tests
  test_config.py   Settings precedence tests
  test_store.py    Markdown store tests
  test_db.py       DB operation tests
  test_engine.py   Engine tests
  test_room.py     Memory room tests
  test_surface.py  Proactive recall tests
  test_transcript.py  Transcript summarization tests
  test_hooks.py    Hook and hook-registration tests
  test_integration.py  Integration tests

Troubleshooting

Codex says engram is enabled but the connection times out on startup

On the torch fallback path, engram loads the embedding model (plus checks the memories folder) on every startup, which can take longer than Codex's default 30-second MCP startup timeout — especially right after a reboot, during antivirus scans, or when the memories folder lives on a cloud-synced drive (Google Drive, OneDrive, etc.). Your memories are fine; only the initial connection is timing out. (Running engram export-onnx once largely eliminates this — startup drops to ~2 s.)

Newer versions of engram setup write a longer startup timeout automatically. If you registered with an older version, either re-run engram setup --agents codex, or add one line to the engram block in ~/.codex/config.toml yourself:

[mcp_servers.engram]
command = "..."                # leave as is
startup_timeout_sec = 120.0    # add this line

Then fully restart Codex (quit and relaunch, not just close the window).

Update

Re-run the same one-line installer to overwrite with the latest version:

irm https://raw.githubusercontent.com/ricoaiproject-cmd/engram-global/main/install.ps1 | iex

macOS / Linux:

curl -LsSf https://raw.githubusercontent.com/ricoaiproject-cmd/engram-global/main/install.sh | sh

uv tool upgrade engram does the same (package update only).

  • The one-line installer also re-runs setup afterwards, so environments that never exported the ONNX model get converted automatically and startup drops to ~2 s (skipped when already exported)

  • Your memories and config (~/.engram and the memories folder) are kept — nothing is deleted

  • After updating, restart each agent that uses engram (Claude Code, etc.) so the MCP server reconnects

Uninstall

# 1. Remove the registration from each agent
claude mcp remove engram

# 1b. Manually remove the engram entries from hooks in ~/.claude/settings.json
#     (the "engram hook ..." commands under SessionEnd / UserPromptSubmit)
# 2. Manually remove the engram block from ~/.claude/CLAUDE.md
# 3. Manually remove the [mcp_servers.engram] block from ~/.codex/config.toml
# 4. Manually remove the engram entry from ~/.gemini/config/mcp_config.json

# 5. Uninstall engram itself
uv tool uninstall engram

# 6. To delete the data as well (memories, config, model cache)
Remove-Item -Recurse -Force "$env:USERPROFILE\.engram"
Remove-Item -Recurse -Force "$env:USERPROFILE\.cache\huggingface\hub\models--intfloat--multilingual-e5-small*"

On macOS / Linux, steps 5–6 are:

uv tool uninstall engram
rm -rf ~/.engram
rm -rf ~/.cache/huggingface/hub/models--intfloat--multilingual-e5-small*

Available Tools

11 tools
consolidation_candidatesA

Return clusters of episode memories that are candidates for consolidation.

Call this before ending a session (at session end), to surface clusters of similar older episodes that are candidates for compressing into knowledge or project memories. The LLM generates the summary, then calls mark_consolidated to complete the consolidation.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.6/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden. It clarifies that the tool only returns candidates and does not perform the actual consolidation, and it names the follow-up action (mark_consolidated), which adds valuable behavioral context beyond a simple 'return clusters' statement.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three concise sentences: purpose, timing, and next-step workflow. Every sentence earns its place with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-param tool with no output schema, the description adequately covers purpose, usage, and subsequent actions. It could describe the exact return format in more detail, but the essential context is present and the workflow is clear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema is trivially complete. The description adds no parameter semantics because none are needed; the baseline for zero-parameter tools is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns clusters of episode memories for consolidation, using a specific verb and resource. It distinguishes itself from sibling tools like mark_consolidated and skill_candidates by focusing on candidate generation for consolidation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to call before ending a session and outlines the workflow with mark_consolidated. This provides clear when-to-use context and distinguishes from alternatives by describing the intended place in the consolidation process.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

correctA

Use this instead of forget when a memory turns out to be wrong.

Demotes the old memory to superseded (corrected) and creates a new memory that records the reason for the correction. Explicitly recording the mistake prevents the same error from being repeated (a hypercorrection effect).

ParametersJSON Schema
NameRequiredDescriptionDefault
idYes
reasonYes
sourceNounknown
corrected_contentYes

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the key behavioral effects: demoting the old memory to superseded and creating a new memory with the reason for correction. It also explains the hypercorrection effect, which adds useful context. However, it does not mention whether the old memory becomes unavailable or any potential side effects, leaving some minor gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise and front-loaded, starting with a clear directive and then explaining the behavioral rationale. Every sentence adds value, with no redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given it has no output schema or annotations, the description adequately covers the core workflow: when to use, what happens to the old and new memory, and why this is beneficial. It could be improved by mentioning how to obtain the 'id' or what 'source' is for, but overall it is complete enough for an agent to select and invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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. It indirectly explains 'corrected_content' and 'reason' through the narrative, and 'id' is inferable as the memory to correct. However, 'source' is never mentioned, and no explicit parameter mapping is given. This provides moderate help beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: to correct a memory that turns out to be wrong, demoting the old memory and creating a new one with the correction. It uses a specific verb ('correct') and contrasts with the sibling tool 'forget', making its unique role unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly tells when to use this tool: 'Use this instead of forget when a memory turns out to be wrong.' This names the alternative (forget) and provides a clear decision rule, giving the agent unambiguous guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

forgetA

Soft-delete a memory (move it to trash).

Call this when a memory is no longer needed and you want it excluded from search. This moves the memory to trash rather than physically deleting it, so it can be restored if deleted by mistake. If you want to correct an error rather than remove a memory, use correct instead of forget.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYes

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Since no annotations are provided, the description carries the full burden. It discloses that the operation is a soft delete, moves memory to trash, and can be restored, which is meaningful behavioral context. However, it omits potential side effects (e.g., on links or consolidation status) and what the API returns.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with no filler. The first sentence states the action, the second gives the usage context, and the third provides an alternative. It is well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the key aspects: purpose, usage context, soft-delete behavior, and restoration. It lacks parameter-level guidance and return expectations, but these are less critical for this simple action.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one 'id' parameter with no description (0% coverage). The description never mentions 'id' or clarifies that it is the identifier of the memory to forget, leaving the agent to infer this from the tool name and schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('soft-delete'), the target ('a memory'), and the mechanism ('move it to trash'). It explicitly distinguishes itself from the sibling tool 'correct' by noting when each should be used.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear 'when to use' condition: 'when a memory is no longer needed and you want it excluded from search'. It also explicitly warns against using it for corrections and directs the agent to 'correct' instead, providing an alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mark_consolidatedA

Record that a consolidation has been completed.

Call this after the LLM has summarized a cluster surfaced by consolidation_candidates and created the new memory via remember. The original episodes are demoted to cold (long-term storage) and linked to the new memory via a derived_from link. Also use this tool to demote the target episodes to cold after acting on a skill_candidates cluster.

ParametersJSON Schema
NameRequiredDescriptionDefault
episode_idsYes
new_memory_idYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of disclosing behavioral traits. It clearly states side effects: 'The original episodes are demoted to cold (long-term storage) and linked to the new memory via a derived_from link.' This is a meaningful behavioral disclosure. It doesn't mention reversibility or permissions, but for the scope of this tool, the key side effects are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is slightly longer than ideal but each sentence serves a purpose: stating the main function, the recommended invocation sequence, the side effects, and an additional use case. It is front-loaded with the primary action and structured logically, making it easy to parse. A few words could be trimmed, but overall it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two parameters, no annotations, and no output schema, the description is fairly complete. It covers the main workflow, side effects, and an alternative usage. The only notable gap is that the skill_candidates scenario implies a second use but does not clarify what new_memory_id should be in that context, leaving a minor ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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. It does by contextualizing the parameters: episode_ids are the 'original episodes' being demoted, and new_memory_id refers to the memory created via 'remember'. This adds meaning beyond the raw schema (array of strings, string) and helps the agent understand what values to provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's primary function ('Record that a consolidation has been completed') and elaborates on the specific action of demoting original episodes to cold storage and linking to a new memory. It references consolidation_candidates and skill_candidates, which distinguishes it from sibling tools by clarifying its role in the consolidation workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides when to use this tool: 'Call this after the LLM has summarized a cluster surfaced by consolidation_candidates and created the new memory via remember.' It also mentions an alternative use case with skill_candidates, giving clear context for invocation. This directly guides the agent on the correct sequence.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

recallA

Search for and return memories.

Always call this at the start of a task. It surfaces relevant past knowledge, preferences, and project context. mode="fast" searches only tier=hot, quickly. If the score is low it automatically falls back to deep. mode="deep" searches more broadly, including cold/superseded/episode memories, and follows associative links. mode="exhaustive" ignores activation and ranks purely by relevance across every memory. Use this as a last resort to dig up a "sunk" memory you're sure you recorded but that isn't surfacing under fast/deep. You normally don't need to pass room (it searches only the current room plus common). room="*" searches across all rooms — use it only when necessary, since it breaks the separation between work and personal contexts.

ParametersJSON Schema
NameRequiredDescriptionDefault
modeNofast
roomNo
typeNo
limitNo
queryYes
record_hitsNo

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully carries the transparency burden. It discloses mode-specific behavior (hot tier, fallback to deep, associative links, exhaustive ranking) and room scoping implications. However, it does not mention the side effect of record_hits (default true) or any potential persistence behavior, which is a notable gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a front-loaded one-sentence purpose, a usage directive, and clear bullet-like mode explanations. It is somewhat lengthy but every sentence contributes value, and the structure aids readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with multiple modes and no output schema, the description covers the essential context: when to use it, mode behaviors, room cautions, and fallback mechanisms. It is not fully complete because it omits explanation of `type` and `record_hits`, and does not disclose potential side effects, but overall it provides solid contextual guidance.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameter descriptions (0% coverage), so the description must compensate. It does so thoroughly for `mode` and `room`, but leaves `type`, `limit`, and `record_hits` unexplained. `query` and `limit` are self-evident, but `type` and `record_hits` remain ambiguous, leaving the compensation incomplete.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Search for and return memories,' which is a specific verb+resource pairing that clearly distinguishes this from sibling tools like forget or remember. It further elaborates on mode-specific search scope, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly instructs to 'Always call this at the start of a task' and provides mode-selection guidance (fast vs. deep vs. exhaustive) with clear 'last resort' and 'only when necessary' language. It doesn't explicitly contrast with alternatives or state when not to use it, but the usage context is well defined.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reindexA

Rebuild the DB index from the Markdown files.

Call this after manually editing files, or when you suspect the DB is corrupted. Only memories that differ are re-embedded, so this is faster than a full rebuild.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the tool rebuilds the index from files and that it is incremental, but does not mention potential side effects or whether it is destructive. Still, the key behavioral traits (source, incremental nature, speed) are covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no wasted words. The purpose, usage trigger, and performance characteristic are front-loaded and clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description fully covers the necessary context: what it does, when to call it, and a key performance trait. Nothing important is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so parameter semantics are irrelevant. Per calibration rules, the baseline is 4 for no parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Rebuild the DB index from the Markdown files' with a specific verb and resource, clearly distinguishing this from sibling tools like remember, recall, and forget.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Call this after manually editing files, or when you suspect the DB is corrupted.' It also contrasts with a full rebuild by noting only differing memories are re-embedded, implying when this is the right choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reinforceA

Report which memories actually turned out to be useful.

When a task finishes, report the ids of memories that actually helped. Reinforced memories are more likely to surface near the top on the next recall. Passing multiple ids at once links those memories together via a co-occurrence link (Hebbian learning). strength ranges 0.1-3.0 and controls how strong the reinforcement is.

ParametersJSON Schema
NameRequiredDescriptionDefault
idsYes
strengthNo

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden of behavioral disclosure. It explains the effect on recall ranking, the Hebbian co-occurrence link when passing multiple ids, and the strength range. It omits reversibility and error behavior, but covers the core side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and each sentence adds information. However, the first two sentences are slightly redundant ('Report which memories actually turned out to be useful' vs. 'report the ids of memories that actually helped'), costing it a perfect score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple 2-parameter tool with no output schema and no annotations, this description covers purpose, usage timing, parameter meanings, and behavioral consequences. It does not mention return values or error conditions, but these are not critical for this tool's use case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must explain parameters. It does: 'ids' are memory ids that helped, and 'strength' is given a numeric range (0.1-3.0) and its controlling effect. The multi-id linking behavior adds semantic depth beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action and resource: 'Report which memories actually turned out to be useful.' It clearly distinguishes reinforce from sibling tools like recall (retrieval) and remember (encoding) by focusing on post-task feedback and ranking impact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states when to use the tool ('When a task finishes') and gives context for multi-id usage (co-occurrence linking). It does not name alternatives or exclusions, but the timing condition is clear and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rememberA

Save a new memory.

Call this whenever you discover something important during a task (a fact, a preference, project status, an event). Self-score importance from 1-10 based on how significant it is in context. If a sufficiently similar existing memory is found (cosine similarity >= dup_threshold=0.95), it is reinforced as a duplicate and returned instead. You normally don't need to pass room (it's inferred automatically from the working directory). Only pass room="common" explicitly for universal memories that apply across every context.

ParametersJSON Schema
NameRequiredDescriptionDefault
roomNo
tagsNo
typeYes
sourceNounknown
contentYes
importanceYes
related_idsNo

TDQS

A4.2/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond the basic 'save' operation by explaining duplicate handling (cosine similarity threshold and reinforcement), automatic room inference from the working directory, and the importance scoring scale. These are non-obvious behaviors that an agent needs to know.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph with five sentences, each earning its place. It is front-loaded with the core action, then provides usage guidance, duplicate behavior, and room handling without any redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 7 parameters, no annotations, and no output schema, the description should be more thorough. It covers duplicate logic, importance, and room, but leaves the required `type` parameter completely unexplained and does not describe the return format or what the tool returns when a new memory is saved versus a duplicate. This is a significant omission for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage, so the description must compensate. It adds meaning for `importance` ('from 1-10') and `room` (inferred automatically, only pass 'common' for universal memories), which is valuable. However, it does not explain the required `type` parameter or optional parameters like `tags`, `source`, and `related_ids`, leaving significant gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Save a new memory,' which is a specific verb+resource statement that clearly distinguishes this tool from siblings like 'forget' and 'recall'. It also clarifies the intent by stating it is for storing discovered facts, preferences, project status, or events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to call the tool: 'Call this whenever you discover something important during a task.' It also gives specific parameter-usage guidance for `room`, explaining when to pass it explicitly and when to omit it. However, it does not explicitly name alternative tools or say when NOT to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

skill_candidatesA

Return clusters of episode memories that are candidates for extraction into a reusable skill.

When 3 or more (default; the "three-times rule") episodes recording the same shape of work (procedure) form a similar cluster, use this as input for judging whether that procedure is worth extracting into a reusable skill (a how-to document — a SKILL.md for Claude Code, etc.). Unlike consolidation_candidates, there is no age filter here (recently repeated work is exactly the target). Even when a cluster is found, always propose turning it into a skill to the user and get their approval first. Never create or deploy a skill on your own. Once the decision (adopt or pass) is made, record the reasoning via remember(type=knowledge), then clean up the original episodes with mark_consolidated(episode_ids, new_memory_id).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does this thoroughly: it states that the tool only returns candidates, explicitly instructs to never create/deploy a skill without user approval, and describes the post-decision cleanup steps. This gives the agent a clear understanding of side effects and required permissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise yet comprehensive, structured in three short paragraphs. The first sentence immediately states the primary purpose, followed by usage context and a clear 'Even when a cluster is found...' caveat. Every sentence adds value, and the length is appropriate for the complexity of the tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description provides a high-level of what is returned ('clusters of episode memories') but does not detail the exact structure or fields of the returned clusters. However, it covers the full workflow, prerequisites, and the 'three-times rule,' making it complete enough for an agent to decide when to invoke it and what to do next. The lack of return structure detail slightly prevents a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema coverage is trivially 100% (empty schema). Per the baseline for 0 params, a score of 4 is appropriate. The description does not need to explain parameters since none exist, but it also doesn't add any extra nuance beyond schema, hence not a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Return clusters of episode memories that are candidates for extraction into a reusable skill.' It clearly distinguishes itself from the sibling tool consolidation_candidates by explicitly stating 'Unlike consolidation_candidates, there is no age filter here.' This makes the purpose unambiguous and differentiated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use criteria: when 3 or more episodes (the 'three-times rule') form a similar cluster. It also contrasts with the alternative tool, noting the age-filter difference, and outlines the subsequent workflow (propose to user, get approval, record reasoning, clean up episodes). This gives clear guidance for selecting this tool over siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

statsA

Return memory statistics.

Shows memory counts (by type and tier), the number of access events, the number of links, and so on.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It reveals that the tool returns counts and events, implying a read-only nature. However, it does not explicitly state that no state is modified, nor does it mention any potential side effects or data freshness. The inclusion of 'and so on' also leaves ambiguity about the full set of statistics returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, with the first clearly stating the tool's purpose and the second providing useful detail. No words are wasted, and the structure is front-loaded with the main action. It is appropriately concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description should fully specify what is returned. It lists several concrete examples but weakens it with 'and so on,' leaving room for ambiguity. For a simple no-parameter tool, this is adequate but not complete enough to be fully self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, and the schema reflects this completely (100% coverage). The description therefore needs no parameter-specific semantics. The baseline for a zero-parameter tool is 4, which is appropriate here since the description adds context about the nature of the output without needing to explain parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Return memory statistics' with a specific verb and resource, and then elaborates on the types of statistics (counts by type and tier, access events, links). This distinguishes it from sibling tools like forget or remember, which perform actions rather than reporting information.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended usage is implied: use this tool when you need memory statistics. However, there is no explicit guidance about when to use this tool versus alternatives like consolidation_candidates or skill_candidates, nor any exclusion criteria. The context suggests it for general stats, but the description could be more direct about its role among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 11 tool updatesv0.1.0
    • First observedconsolidation_candidates
    • First observedcorrect
    • First observedforget
    • First observedlink
    • First observedmark_consolidated
    • First observedrecall
    • First observedreindex
    • First observedreinforce
    • First observedremember
    • First observedskill_candidates
    • First observedstats
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: remember saves, recall searches, forget soft-deletes, correct replaces erroneous memories, reinforce boosts relevance, link creates explicit connections, consolidation_candidates and skill_candidates surface different cluster types, mark_consolidated finalizes consolidation, reindex rebuilds the index, and stats reports metrics. Even the superficially similar candidates tools are well-differentiated by their described use cases.

Naming Consistency3/5

Naming uses a mix of simple verbs (remember, recall, forget, reinforce, correct, link, reindex), a noun (stats), and underscore-separated phrases (consolidation_candidates, skill_candidates, mark_consolidated). The convention is not uniform, but names are still readable and descriptive enough to infer their functions.

Tool Count5/5

With 11 tools, the server is well-scoped for a comprehensive memory management system. Each tool addresses a distinct lifecycle phase (creation, retrieval, correction, reinforcement, linking, consolidation, maintenance, and statistics), and none feel redundant or missing.

Completeness4/5

The tool surface covers the core memory lifecycle (create, read, soft-delete, correct, reinforce, link, consolidate, extract skills) plus maintenance and stats. Minor gaps exist, such as no direct update tool for editing a memory's content or a restore-from-trash operation, but these are workaroundable and the provided workflow is intentional.

Maintenance

ActivityActive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • mnemory

    fpytloun
    A
    license
    Not graded
    quality
    A
    maintenance
    Self-hosted MCP server giving AI agents persistent memory for personalization and context across conversations.
    277
    Apache 2.0

  • cell-mem

    Aether-liusiqi
    A
    license
    Not graded
    quality
    D
    maintenance
    An MCP server that provides AI agents with persistent, multi-layered memory inspired by the human brain, including consolidation, self-reflection, and generative replay.
    1
    MIT

  • clude-mcp

    Israeltheminer
    F
    license
    Not graded
    quality
    C
    maintenance
    A self-hosted MCP server that gives AI agents persistent, searchable memory with importance scoring, knowledge graphs, and autonomous memory consolidation.
    1
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ricoaiproject-cmd/engram-global'

If you have feedback or need assistance with the MCP directory API, please join our Discord server