Which integrations are available for this server?

Provides persistent, private memory for GitHub Copilot, enabling it to recall decisions, patterns, and debugging insights across sessions and projects.

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Myelin recall my architectural decisions from yesterday" 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.

Myelin

by et-do

Overview Schema Source Related Servers Discussions Admin

Python

Local

Neuromorphic long-term AI memory — brain-inspired persistent context for AI agents.

Related MCP server: Smriti

Why Myelin

The problem: Every AI agent conversation starts from scratch. Context is lost between sessions, across tools, across projects. Agents repeat mistakes, forget decisions, and can't build on prior work.

What Myelin does:

Persistent memory across sessions — decisions, patterns, and debugging insights survive after the chat window closes
Cross-agent context — Copilot, Claude, and Cursor share the same memory. What one agent learns, all agents can recall.
Cross-project knowledge — architectural patterns from project A inform decisions in project B
Self-organizing — auto-classifies memory types (decisions, procedures, events), auto-infers recall filters, auto-prunes stale knowledge
Private and local — all data stays on your machine (or your team's server). No API keys. No cloud dependency. No data leaving your network.
Gets better with use — frequently co-recalled memories strengthen their association (Hebbian learning). The more you use it, the better recall gets.
98.2% Recall@5 on LongMemEval — beats LLM-based systems using only local 22M-parameter models

Quick Start

Requirements: Python 3.11+ · ~500 MB disk (models download on first run) · No GPU · No API keys

Install

Option A — uv (recommended, no admin required):

macOS / Linux:

curl -LsSf https://astral.sh/uv/install.sh | sh
uv tool install myelin-mcp

Windows (PowerShell):

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
uv tool install myelin-mcp

Option B — pip:

# --user installs to ~/.local/bin (Linux/macOS) or %APPDATA%\Python\...\Scripts (Windows)
# No admin rights required
pip install --user myelin-mcp

NOTE

After installing, run myelin status once before opening VS Code. This downloads ~500 MB of embedding models and pre-warms them so your first tool call is instant. The MCP server starts without waiting for models, but the first store or recall will be slower if models haven't loaded yet. If myelin isn't found, your user bin dir isn't on $PATH. Add ~/.local/bin to your shell profile (Linux/macOS), or find the correct path with python -m site --user-scripts (Windows).

Configure your AI tool

Add Myelin as an MCP server.

VS Code — open mcp.json (Ctrl+Shift+P → MCP: Open User Configuration):

{
  "servers": {
    "myelin": {
      "command": "myelin",
      "args": ["serve"]
    }
  }
}

IMPORTANT

myelin not found by VS Code? MCP hosts launch in a clean environment and may not inherit your shell $PATH. Use the full path (e.g. ~/.local/bin/myelin on Linux/macOS) or switch to "command": "uvx" with "args": ["myelin-mcp", "serve"] — uvx resolves the tool location automatically.

Claude Desktop — add the same block to claude_desktop_config.json.

Verify

Restart VS Code (Ctrl+Shift+P → Developer: Reload Window).
Open Output panel (Ctrl+Shift+U) → MCP: myelin — you should see the server start and discover tools:

Click Configure Tools (filter icon in Chat input bar) to verify Myelin's tools are listed:

Ask your agent: "Check myelin status" — it should call the status tool and return memory counts.

Setup Guides

Myelin stores all data in a single directory (~/.myelin by default). How you deploy that directory determines the scope of memory.

Personal (Cross-Project)

Best for: Solo developers who want one memory across all projects and agents.

This is the default setup. Follow the Quick Start Install steps above — they set up user-level config by default.

All projects and agents share ~/.myelin/. Use project metadata when storing to keep work organized — just tell your agent:

"Store this as project=backend, scope=auth"

Recall can filter by project or search across everything.

Per-Repository

Best for: Teams who want memory scoped to a single repo, committed alongside the code.

1. Set MYELIN_DATA_DIR to a path inside the repo:

Create a .vscode/mcp.json in the repo:

{
  "servers": {
    "myelin": {
      "command": "myelin",
      "args": ["serve"],
      "env": {
        "MYELIN_DATA_DIR": "${workspaceFolder}/.myelin"
      }
    }
  }
}

TIP

Use"command": "uvx" with "args": ["myelin-mcp", "serve"] if myelin isn't on the PATH in your MCP host's environment.

2. Decide whether to commit the data:

Commit .myelin/ — the team shares accumulated knowledge (architectural decisions, conventions, debugging history). New contributors inherit project memory. Good for stable, curated knowledge.
Gitignore .myelin/ — each developer builds their own memory. Add .myelin/ to .gitignore. Good for personal workflow memory you don't want to share.

3. Add agent instructions (see Teaching Your Agent below).

Multi-Agent (Shared Instance, Isolated Namespaces)

Best for: Multiple trusted agents sharing one Myelin data directory, each working from its own memory pool.

Myelin filters recalls by agent_id at the database level — a recall with agent_id="copilot" will never return a memory stored with agent_id="ci-bot". The filter is unconditional once applied.

However, agent_id is not authenticated. The server accepts whatever value the caller supplies. Any agent — or user — that knows another agent's agent_id can read and write to that namespace. There is no credential, token, or OS-level enforcement preventing this.

This means agent_id is a namespace convention for cooperating agents, not an access-control boundary. It is appropriate when:

Agents are trusted (same team, same deployment)
The goal is preventing accidental cross-contamination between agent contexts
You are not trying to hide memories from a potentially adversarial caller

If hard isolation is a requirement, run separate Myelin instances pointing at separate data directories.

To keep agents in their own namespace, add a line to each agent's instructions file (.github/copilot-instructions.md or equivalent):

Always pass agent_id="copilot" on every myelin store and recall call.

Without this instruction, an agent may omit agent_id and write to the global namespace — visible to all callers regardless of agent_id.

The global namespace (no agent_id) is intentional for shared project context that every agent should see, such as architectural decisions and conventions.

# Scope a debug-recall diagnostic to one namespace
myelin debug-recall "auth approach" --agent-id copilot

Team / Cloud

Best for: Organizations that want shared memory across team members and CI environments.

Myelin itself is a local process — it reads/writes to a data directory. For team sharing, you point that directory at shared storage. This does not require deploying Myelin as a hosted service.

Option A: Shared network drive or mounted volume

Point MYELIN_DATA_DIR to a shared filesystem (NFS, SMB, EFS, GCS FUSE, etc.):

export MYELIN_DATA_DIR=/mnt/team-memory/myelin

SQLite uses WAL mode and file-level locking, which works on most network filesystems for light concurrency. For heavy concurrent writes, consider Option B.

Option B: Sync via export/import

Use the CLI to periodically export and import memory between environments:

# On one machine — export
myelin export team-memory.json

# On another machine — import
myelin import team-memory.json

This can be automated in CI (e.g., export after each deploy, import at dev environment setup).

Seeding from existing docs

Use myelin ingest to bulk-load existing documentation, notes, or wiki exports into memory:

myelin ingest ./docs/ --project myapp --source wiki
myelin ingest ./decisions/ --scope architecture --source adr

Markdown files with YAML frontmatter get their metadata (project, scope, tags, memory_type) automatically applied per file. JSON exports from other Myelin instances can also be ingested directly.

Option C: Shared server (future)

A dedicated Myelin server with HTTP transport is on the roadmap. For now, the export/import workflow covers most team use cases.

Teaching Your Agent

Connecting the MCP server gives your agent the ability to store and recall — but it won't use memory automatically unless you tell it to.

Agent Instructions

Add a .github/copilot-instructions.md (VS Code / Copilot) or equivalent instructions file to your project:

## Memory

You have access to a long-term memory system (Myelin) via MCP tools.

### When to Recall
- At the START of every task, recall relevant context about the current project,
  file, or problem domain.
- Before making architectural decisions, recall past decisions and their rationale.
- When debugging, recall similar past issues and their resolutions.

### When to Store
- After making significant decisions — record WHAT was decided and WHY.
- After resolving non-trivial bugs — record the symptoms, root cause, and fix.
- When discovering project conventions, patterns, or gotchas.
- After completing a meaningful feature — summarize the approach and trade-offs.

### How to Store Effectively
- Always include `project` metadata (e.g., project="myapp").
- Use `scope` to organize by domain (e.g., scope="auth", scope="database").
- Use `tags` for cross-cutting concerns (e.g., tags="performance,optimization").
- Use `memory_type` when it's clear: "semantic" for decisions/facts,
  "procedural" for how-to, "episodic" for events, "prospective" for plans.
- Be specific. "We use JWT RS256 because asymmetric keys let the API gateway
  verify without the signing secret" is better than "We use JWT."

### Maintenance
- After extended sessions (10+ stores), run `consolidate` to build the
  [semantic network](#consolidation-offline) — it improves recall by linking related entities.
- [Consolidation](#consolidation-offline) auto-triggers every 50 stores, but running it manually
  after a burst of activity gives immediate benefit.
- Periodically run `decay_sweep` to prune stale memories (90+ days idle,
  <2 accesses).

### What NOT to Store
- Trivial or ephemeral information (typo fixes, one-off commands).
- Exact code blocks — store the reasoning, not the implementation.
- Anything sensitive (secrets, credentials, PII).

Tips for Effective Memory

Use project consistently. It's the primary organizational axis. An agent working on "myapp" should always store with project="myapp" so recall can filter by project.
Pin critical context. Use pin_memory for things every session should know (system architecture, active conventions, team preferences). Pinned memories are prepended to every recall result via the Thalamus overlay.
Run consolidation periodically. myelin consolidate (or it auto-runs every 50 stores) builds the semantic network — entity relationships that improve recall quality over time.
Run decay periodically. myelin decay prunes memories that haven't been accessed in 90+ days with fewer than 2 accesses. Keeps the memory clean without manual curation.
Export before major changes. myelin export backup.json creates a full backup you can restore with myelin import.

Benchmark Results

LongMemEval_S — 500 questions, zero LLM calls

LongMemEval (ICLR 2025) tests long-term conversational memory: can the system find the right conversation session given a natural-language question? R@k measures whether any ground-truth session appears in the top-k results (binary hit).

Metric	Myelin	MemPalace (GPT-4o)
R@1	91.2%	—
R@3	98.0%	—
R@5	98.2%	96.6%
R@10	98.2%	—
NDCG@5	95.2%	—
LLM calls	0	requires GPT-4o

98.2% R@5 (491/500 questions) using only local models — no LLM calls. Exceeds MemPalace's 96.6% R@5 which relies on GPT-4o.

Per-Category Breakdown

Category	Questions	R@1	R@5
knowledge-update	78	97.4%	100.0%
single-session-assistant	56	100.0%	100.0%
single-session-user	70	88.6%	100.0%
multi-session	133	91.0%	98.5%
temporal-reasoning	133	90.2%	96.2%
single-session-preference	30	70.0%	93.3%

LoCoMo — 1,986 questions, 10 conversations

LoCoMo (Snap Research) tests memory over long conversations. Stricter metric: R@k = fraction of all evidence sessions found in top-k (not binary hit). Multi-evidence questions require retrieving multiple sessions simultaneously.

Metric	Myelin	MemPalace hybrid v5
R@5	88.9%	—
R@10	95.1%	88.9%
R@20	95.1%	—

Latency — 8-core CPU, no GPU

Operation	n	Mean	Min	Max	Notes
store	100	94ms	47ms	149ms	embed (15ms) + dedup check + gist + ChromaDB write
store	500	67ms	43ms	130ms	flat: HNSW dedup-query adds <5ms over 500 items
recall	100	142ms	94ms	171ms	3-probe pipeline: embed + HNSW + CE rerank
recall	500	130ms	116ms	153ms	flat retrieval scaling confirmed
recall	1000	134ms	104ms	173ms	still flat at 10× scale
recall + project filter	100	162ms	120ms	224ms	similar to unfiltered at n=100; benefits grow with n
recall + scope filter	100	149ms	76ms	188ms	similar to unfiltered at n=100; benefits grow with n
Hebbian + Thalamus overhead	100	+~10ms	—	—	seeded Hebbian (~125 pairs); SQLite WAL reads/writes

Retrieval scales flat with collection size. Recall averages 142ms at n=100, 130ms at n=500, and 134ms at n=1000 — all within the variance of each other. The bottleneck is fixed model inference: embedding the query (~15ms) and cross-encoder scoring the candidate pool (~60ms across 3 probes). HNSW index search adds <5ms at these scales. This means retrieval stays fast as memory grows — a user with 1000 memories pays the same latency as one with 100.

Store variance is high. The 47ms–149ms range reflects gist extraction cost, which varies with content length and semantic density. Short, single-topic memories hit the low end; anything requiring multi-chunk gists hits higher. Mean of ~80ms is well within the 500ms agent tool-call budget.

Filters add negligible overhead at small n. At n=100, project and scope filters show ~10–20ms higher means than unfiltered recall, but this is within measurement noise (stddev 24–38ms). Filter benefits appear at larger collection sizes where a filter can meaningfully reduce the cross-encoder candidate pool.

Methodology

LongMemEval: LongMemEval_S cleaned — 500 questions, 6 categories (ICLR 2025). Oracle mode, chunks deduplicated to sessions.
LoCoMo: 10 conversations, 1,986 QA pairs. R@k = fraction of evidence sessions found in top-k.
Latency: pytest-benchmark micro-timings, ephemeral ChromaDB, warm models, 8-core CPU, no GPU, n=100–1000 memories. Run uv run pytest tests/benchmarks/test_latency.py -p no:xdist --override-ini="addopts=" to reproduce.
Models: all-MiniLM-L6-v2 (22M params) + cross-encoder/ms-marco-MiniLM-L-6-v2 (22M params)
Hardware: 8-core CPU, no GPU
LLM calls: Zero in retrieval

How It Works

Core Concepts

Concept	Neuroscience	Myelin Equivalent
Cortical Region	Specialized brain areas for different domains	`project` — each project is a distinct neural territory
Engram Cluster	Co-active neurons forming a memory trace	`scope` — related memories (auth, billing) share a cluster
Memory System	Distinct encoding/retrieval strategies	`memory_type` — episodic, semantic, procedural, prospective
Association Fiber	White matter connecting co-active regions	Hebbian links — built from co-retrieval patterns
Gist Trace	Meaning and detail stored in parallel	Vector embedding (gist) + raw content (verbatim)
Sparse Code	Only 1-5% of neurons fire per stimulus	Chunking — each segment is a focused representation

Memory Systems

System	`memory_type`	What It Stores	Example
Episodic	`episodic`	Events with temporal context	"What happened when we deployed?"
Semantic	`semantic`	Decisions, facts, knowledge	"What did we decide for auth?"
Procedural	`procedural`	Habits, preferences, how-to	"How do we run migrations?"
Prospective	`prospective`	Future plans, recommendations	"What are the next steps?"

Pipeline Overview

STORE (fast, zero-LLM)              RECALL (multi-probe)

  content                              query
    │                                    │
    ▼                                    ▼
  Amygdala ─── reject noise          Query Planner ─── auto-infer filters
    │                                    │
    ▼                                    ▼
  Prefrontal ── auto-classify         Multi-probe (3 query variants)
    │                                    │
    ▼                                    ▼
  Chunking ──── pattern separation    Per-probe retrieval
    │                                    │ dual-path search + re-rank
    ▼                                    ▼
  Entorhinal ── context coordinates   Pool merge + cross-encoder re-score
    │                                    │
    ▼                                    ▼
  Perirhinal ── gist extraction       Spreading activation + lateral inhibition
    │                                    │
    ▼                                    ▼
  Hippocampus ─ embed + store         Return top-k

Post-Recall

Component	What It Does
Hebbian Boost	Co-retrieved memories strengthen mutual links
Thalamus Overlay	Prepends pinned memories, tracks recency
Decay Sweep	TTL pruning of unrehearsed, low-access memories
Consolidation	Entity extraction → semantic network (auto-triggers every N stores)

For the full step-by-step pipeline walkthrough, neuroscience mapping, and advanced configuration, see docs/architecture.md.

CLI & MCP Tools

CLI

myelin status       # Health + integrity check
myelin stats        # KPI dashboard: counts, types, age, Hebbian links
myelin serve        # Start MCP server (stdio)
myelin decay        # Prune stale memories
myelin consolidate  # Replay episodes into semantic network
myelin export out.json      # Export all memories to JSON
myelin import out.json      # Import memories from JSON
myelin export-md ./exports/ # Export memories as Markdown files with YAML frontmatter
myelin import-md ./exports/ # Import memories from a directory of Markdown files
myelin obsidian-export ~/vaults/work  # Export to an Obsidian vault (graph view)
myelin obsidian-import ~/vaults/work  # Import from an Obsidian vault
myelin ingest ./docs/       # Bulk-load .txt/.md/.json files into memory
myelin debug-recall "your query"  # Full pipeline breakdown for debugging
myelin graph                      # Launch browser admin dashboard (Graph | Overview | Memories)

myelin stats accepts --project, --agent-id, and --json flags for filtering and machine-readable output.

The ingest command bulk-loads content from files or directories:

myelin ingest ./docs/                        # Recurse into directory
myelin ingest ./notes/arch.md                # Single file
myelin ingest ./docs/ --project myapp --scope architecture
myelin ingest ./data/ --source wiki --no-recursive  # Top-level only

Supported formats:

.txt / .md — file body becomes one memory; YAML frontmatter between --- delimiters is parsed for project, scope, tags, memory_type, language, source fields
.json — list of objects in the same shape as myelin export; each must have a "content" key

The export-md / import-md commands round-trip memories as individual Markdown files with YAML frontmatter — useful for version-controlling memories in a git repo or editing them manually:

myelin export-md ./memory-backup/
# edit files...
myelin import-md ./memory-backup/
myelin import-md ./memory-backup/ --source restored

The obsidian-export command exports memories into an Obsidian vault for graph-view visualisation. Each memory becomes a note with YAML frontmatter and [[entity]] wikilinks — Obsidian's graph view then clusters memories by shared entities, projects, and scopes:

myelin obsidian-export ~/vaults/work           # export all memories
myelin obsidian-export ~/vaults/work --type semantic   # decisions only
myelin obsidian-export ~/vaults/work --project myapp   # one project

The resulting vault structure:

vault/
├── Memory Index.md
└── Memories/
    ├── semantic/   ← decisions, facts
    ├── episodic/   ← events, bug fixes
    ├── procedural/ ← preferences, how-tos
    └── prospective/← plans, advice

To bring hand-edited or new notes back into myelin:

myelin obsidian-import ~/vaults/work
myelin obsidian-import ~/vaults/work --source obsidian

The debug-recall command runs a recall query and shows exactly what happened at each stage of the pipeline:

myelin debug-recall "what auth approach did we pick?" [-n N] [--project P] [--scope S] [--memory-type T] [--json]

Output includes:

Query plan — what the PFC query planner inferred (memory type, scope, signals)
Amygdala gate — whether the query would be accepted if stored
Results with per-result score breakdown:
- bi — raw bi-encoder cosine similarity from ChromaDB
- ce — cross-encoder re-rank score
- hebbian — co-access weight accumulated from prior co-recalls
- final_score — after Hebbian boost (the score used for ranking)

NOTE

If running from a dev checkout instead of an installed package, prefix withuv run: uv run myelin status

MCP Tools

Tool	Description
`store`	Encode a memory with context metadata (auto-classifies type, auto-chunks, 500K char limit). Pass `overwrite=true` to replace a near-duplicate instead of rejecting. Pass `agent_id` to store in an isolated namespace.
`recall`	Retrieve by semantic similarity (auto-inferred filters, multi-probe, Hebbian boost, 10K char limit). Pass `agent_id` to restrict results to that namespace.
`forget`	Remove a specific memory by ID
`pin_memory`	Pin a memory — always included in recall results
`unpin_memory`	Remove a pin
`decay_sweep`	Prune stale memories (access-based TTL)
`consolidate`	Replay episodes into the semantic network
`status`	Memory system health check (counts, configuration)
`stats`	KPI dashboard: counts by type/project/scope/region, access health, age distribution, Hebbian links, decay candidates. Accepts `project` and `agent_id` filters.
`health`	Lightweight liveness probe (ok + version, no store initialization)
`ingest`	Bulk-load a file or directory into memory (`.txt`, `.md`, `.json`; supports YAML frontmatter metadata)

Data Storage

All data lives in ~/.myelin/ (configurable via MYELIN_DATA_DIR):

File	Purpose
`chroma/`	Vector database (ChromaDB) — embeddings and metadata
`hebbian.db`	Co-access patterns between memories
`neocortex.db`	Semantic network — entities and relationships
`thalamus.db`	Pinned memories and recency tracking

SQLite files use WAL mode for concurrent read performance. For more on inspecting these databases, see docs/architecture.md.

Configuration

All parameters use environment variables with a MYELIN_ prefix. Defaults work out of the box — most users won't need to change anything.

Common Parameters

Parameter	Default	What It Controls
`data_dir`	`~/.myelin`	Where all data lives
`default_n_results`	`5`	Results returned per recall
`max_memories`	`0`	Hard memory cap; 0 = unlimited. LRU eviction when exceeded
`consolidation_interval`	`50`	Auto-consolidate every N stores (0 = disabled)
`log_level`	`INFO`	Logging verbosity (structured JSON to stderr)

Storage Parameters

Parameter	Default	What It Controls
`embedding_model`	`all-MiniLM-L6-v2`	Bi-encoder model (384-dim, 22M params)
`chunk_max_chars`	`1000`	Max characters per chunk
`chunk_overlap_chars`	`200`	Overlap between text chunks
`min_content_length`	`20`	Minimum chars to pass the input gate
`dedup_similarity_threshold`	`0.95`	Above this = near-duplicate, rejected

Recall Parameters

Parameter	Default	What It Controls
`recall_over_factor`	`8`	Over-retrieval multiplier for re-ranking headroom
`multiprobe`	`true`	3-probe retrieval (original + keywords + entity-expanded)
`neocortex_rerank`	`true`	Cross-encoder re-ranking
`neocortex_weight`	`0.6`	CE/bi-encoder blend (0.0–1.0)
`cross_encoder_model`	`ms-marco-MiniLM-L-6-v2`	Cross-encoder model (22M params)
`lateral_k`	`1`	Max results per session/scope (0 = off)

For advanced tuning parameters (boosting weights, spreading activation, maintenance thresholds, background worker), see docs/architecture.md.

Upgrading

Patch and minor updates (0.x.y)

# uv
uv tool upgrade myelin-mcp

# pip
pip install --upgrade myelin-mcp

Patch and minor updates are backward-compatible — your existing data directory works without changes. Run myelin status after upgrading to verify.

Backup before major updates

Before upgrading across major versions, export your data:

myelin export backup.json
# upgrade
myelin import backup.json

Embedding model changes

Myelin records the embedding model version in ChromaDB metadata. If a future release changes the default embedding model, existing vectors would need re-encoding to maintain recall quality. This has not happened yet — all-MiniLM-L6-v2 has been the model since v0.1.0.

When a model change does ship, the release notes will include migration instructions. The safe path is always: myelin export → upgrade → myelin import (re-encodes all content with the new model).

Development

git clone https://github.com/et-do/myelin.git
cd myelin
uv sync --extra dev
uv run pre-commit install
uv run pytest -v --cov=myelin

A Dev Container config is included — open in VS Code and "Reopen in Container" for a zero-setup environment.

See CONTRIBUTING.md for the full workflow: branching, conventional commits, automated releases, benchmarking, and project structure.

License

MIT

Available Tools

11 tools

consolidateA

Replay episodic memories into the semantic network (offline consolidation).

Extracts entities from stored memories and builds co-occurrence relationships in the neocortex — like hippocampal replay during sleep.

Returns: JSON summary of memories replayed, entities found, and relationships created.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations provided, the description correctly identifies this as a write/transform operation (not read-only) and mentions it 'extracts entities' and 'builds co-occurrence relationships', implying no destructive side effects. However, it does not disclose concurrency concerns, required state (e.g., must have memories stored first), or whether it can be safely run multiple times (idempotency).

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?

Three concise sentences with biological analogy front-loaded, then processing details, then return format. No wasted words.

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?

For a zero-parameter tool with an output schema, the description is complete. It explains the abstract purpose, the internal process, and the return value format without needing to detail parameters or schema fields.

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?

No parameters exist, so the baseline is 4. The description adds meaning by explaining what happens during consolidation (entity extraction, relationship building), which compensates for the absence of 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 the tool 'replays episodic memories into the semantic network' using the specific verb 'consolidate'. It distinguishes itself from siblings (store, recall, forget) by explaining its offline processing role similar to hippocampal replay during sleep.

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 description implies this is for processing stored memories into long-term semantic structure, but does not explicitly state when to use it versus siblings like 'store' or 'decay_sweep'. No when-not-to-use guidance or prerequisites are provided.

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

decay_sweepB

Prune stale memories that haven't been accessed recently.

Removes memories exceeding the idle threshold with low access counts.

Returns: JSON summary of pruned memories.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description bears full responsibility for disclosing behavior. It mentions pruning based on 'idle threshold' and 'low access counts' and that it returns a JSON summary, but it does not explain what the threshold is, whether the operation is reversible, what happens to pinned memories, or any side effects. This is insufficient for a mutation tool.

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, clearly front-loaded with the core action. Every sentence provides useful information: the purpose, the mechanism, and the return format. No wasted words.

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 no parameters and an output schema present, the description covers the essential aspects: what it does, how it selects memories, and what it returns. It could elaborate on the idle threshold or any configuration, but given the simplicity, it is largely complete.

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?

There are no parameters, so the schema coverage is trivially 100%. The description adds meaning beyond the empty schema by explaining the action (pruning stale memories) and the return value (JSON summary). This is valuable context that the schema alone cannot provide.

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

Purpose4/5

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

The description clearly states the tool prunes stale memories based on recency and access counts, using specific verbs like 'Prune' and 'Removes'. It distinguishes from siblings like 'forget' (explicit removal) and 'store'/'recall' by focusing on automatic cleanup of unused memories. However, it could be more explicit about the idle threshold and access count criteria, which are not fully defined.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'forget' for explicit removal or 'consolidate' for merging. It does not state prerequisites, context, or when not to use it. The description implies automated cleanup but lacks explicit usage boundaries.

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

forgetB

Remove a specific memory by ID.

Args: memory_id: The ID of the memory to remove.

Returns: JSON confirmation or error.

ParametersJSON Schema

Name	Required	Description	Default
`memory_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavioral traits. It only states 'Remove' without clarifying side effects (e.g., irreversibility, impact on related data, or required permissions). The return line mentions 'confirmation or error' but lacks specifics on what the confirmation looks like.

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 concise and structured, with a clear purpose sentence followed by parameter and return sections. It is front-loaded and uses minimal words, though it could be slightly more compact without losing clarity.

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 the tool's simplicity (one parameter, delete operation), the description is mostly complete. However, it lacks details on the output format (the output schema exists but is not referenced) and does not address edge cases like missing IDs or concurrent modifications. This leaves some ambiguity for an agent.

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 0% description coverage, so the description carries the burden. It explains 'memory_id: The ID of the memory to remove', which adds basic meaning but no extra context like format, examples, or constraints. For a single parameter, this is adequate but not enriching.

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 uses the specific verb 'Remove' and the resource 'memory by ID', clearly distinguishing this deletion tool from siblings like 'store', 'recall', or 'pin_memory'. No tautology; the name 'forget' is clarified by the action.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, such as checking that the memory exists, or situations where other tools like 'decay_sweep' might be more appropriate.

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

healthA

Lightweight health check — returns ok without initializing stores.

Returns: JSON with status and version.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/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 clearly states the tool is non-destructive and lightweight, which is a strong behavioral disclosure. The only gap is not explaining what happens if internal state is partially initialized, but for a health check, this is sufficient.

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: one sentence of purpose, then a bullet pointing to return values. Every word earns its place, and it's front-loaded with the key behavioral trait.

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 zero parameters, no annotations, and a simple health check task, the description is complete. It covers purpose, behavior, and return value format (JSON with status and version). No gaps.

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 schema has no parameters, and schema description coverage is 100%, so the baseline is 4. The description adds no param info but doesn't need to.

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 purpose: 'Lightweight health check — returns ok without initializing stores.' The verb 'returns' and resource 'health check' are specific, and the tool distinguishes itself from siblings like 'stats' or 'status' by emphasizing it's lightweight and doesn't initialize stores.

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 says 'without initializing stores,' implying it's safe to call without side effects. However, it doesn't explicitly state when to use this versus other tools like 'stats' or 'status,' though the context is clear enough for an agent to infer it's a basic readiness check.

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

ingestA

Bulk-load memories from a file or directory.

Supported formats:

.txt / .md: file body stored as one memory. Optional YAML frontmatter (between --- delimiters) sets project, scope, language, memory_type, tags, and source for that file.
.json: array of objects with a "content" key (same shape as myelin export output).
directory: recurse and ingest every supported file found.

Args: path: Absolute or relative path to a file or directory. project: Default project tag (overridden by per-file frontmatter). scope: Default scope tag (overridden by per-file frontmatter). source: Source label for all ingested memories. recursive: Descend into subdirectories (default: true).

Returns: JSON summary with stored, skipped, and errors counts.

ParametersJSON Schema

Name	Required	Default
`path`	Yes
`scope`	No
`source`	No	ingest
`project`	No
`recursive`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

With no annotations, the description carries full behavioral disclosure. It details how files are processed (YAML frontmatter overrides, JSON array shape), recursion behavior, and the return summary (stored, skipped, errors). This gives the agent a solid understanding of what the tool does beyond the raw schema.

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 well-structured with clear sections (intro, formats, args, returns). While detailed, every sentence earns its place and there is no redundancy. It front-loads the main purpose and then organizes supporting details logically.

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 complexity (multiple formats, options, recursion), the description is complete. It covers all inputs, behaviors, and return values. The output summary is mentioned, and the schema adds further specificity. It is fully adequate for agent invocation.

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

Parameters5/5

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

The description provides an 'Args:' section that describes every parameter beyond the schema: path is absolute/relative, project/scope are overridden by frontmatter, source is a label for all memories, and recursive defaults to true. This adds substantial meaning to the bare schema entries.

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 it 'Bulk-load memories from a file or directory,' with specific verbs ('load') and resources ('memories'). It distinguishes itself from siblings like 'store' (which presumably handles single memories) by emphasizing bulk ingestion from files/directories.

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 clearly implies when to use this tool—when you have memories in a file/directory. It explains supported formats and recursion behavior, providing clear context. However, it does not explicitly mention alternatives or when not to use it, such as pointing to 'store' for individual memories.

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

pin_memoryA

Pin a memory so it is always included in recall results.

Pinned memories model the thalamic relay — sustained activation that keeps critical facts always available to the cortex.

Args: memory_id: The ID of the memory to pin. priority: 0 = identity/system context, 1 = critical facts. label: Optional human-readable label for this pin.

Returns: JSON confirmation.

ParametersJSON Schema

Name	Required	Description	Default
`label`	No
`priority`	No
`memory_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

The description discloses the key behavioral effect (always included in recall) and explains the priority parameter's meanings. Without annotations, it carries the transparency burden well, though it omits mention of mutability or reversibility.

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 summary, conceptual analogy, and parameter details. The thalamic relay analogy adds context but may be slightly verbose for an AI agent; still concise overall.

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?

The description covers the tool's purpose, parameters, and return format. It references the relevant sibling 'unpin_memory' implicitly but doesn't mention prerequisites or integration with other tools. Given the output schema exists, the return description is sufficient.

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

Parameters5/5

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

The Args section provides clear, human-readable explanations for all three parameters, adding meaning beyond the schema's type and default definitions. Priority values are explicitly mapped to semantic categories.

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 action ('Pin a memory') and its effect ('always included in recall results'). It distinguishes from siblings like 'unpin_memory' and 'forget' by specifying the persistent inclusion in recall.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives like 'store' or 'unpin_memory'. The description does not mention prerequisites or when pinning is appropriate, leaving the agent to infer context.

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

recallA

Recall memories relevant to a query.

Args: query: What to search for (semantic similarity). n_results: Maximum number of results to return. project: Filter to a specific cortical region (project). language: Filter to a specific language. scope: Filter to a specific engram cluster (domain scope). memory_type: Filter by memory system (episodic/semantic/procedural/prospective). reference_date: ISO-8601 date for temporal context (e.g. "2026-04-12"). Defaults to now. agent_id: Namespace identifier — only returns memories stored with the same agent_id. Omit or leave empty to query the global shared namespace.

Returns: JSON array of matching memories with scores.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`scope`	No
`project`	No
`agent_id`	No
`language`	No
`n_results`	No
`memory_type`	No
`reference_date`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must disclose behavioral traits. The description suggests a read-only operation by stating 'recall' and 'returns ... memories,' but it does not explicitly confirm no side effects, required permissions, or rate limits. The behavior is implied but not fully transparent.

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 an Args/Returns format and is front-loaded with the purpose. While somewhat lengthy, the parameter descriptions are necessary given the schema coverage. Every sentence contributes, but minor redundancy could be trimmed (e.g., default values for n_results are both in schema and description).

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 complexity (8 parameters, output schema exists) the description is fairly complete. It covers all parameters, return format, and basic semantics. It lacks mention of edge cases (e.g., empty results, error handling) and sorting order, but the output schema presumably defines the exact structure. Overall adequate for a retrieval tool.

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

Parameters5/5

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

With 0% schema description coverage, the description provides essential explanations for each of the 8 parameters, including defaults, examples (e.g., reference_date ISO-8601), and semantics (e.g., agent_id for namespace). This fully compensates for the schema's lack of descriptions and adds significant value.

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 'Recall memories relevant to a query.' The verb 'recall' and resource 'memories' precisely describe the operation. It distinguishes itself from sibling tools like store (write), forget (delete), and stats (aggregate), making the tool's 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 Guidelines3/5

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

The description implies the tool is for querying memories but does not explicitly state when to use it vs. alternatives (e.g., stats for aggregated data, or ingest for adding data). No exclusions or prerequisites are mentioned, leaving the agent to infer usage context from sibling names.

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

statsA

KPI dashboard for the memory database.

Returns counts by memory type, project, scope, knowledge domain, access health (hot/warm/cold), age distribution, Hebbian link statistics, and a count of decay candidates. Optionally filter to a specific project or agent namespace.

Args: project: Restrict results to this project name (empty = all projects). agent_id: Restrict results to this agent namespace (empty = all agents).

Returns: JSON with total, entity_count, relationship_count, pinned_count, hebbian stats, by_type, by_project, by_scope, by_region, access, age, decay_candidates, and filter.

ParametersJSON Schema

Name	Required	Description	Default
`project`	No
`agent_id`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It correctly describes the tool as an information retrieval (dashboard) with no destructive side effects, but does not mention performance implications (e.g., might be expensive on large databases), concurrency behavior, or permission requirements. The level of transparency is adequate but not comprehensive.

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-organized: a one-line summary, then a bullet-like list of returned metrics, followed by parameter documentation. This front-loads the purpose and scans well. It could be slightly more concise by merging the parameter and returns sections, but remains efficient.

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 complexity (aggregating many metrics), limited parameters, and the presence of an output schema that documents the return structure, the description is remarkably complete. It explains what each section of the return value covers and how filtering works, leaving no major gaps.

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 explain parameters. It does so effectively: it states 'project restricts results to this project name' and 'agent_id restricts results to this agent namespace', and documents that empty values mean no filtering. This adds clear meaning beyond the schema's minimal 'Project' and 'Agent Id' titles.

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 'KPI dashboard for the memory database' and enumerates specific metrics returned (counts by type, project, scope, etc.), which distinguishes it from siblings like 'status' and 'health' that likely provide operational or health check 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 description explains optional filtering by project or agent_id, but provides no guidance on when to use this tool versus alternatives like 'status', 'health', or 'ingest'. It lacks explicit context on when it is appropriate to call stats or when to avoid it.

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

statusA

Show memory system status.

Returns: JSON with memory count and configuration.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description must stand alone. It correctly indicates a read-only operation ('show') and states the return type, but does not disclose any side effects, rate limits, or whether configuration implies mutable state. Adequate for a read-only tool.

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 with two short sentences, front-loading the purpose and briefly summarizing the return value. 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 there are no parameters, the description provides sufficient context for a simple status read tool. The presence of an output schema likely details the JSON structure, so repeating it is unnecessary. One minor gap: it does not explain what 'memory count' or 'configuration' represent.

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?

There are zero parameters, so the schema is fully covered. The description does not need to add parameter meaning but adds value by describing the return format ('JSON with memory count and configuration').

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 'Show memory system status', which is a specific verb-resource combination. It distinguishes itself from siblings like 'stats' (likely focuses on statistics) and 'health' (likely checks system health).

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 description provides no explicit guidance on when to use this tool versus alternatives like 'stats' or 'health'. However, given there are zero parameters and the purpose is clear, usage context is implied as a simple status read.

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

storeA

Store a memory with optional context metadata.

Args: content: The information to remember. project: Cortical region — project name for scoped retrieval. language: Programming language context. scope: Engram cluster — domain scope (e.g. "auth", "database"). memory_type: Memory system (episodic/semantic/procedural/prospective). tags: Comma-separated tags for categorization. source: Which tool stored this ("copilot", "cursor", etc.). overwrite: If True and content is a near-duplicate of an existing memory, replace the old memory instead of rejecting. The response will include "replaced": <old_parent_id> and "status": "updated". agent_id: Namespace identifier for the storing agent or bot. Memories tagged with an agent_id are only returned when the same agent_id is supplied at recall time. relations: JSON-encoded list of [subject, predicate, object] triples to assert as relationship edges immediately, e.g. '[["AuthService","depends_on","JWTHelper"]]'. Malformed input is silently ignored so it never blocks the store.

Returns: JSON with memory ID on success, or rejection reason.

ParametersJSON Schema

Name	Required	Description	Default
`tags`	No
`scope`	No
`source`	No
`content`	Yes
`project`	No
`agent_id`	No
`language`	No
`overwrite`	No
`relations`	No
`memory_type`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/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. It explains overwrite behavior, silent failure for malformed relations, agent_id scoping, and return format. This is comprehensive and avoids contradictions.

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 Args and Returns sections and is front-loaded with the main purpose. It is somewhat lengthy but justified by 10 parameters. Every sentence adds value, so no waste.

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 complexity (10 params, no annotations, sibling tools), the description covers purpose, all parameters with detailed semantics, return values, and edge cases (malformed inputs). It is comprehensive enough for an agent to correctly select and invoke the tool.

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

Parameters5/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 thoroughly explains all 10 parameters, including overwrite's response details, relations format with error handling, and agent_id scoping. This adds significant meaning 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 clearly states 'Store a memory with optional context metadata,' which is a specific verb+resource. It distinguishes from sibling tools like recall, forget, and ingest by focusing on storage creation.

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 clear context for storing memories but does not explicitly state when to use this tool versus alternatives (e.g., ingest for bulk import). However, the purpose is self-evident and adequately differentiated by name and siblings.

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

unpin_memoryB

Remove a pinned memory from the thalamic buffer.

Args: memory_id: The ID of the memory to unpin.

Returns: JSON confirmation or not_found.

ParametersJSON Schema

Name	Required	Description	Default
`memory_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior3/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 of behavioral disclosure. It indicates the operation is destructive (removing a pin), mentions possible not_found result, but does not clarify whether the memory is deleted or simply unpinned, nor does it state authorization or 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 concise with only two sentences plus an Args section. It is front-loaded with the purpose and includes parameter and return info. No unnecessary text.

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?

With no output schema provided in the input (though context signals indicate it exists), the description mentions the return shape (JSON confirmation or not_found). For a simple single-parameter tool, this is reasonably complete, but could still benefit from clarifying whether 'remove' means deletion or just unpinning.

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 explains the memory_id parameter as 'The ID of the memory to unpin', which adds clear meaning beyond the schema's minimal 'Memory Id' title. This is good coverage given only one parameter.

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

Purpose4/5

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

The description clearly states the verb 'Remove' and the resource 'pinned memory from the thalamic buffer'. It also mentions the expected return value (JSON confirmation or not_found). This distinguishes it from siblings like pin_memory, but doesn't fully differentiate from related tools like forget.

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

Usage Guidelines2/5

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

The description does not provide any guidance on when to use this tool vs. alternatives such as forget or pin_memory. It lacks context about prerequisites (e.g., memory must be pinned first) or scenarios where using this tool is appropriate.

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.

11 tool updatesv0.1.0Aug 18, 2026
- First observedconsolidate
- First observeddecay_sweep
- First observedforget
- First observedhealth
- First observedingest
- First observedpin_memory
- First observedrecall
- First observedstats
- First observedstatus
- First observedstore
- First observedunpin_memory

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored 2026-08-18 03:30 across 11 tools

Disambiguation5/5

Each tool targets a clearly distinct operation on the memory system: stats for aggregation, store/recall/forget for CRUD, pin/unpin for priority memory, decay_sweep for maintenance, status for system info, consolidate for memory processing, ingest for bulk loading, and health for liveness. There is no ambiguity between tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern (e.g., pin_memory, decay_sweep, consolidate) with no mixing of casing or conventions. The names are concise and descriptive, making the action and target immediately clear.

Tool Count5/5

With 11 tools, the server covers the full lifecycle of memory management (store, recall, forget, pin, unpin, stats, status, consolidate, decay_sweep, ingest, health) without being bloated. Each tool serves a necessary function, and the count feels well-scoped for a memory database server.

Completeness5/5

The tool set provides comprehensive coverage: CRUD operations (create through store/recall/forget), pinning for prioritized recall, bulk ingestion, maintenance through decay_sweep, consolidation for semantic learning, and monitoring via stats/status/health. There are no obvious gaps for a memory system.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Penfield Memory AOAuth
io.github.penfieldlabs
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Knowledge & Memory RAG Systems Vector Databases
1726
SutraOAuth
io.github.shivnathtathe
Private, portable memory and reusable skills for AI agents.
Knowledge & Memory Autonomous Agents
11
agentbay-mcp AOAuth
io.github.thomasjumper
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Knowledge & Memory Autonomous Agents Agent Orchestration
21
Epitome
io.github.gunning4it
Personal AI memory — gives every AI agent shared, persistent memory of you
Knowledge & Memory Autonomous Agents
2

Related MCP Servers

Mnemexa MCPofficial
Knowledge & Memory RAG Systems
mnemexa
A
license
A
quality
D
maintenance
Provides persistent, self-optimizing memory for AI agents, enabling them to remember preferences and context across sessions and share knowledge across multiple agents.
Updated 4 months ago (2026-05-20 17:57 UTC)
4
9 npm
ISC
Smriti
Knowledge & Memory Search
moltizmo
A
license
Not graded
quality
D
maintenance
Local-first persistent memory for AI agents via MCP, enabling semantic search and memory sharing across agents with zero cloud cost and full privacy.
Updated 6 months ago (2026-03-13 16:54 UTC)
6 npm
1
MIT
hmem
Knowledge & Memory Agent Orchestration Autonomous Agents
Bumblebiber
A
license
Not graded
quality
F
maintenance
Enables persistent, portable memory for AI agents across sessions, devices, and providers with token-efficient 5-level lazy loading and automatic session capture.
Updated 17 days ago (2026-08-28 14:11 UTC)
7 npm
MIT
Ori Mnemos
Knowledge & Memory RAG Systems
aayoawoyemi
A
license
Not graded
quality
A
maintenance
Open-source persistent memory infrastructure for AI agents.
Updated a month ago (2026-07-30 23:07 UTC)
92 npm
323
Apache 2.0

Table of Contents

Why Myelin

Quick Start

Install

Configure your AI tool

Verify

Setup Guides

Personal (Cross-Project)

Per-Repository

Multi-Agent (Shared Instance, Isolated Namespaces)

Team / Cloud

Teaching Your Agent

Agent Instructions

Tips for Effective Memory

Benchmark Results

LongMemEval_S — 500 questions, zero LLM calls

Per-Category Breakdown

LoCoMo — 1,986 questions, 10 conversations

Latency — 8-core CPU, no GPU

Methodology

How It Works

Core Concepts

Memory Systems

Pipeline Overview

Post-Recall

CLI & MCP Tools

CLI

MCP Tools

Data Storage

Configuration

Common Parameters

Storage Parameters

Recall Parameters

Upgrading

Patch and minor updates (0.x.y)

Backup before major updates

Embedding model changes

Development

Further Reading

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Mnemexa MCPofficial