Skip to main content
Glama

engrim

CI PyPI Website Python 3.10+ License: MIT Local & Private Glama MCP

The Universal Cross-Model & Cross-Agent Episodic Memory Standard.

A local-first, project-scoped SQLite memory engine that allows developers to freely switch between models and environments (Google Antigravity, Claude Code, Cursor, Codex CLI, GitHub Copilot CLI, OpenCode, and Windsurf) on the same codebase without losing architectural decisions, user constraints, or project state.


1. Overview & Core Value Proposition

"Why pay for 200,000 tokens of forgotten noise on every turn? The models are disposable utilities; your project's decisions are not."

Engrim is the universal, cross-model episodic memory standard engineered specifically for autonomous AI coding agents and heavy software development.

It solves the "200,000-token context window trap" (where coding models suffer from severe attention dilution, compounding per-turn token costs, and the loss of prior architectural decisions whenever a chat session is cleared) by replacing raw transcript replay with 4,000 characters of high-precision, curated episodic working memory stored in a single, local-first SQLite file (~/.engrim/memory.db).

The Problem vs. The Engrim Standard

Challenge

Without Engrim (Token Bloat & Context Resets)

With Engrim (Episodic Continuity)

Context Window

Attention Dilution: 150k+ tokens re-sent on every turn; models lose reasoning sharpness and hallucinate past constraints.

Precision Working Memory: ~4,000 chars (<1,000 tokens, <1% of context) injected at boot. Zero attention dilution.

Session Clearing

Context Reset on /clear: Clearing chat wipes agent context to zero; you spend minutes re-explaining rules and architecture.

Continue-As-Clear: Clear anytime (/clear). Decisions, active state, and [โ–ถ RESUME HERE] reload instantly.

Agent Ecosystem

Vendor Silos: Decisions made in Claude Code are invisible in Antigravity, Cursor, Codex, Copilot CLI, or OpenCode.

Universal Substrate: One local SQLite store (~/.engrim/memory.db) shared across all 6 major harnesses.

Hook Reliability

Silent Failures: Moving across machines or OSes silently breaks hardcoded binary paths with no error message.

Self-Healing Diagnostics: engrim doctor --fix checks the supported hook and MCP configurations and repairs stale binary paths.

Data Privacy

SaaS Cloud Leakage: Proprietary code and architectural constraints sent to third-party memory APIs.

100% Local & Private: Stored locally in SQLite WAL mode (POSIX 0600). No telemetry, no cloud sync, no tracking.


Related MCP server: agentmem

2. Architecture & How It Works (The 10-Second Mental Model)

graph TD
    subgraph Agents ["Supported Agent Environments"]
        AGY["Google Antigravity<br/>(PreInvocation & Stop Hooks)"]
        CLAUDE["Claude Code<br/>(SessionStart & Stop Hooks)"]
        CURSOR["Cursor / Windsurf<br/>(Model Context Protocol stdio)"]
        CODEX["Codex CLI<br/>(Hooks, guidance & optional MCP)"]
        OPENCODE["OpenCode<br/>(Plugin & MCP)"]
        COPILOT["GitHub Copilot CLI<br/>(Command hooks & MCP)"]
    end

    subgraph CoreEngine ["engrim Core Engine (v1.4.11)"]
        ADAPTERS["Adapters & Lifecycle Hooks<br/>(agy, claude, opencode, copilot, mcp)"]
        DOCTOR["Health & Diagnostic Engine<br/>(engrim doctor --fix)"]
        PROVENANCE["Agent Provenance Engine<br/>(origin_agent tracking)"]
        ROUTER["Hybrid Retrieval & Minder<br/>(bm25 lexical + vector cosine)"]
    end

    subgraph Storage ["Local-First SQLite Store (~/.engrim/memory.db)"]
        MEMORIES[("Curated Memories<br/>(decisions, facts, feedback)")]
        FTS5["FTS5 Full-Text Search<br/>(porter stemmer, triggers)"]
        VEC["Vector Embeddings<br/>(model2vec static embeddings)"]
        LOG["Flight Recorder Log<br/>(turns + action lines)"]
    end

    AGY <-->|"hook / CLI"| ADAPTERS
    CLAUDE <-->|"hook / CLI"| ADAPTERS
    CURSOR <-->|"JSON-RPC (stdio)"| ADAPTERS
    CODEX <-->|"command hook / MCP"| ADAPTERS
    OPENCODE <-->|"plugin / MCP"| ADAPTERS
    COPILOT <-->|"command hook / MCP"| ADAPTERS
    ADAPTERS --> PROVENANCE
    PROVENANCE --> ROUTER
    ROUTER --> MEMORIES
    MEMORIES --- FTS5
    MEMORIES --- VEC
    ADAPTERS --> LOG
  1. Boot: When your agent starts or a prompt is submitted, engrim injects the top-priority memory pack (~4k chars) into the agent's context, leading with [โ–ถ RESUME HERE].

  2. Capture: As the agent works, it records architectural decisions via MCP (engrim_add) or lifecycle hooks automatically, tracking the origin_agent provenance.

  3. Recall & Minder: Hybrid lexical (bm25) + vector (model2vec) search retrieves relevant records on demand in ~30ms without slowing down the agent.

  4. Continue-As-Clear: When context bloats or the model drifts, type /clear. The next session boots from memory.db with zero memory loss.


3. Multi-Agent Quickstart

Installation

pip install engrim

Run engrim setup without arguments. It automatically detects installed environments on your machine and configures them all:

engrim setup
  • If ~/.gemini exists $\rightarrow$ wires Antigravity lifecycle hooks, skill, and MCP server.

  • If ~/.claude exists $\rightarrow$ wires Claude Code SessionStart, Stop, status line, and CLAUDE.md.

  • If ~/.cursor exists $\rightarrow$ generates and merges Cursor MCP configuration.

  • If ~/.codex exists $\rightarrow$ wires Codex CLI native command hooks and managed global AGENTS.md guidance. MCP stays opt-in.

  • If ~/.config/opencode exists $\rightarrow$ writes OpenCode plugin, registers MCP server, and adds AGENTS.md notes.

  • If ~/.copilot exists $\rightarrow$ wires Copilot CLI hooks and the Engrim status line, registers the MCP server, and adds copilot-instructions.md notes.


Diagnostic Health Check & Self-Healing (engrim doctor)

Verify database integrity, semantic recall coverage, and all configured agent hooks across your system:

# Run comprehensive health diagnostic across all agent environments
engrim doctor

# Automatically repair broken hook paths or cross-OS migrations with self-healing PATH fallback
engrim doctor --fix

# Output diagnostic report as JSON (for CI pipelines or health monitoring)
engrim doctor --json

Real output:

================================================================================
                 ๐Ÿฉบ ENGRIM DOCTOR: DIAGNOSTIC HEALTH CHECK                    
================================================================================
Platform   : linux (x86_64) ยท Python 3.12.3
Engrim CLI : /home/user/.local/bin/engrim
Project    : /workspace/my-project

[1] Database & Storage Engine
  โœ“ Store Location   : /home/user/.engrim/memory.db
  โœ“ Integrity Check  : ok
  โœ“ Journal Mode     : wal (WAL)
  โœ“ Curated Memories : 956 active / 1057 total
    (decision=413, fact=178, feedback=47, reference=20, state=283, user=15)
  โœ“ Flight Log Turns : 48501 logged

[2] Semantic Recall Engine
  โœ“ Model Available  : model2vec:minishlab/potion-base-8M
  โœ“ Embedded Records : 1032 / 956

[3] Agent Environments & Hooks
  Google Antigravity (~/.gemini):
    โœ“ PreInvocation hook: valid
    โœ“ Stop hook: valid
    โœ“ MCP server: /home/user/.local/bin/engrim (valid)
    โœ“ Skill deployed: yes
  Claude Code (~/.claude):
    โœ“ SessionStart hook: valid
    โœ“ SessionEnd hook: valid
    โœ“ Stop hook: valid
    โœ“ UserPromptSubmit hook: valid
  Codex CLI (~/.codex):
    โœ“ SessionStart hook: valid
    โœ“ SessionEnd hook: valid
    โœ“ Stop hook: valid
    โœ“ UserPromptSubmit hook: valid
    โœ“ Managed AGENTS.md guidance: present
    โ€ข MCP registration: optional, not configured
  GitHub Copilot CLI (~/.copilot):
    โœ“ sessionStart hook: valid
    โœ“ userPromptSubmitted hook: valid
    โœ“ agentStop hook: valid
    โœ“ MCP server: /home/user/.local/bin/engrim (valid)
    โœ“ Status line: configured

================================================================================
Result: All systems healthy. Zero issues detected across all agent hosts.
================================================================================
  • Self-Healing Path Fallback: Hook commands feature portable PATH fallback (<bin> || engrim ... || true) ensuring sessions never experience silent hook failures when directories move or dotfiles sync across machines.

  • Deep Integrity Audit: Validates SQLite WAL mode, database consistency (PRAGMA integrity_check), active records, and semantic model readiness (model2vec).


Explicit Platform Setup

๐Ÿช Google Antigravity

engrim setup --agy
  • Configures ~/.gemini/config/hooks.json to execute engrim hook --agent agy --event boot on PreInvocation and engrim hook --agent agy --event stop on Stop.

  • Deploys canonical Antigravity skill to ~/.gemini/config/skills/engrim/SKILL.md.

  • Registers MCP server in ~/.gemini/antigravity-cli/mcp_config.json and ~/.gemini/config/mcp_config.json.

๐ŸŸฃ Claude Code

engrim setup --claude
  • Wires SessionStart, SessionEnd, Stop, and UserPromptSubmit hooks in ~/.claude/settings.json.

  • Configures live ambient status line in Claude Code's status bar.

  • Appends memory usage notes to ~/.claude/CLAUDE.md.

โšก Cursor & Windsurf

engrim setup --cursor
  • Adds engrim to ~/.cursor/mcp.json running engrim serve --mcp.

For Windsurf, add engrim to ~/.codeium/windsurf/mcp_config.json:

{
  "mcpServers": {
    "engrim": {
      "command": "engrim",
      "args": ["serve", "--mcp"]
    }
  }
}

๐Ÿ’ป Codex CLI

engrim setup --codex
  • Wires SessionStart, SessionEnd, Stop, and UserPromptSubmit command hooks in $CODEX_HOME/hooks.json (~/.codex by default).

  • Adds or updates an Engrim-owned block in $CODEX_HOME/AGENTS.md. Existing instructions and symbolic links remain unchanged. If the file already has an unmarked ## Project Memory (engrim) section, setup treats it as user-owned and does not add a duplicate. A non-empty AGENTS.override.md is not modified, but setup warns that it shadows the guidance.

  • Calls the local engrim CLI directly, so MCP is not required. Hooks must be reviewed and trusted with Codex's /hooks command before they run.

To expose the engrim_* tools to Codex, enable the optional MCP server:

engrim setup --codex-mcp
# Equivalent: engrim setup --codex --codex-mcp

This uses Codex's supported codex mcp add command and preserves unrelated config.toml settings. Use /mcp to verify the server, then open a new Codex session so the hooks and guidance load.

engrim uninstall --codex removes only Engrim hooks, the managed guidance block, and the mcp_servers.engrim entry. It preserves all other Codex settings and instructions.

๐Ÿค– GitHub Copilot CLI

engrim setup --copilot
  • Writes ~/.copilot/hooks/engrim.json (respects $COPILOT_HOME), a file engrim owns outright, so your other hook files are never rewritten.

    • sessionStart โ†’ the memory pack is returned as additionalContext and injected into the new session before your first prompt.

    • userPromptSubmitted โ†’ the prompt lands in the flight-recorder log. Copilot CLI discards the output of command hooks on this event, so this hook injects nothing.

    • agentStop โ†’ assistant messages are read from the supplied events.jsonl transcript path and added to the flight-recorder log.

  • Registers mcpServers.engrim (engrim serve --mcp) in ~/.copilot/mcp-config.json, exposing the engrim_* tools. Records the agent writes are attributed to copilot automatically.

  • Configures engrim statusline in ~/.copilot/settings.json, providing live curated, logged, in-play, and clear-safety counts. An existing custom status line is preserved.

  • Appends a usage note to ~/.copilot/copilot-instructions.md.

Hook entries use Copilot's exec + args form, which runs the binary directly with no shell in between, so a path containing spaces or backslashes needs no quoting. Hook configuration is read at startup: open a new session after setup.

Copilot can flush the final assistant event shortly after agentStop begins, so Engrim polls briefly and recovers any later tail during the next session start. The event-file schema is not a public Copilot compatibility contract. Engrim detects incompatible known records without putting transcript content in diagnostics, warns once through the hook, and reports the persistent issue through engrim doctor until a compatible pass succeeds.

๐ŸŸฉ OpenCode

engrim setup --opencode

OpenCode has no shell hooks, so engrim ships as a plugin plus an MCP server:

  • Writes ~/.config/opencode/plugins/engrim.js (respects $XDG_CONFIG_HOME). The plugin calls engrim hook --agent opencode at each lifecycle moment:

    • session boot โ†’ memory pack is injected into system prompt (once per session, and again after compaction);

    • every prompt โ†’ minder pulls the few records relevant to that message and attaches them to that user message, never to the system prompt, so the provider's prompt cache (vLLM prefix cache, Anthropic prompt caching) stays warm across turns;

    • session idle โ†’ session's new user/assistant turns land in flight-recorder log (idempotent, keyed on OpenCode message ids);

    • compaction โ†’ compaction prompt is told that durable memory lives in engrim and to list uncaptured decisions so they get engrim_add-ed.

  • Registers mcp.engrim (engrim serve --mcp) in ~/.config/opencode/opencode.json, exposing engrim_* tools to the agent.

  • Appends usage note to ~/.config/opencode/AGENTS.md.

OpenCode Transcript Store vs. Engrim

opencode.db stores raw transcripts (sessions, messages, parts) for OpenCode alone. Engrim provides the universal cross-session memory layer:

  • Cross-Harness Continuity: Switch between OpenCode, Claude Code, Codex CLI, Cursor, or Antigravity on the same codebase from one ~/.engrim/memory.db.

  • Curated Episodic State: Preserves typed records (decision, fact, state) that survive /new, session deletion, and compaction.

  • Model-Driven Retrieval: Hybrid FTS5 + vector recall (engrim_recall) and per-prompt minding with cross-agent provenance (origin_agent).

๐Ÿ™ GitHub Agentic Workflows (gh-aw)

See examples/gh-aw/ for engrim inside GitHub Agentic Workflows: memory across runs through artifacts and engrim merge, and a continue-as-clear restart instead of auto-compaction.

All Platforms

engrim setup --all

--all configures Codex hooks and guidance but does not opt in to the Codex MCP server. Add --codex-mcp explicitly when you want that tool interface. (Use --dry-run with any setup command to preview changes without writing to disk).


4. Empirical Proof (The 105-Session Case Study)

Tested across 105 continuous sessions on a 50,000-line algorithmic trading system. Zero regressions across 186 unit tests, zero context loss across model switches.

In production testing on an active algorithmic trading codebase running real capital:

  • Over 153,000 tokens of work across days of architecture, parameter tuning, and debugging was consolidated into an active memory pack under 1,000 tokens (<1% of the context window).

  • That is a 99%+ cut in reloaded context cost on every session restart.

  • Seamlessly switched between Google Antigravity CLI, Claude Code, and Cursor MCP on identical repos with zero model drift or architectural regression.


5. Agent Provenance Tracking

When multiple agents collaborate on a single codebase, provenance matters. engrim records the origin of every memory entry with the origin_agent field:

  • Allowed values: antigravity, claude-code, cursor, codex, opencode, copilot, cli, or user.

  • Automatically populated based on the active hook, MCP client, or CLI session.

  • Subtly surfaced in engrim context and engrim list:

๐Ÿง  engrim ยท memory restored for this project: you don't have to re-explain ยท /workspace
  18 of 54 curated records loaded (~3850 chars) ยท the rest one `recall` away

[DECISION]
- #961 [DECISION] (via Antigravity): Inverted stop loss matrix for high volatility  (risk, execution)
- #942 [DECISION] (via Claude Code): Switched primary database from MongoDB to PostgreSQL  (db, schema)
- #910 [DECISION] (via Cursor): Standardized on Pydantic v2 schemas across API boundaries  (api, types)

Existing databases are non-destructively migrated on first access via ALTER TABLE memories ADD COLUMN origin_agent TEXT.


6. Hardened Model Context Protocol (MCP) Server

Launch the zero-dependency, JSON-RPC 2.0 stdio MCP server:

engrim serve --mcp
# or: engrim mcp

stdout is strictly reserved for JSON-RPC messages, redirecting all diagnostic logs to stderr.

Core MCP Tools Exposed:

Tool

Signature

Purpose

engrim_recall

(query: str, project: str = "auto", k: int = 5, type: str = None, tag: str = None)

Search project memory using hybrid ranking (optionally filter by type or tag).

engrim_add

(type: str, summary: str, detail: str = None, tags: list[str] = [])

Write a durable memory record persisted across sessions.

engrim_context

(project: str = "auto", budget: int = 4000)

Retrieve the session-boot memory pack within a character budget.

engrim_review

(project: str = "auto")

Check uncaptured decisions from transcript logs before clearing.

engrim_review returns safe_to_clear: null (unknown) when the project has no transcript log. With logged turns, it evaluates whether uncaptured architectural decisions exist before a developer runs /clear.


7. CLI Reference

Command

Usage

Description

engrim add

engrim add -t decision -s "..." [--origin-agent agy]

Insert memory record (types: decision, fact, feedback, state, user, reference).

engrim recall

engrim recall -q "database" [--tag auth]

Ranked hybrid recall for the project (--tag filters by tag; --log searches raw turns).

engrim context

engrim context [-b 4000]

Priority-ordered, budget-capped session-boot pack.

engrim doctor

engrim doctor [--fix] [--json]

Comprehensive health & environment diagnostic across SQLite, semantic engine, and hooks (--fix auto-repairs paths).

engrim hook

engrim hook --agent agy --event boot

Agent lifecycle hook runner for Claude Code, Antigravity, Codex, Copilot CLI, and OpenCode (--agent opencode --event boot|prompt|stop).

engrim setup

engrim setup [--agy|--claude|--cursor|--codex|--codex-mcp|--opencode|--copilot|--all] [--strict]

Universal multi-agent environment configuration. --codex-mcp implies --codex; --strict wires gate mode.

engrim serve

engrim serve --mcp

Start stdio MCP server for agent integrations.

engrim review

engrim review [--strict]

"Safe to clear" coverage check: scans logs for uncurated decisions (--strict exits 2 if uncaptured).

engrim prune

engrim prune [--keep-days <N> | --all | --vacuum]

Purge old transcript logs and VACUUM the SQLite DB (opt-in retention; off by default).

engrim list

engrim list [-k 20] [--tag auth]

List recent memories for the current project (supports --tag).

engrim project

engrim project [-p PROJECT | --global | --all] [--json]

Records, active count and last write for one project tag (the current one by default), or every tag with --all.

engrim projects

engrim projects [--json]

Every project's counts: the same as engrim project --all.

engrim supersede

engrim supersede --id 12 --status superseded

Mark a record superseded without erasing history.

engrim retire

engrim retire [--all] [--dry-run] [--json]

Mark active resume-pointer record(s) done once their work is finished (never erases).

engrim sync

engrim sync [DIR]

Mirror markdown memories into the store (idempotent seed-once).

engrim merge

engrim merge OTHER.db [--dry-run]

Fold another store's records into this one (content-keyed, idempotent; retirements carry over).

engrim backup

engrim backup COPY.db [--force] [--json]

Consistent copy of the store via SQLite's online backup API (safe while agents hold it open).


8. Continue-As-Clear Workflow

  1. Capture as you work: Whenever a major decision or architectural constraint is established, save it to memory. Connected agents do this automatically via engrim_add, or you can run engrim add.

  2. Use resume-pointer: Before ending a session or clearing, add a record tagged resume-pointer describing the immediate next task. The newest pointer is pinned under [โ–ถ RESUME HERE] at the top of the next session's boot pack. When that work is done, engrim retire marks the pointer done so finished tasks never lead later packs.

  3. Verify with engrim review: Check that all recent decisions are captured before clearing.

  4. Clear freely (/clear): The session window is wiped clean. engrim automatically re-injects the active memory pack on the next prompt or invocation with zero context loss.


9. Open Core Architecture: Local vs. Enterprise

Engrim maintains a strict, transparent architectural boundary between open-source single-developer productivity and enterprise infrastructure:

Capability

Engrim Open Source (Free, MIT)

Engrim Enterprise (Commercial In-VPC)

Target User

Individual developers & local coding agents

Engineering teams & autonomous CI/CD pipelines

Storage Substrate

100% local SQLite WAL (~/.engrim/memory.db)

In-VPC high-throughput state collector & team repository

Retrieval Engine

Hybrid FTS5 bm25 + model2vec (CPU, ~30ms)

Organization-wide semantic search & multi-tenant indexing

Agent Support

Antigravity, Claude Code, Cursor, Codex, Copilot CLI, OpenCode

Distributed container fleets & autonomous CI state-machines

Integrity & Health

engrim doctor diagnostic & self-healing hooks

Pre-commit AST invariant arbiter & deterministic validation

Security & Compliance

POSIX 0600 owner permissions, offline

Secret & PII scrubber, cryptographic Merkle compliance ledger

Collaboration

Local merge & backup (engrim merge/backup)

Multi-developer team memory federation & Linear-grade web UI


10. How Does Engrim Compare?

  • vs gbrain: While gbrain is a provider-agnostic memory tool, engrim sets itself apart with a lightweight, local-first SQLite architecture. It requires zero cloud infrastructure, no complex daemon setup, and operates entirely on CPU.

  • vs OpenCode & Codex Internal Stores: Their built-in SQLite databases store transcripts (sessions, raw message parts, lossy compaction summaries) locked to one tool. engrim is a cross-tool episodic memory engine that tracks provenance across all your tools. With the OpenCode plugin, engrim serves as the durable memory layer rather than competing with it.

  • vs Pi / Personal Companions: Companion tools focus on social conversation history. engrim is engineered specifically for software engineering projects, preserving architectural decisions, invariant constraints, and technical state.


11. Security & Privacy

  • 100% Local & Offline: All memory records and flight-recorder logs reside in your local SQLite file (~/.engrim/memory.db). No telemetry, no cloud sync, no tracking.

  • CPU-Only Vector Inference: Uses model2vec for static embeddings (~30ms load time, no GPU required, runs on CPU). Can run pure-lexical (ENGRIM_EMBED=off) for zero extra dependencies.

  • POSIX Owner Permissions: Databases are created with restricted owner-only permissions (0600).

  • Git Safe: *.db is gitignored by default; memories are never accidentally committed to public version control.


12. About the Project & Author

Engrim was created by Tim Gordon (@timgordontg).

Tim built Engrim to establish the definitive open-source standard for agent episodic memory, giving developers complete freedom from vendor lock-in.

For enterprise licensing, advisory, pilot deployments, or custom agent integrations, reach out at timgordontg@gmail.com.


13. License

MIT ยฉ 2026 Tim Gordon.

Available Tools

4 tools
engrim_addA

Write operation: Save a durable memory record to local SQLite storage so it persists across sessions and agent restarts. Call this whenever a non-trivial architectural choice, durable fact, user constraint, or state milestone is established. Appends a new record to the project memory database.

ParametersJSON Schema
NameRequiredDescriptionDefault
tagsNoOptional list of categorical string tags (e.g. ['auth', 'api']).
typeYesCategory of memory: 'decision' (architectural choices), 'fact' (project truths), 'feedback' (user preferences), 'state' (progress milestones), 'reference' (external links), or 'user' (durable user constraints).
detailNoOptional detailed explanation, context, trade-offs, or rationale.
globalNoIf true, stores in the global user-layer (~/.engrim/memory.db) accessible across all projects.
projectNoProject identifier tag; 'auto' infers from current working directory repository root.auto
summaryYesConcise one-line headline summarizing the record.
origin_agentNoOrigin agent identifier for provenance tracking.

Output Schema

ParametersJSON Schema
NameRequiredDescription
idYes
typeYes
projectYes
summaryYes
origin_agentYes

TDQS

A3.8/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 behavioral burden. It discloses persistence across sessions/restarts, append-only behavior, and local SQLite storage. However, the final sentence 'Appends a new record to the project memory database' ignores the `global` parameter which can redirect storage to a user-layer database, making the statement slightly incomplete or misleading.

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, each carrying distinct value: what it does, when to call it, and append behavior. No filler or redundancy, and the key operation is 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?

For a simple write tool with a full schema and output schema present, the description covers the essential aspects: operation type, persistence, and invocation conditions. The only notable omission is not acknowledging the `global` storage option, but that is documented in the schema, so the description is still sufficiently complete.

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 coverage is 100% โ€“ every parameter (type, summary, tags, detail, global, project, origin_agent) is described in the schema. The description adds no additional parameter semantics, which is appropriate given the high coverage; baseline 3 applies.

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?

Description states a specific verb and resource: 'Save a durable memory record to local SQLite storage' and opens with 'Write operation', which contrasts with read-like siblings. However, it does not explicitly name sibling tools or explain how this differs from engrim_context or engrim_recall beyond the write semantics.

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?

Provides explicit trigger conditions: 'Call this whenever a non-trivial architectural choice, durable fact, user constraint, or state milestone is established.' It does not mention when not to use it or name alternative tools like engrim_recall for retrieval, so it falls short of a full 5 but is clear on the primary use case.

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

engrim_contextA

Read-only query: Return this project's curated session-boot memory pack (high-signal architectural decisions, active constraints, and conventions) to orient an agent at the start of a session or after clearing context. Safe to call repeatedly with zero mutations or external side effects. Records are prioritized and truncated to strictly fit within the specified character budget.

ParametersJSON Schema
NameRequiredDescriptionDefault
budgetNoMaximum character budget for the returned memory pack (default 4000). Prioritizes active decisions and constraints.
projectNoProject identifier tag; 'auto' infers from current working directory repository root.auto

Output Schema

ParametersJSON Schema
NameRequiredDescription
charsYes
loadedYes
projectYes
recordsYes
total_activeYes

TDQS

A4.5/5.0
Behavior5/5

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

Despite no annotations, the description transparently declares read-only, zero side effects, and prioritization/truncation behavior. This fully satisfies the disclosure burden for a query 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?

Two concise sentences, front-loaded with the read-only guarantee and the purpose. No filler; each clause serves a distinct role.

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 an output schema exists and the tool is a simple query with two optional parameters, the description covers purpose, safety, and behavior. Nothing essential is missing.

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 already covers both parameters (100% coverage), so description adds little beyond what the schema states. It reinforces the budget behavior but does not provide new information.

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?

Description states a specific action ('Return') on a specific resource ('curated session-boot memory pack') and clearly distinguishes from sibling tools by focusing on boot-time orientation. It is unambiguous about what the tool returns and its purpose.

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?

Provides explicit context for when to use: 'at the start of a session or after clearing context.' Does not name alternatives or exclusions, but the use case is clear enough to route an agent appropriately.

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

engrim_recallA

Read-only query: Search this project's engrim memory for records relevant to a query using hybrid BM25 keyword and semantic vector ranking. Use before starting non-trivial work to recall prior architectural decisions, technical facts, user feedback, and project state. Safe to invoke repeatedly with zero mutations or side effects.

ParametersJSON Schema
NameRequiredDescriptionDefault
kNoMaximum number of records to return (default 5).
tagNoOptional filter by tag name (e.g. 'auth', 'database').
typeNoOptional filter by memory type ('decision', 'fact', 'feedback', 'state', 'reference', 'user').
queryYesFree-text topic or search keywords.
projectNoProject identifier tag; 'auto' infers from current working directory repository root.auto
include_staleNoInclude superseded or retired records alongside active records.

Output Schema

ParametersJSON Schema
NameRequiredDescription
countYes
projectYes
recordsYes

TDQS

A4.5/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 and does so well: it declares read-only behavior, zero mutations, no side effects, safe repeated invocation, and explains the hybrid BM25 plus semantic vector ranking mechanism. This goes beyond a simple 'search' claim and gives the agent confidence about side-effect safety.

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 short, dense sentences front-load the core purpose, then add usage timing, recalled content types, and safety guarantees. Every sentence earns its place with no fluff or repetition.

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?

The presence of an output schema covers return-value details, while the description covers purpose, ranking behavior, safe usage, and intended timing. Combined with complete parameter documentation, the agent has everything needed to decide when and how to invoke the tool.

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 already documents all six parameters with 100% coverage, including defaults and enums. The description adds high-level context about ranking, but no parameter-specific semantics beyond what the schema provides, so a baseline score of 3 is appropriate.

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 'Read-only query: Search this project's engrim memory for records relevant to a query,' giving a specific verb, resource, and operation. It clearly distinguishes itself from sibling tools like engrim_add and engrim_review by framing recall as a non-mutating search.

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?

It explicitly advises using the tool before starting non-trivial work to recall architectural decisions, facts, feedback, and project state. It does not explicitly contrast with alternatives or state when not to use it, but the intended context is clear enough.

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

engrim_reviewA

Read-only check: Inspect conversation and flight recorder history before clearing context to surface recent architectural decisions not yet saved to curated memory. Safe to call with no side effects. Returns heuristic verdict (safe_to_clear: true/false/null) and uncaptured candidate records.

ParametersJSON Schema
NameRequiredDescriptionDefault
projectNoProject identifier tag; 'auto' infers from current working directory repository root.auto

Output Schema

ParametersJSON Schema
NameRequiredDescription
messageYes
projectYes
uncapturedYes
safe_to_clearYes
scanned_turnsYes
active_curatedYes
total_log_turnsYes
uncaptured_countYes

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations supplied, the description takes full responsibility for behavior. It explicitly discloses read-only status, 'no side effects', and a heuristic verdict that may be null, plus the uncaptured-candidate output. This gives an agent an accurate safety and expectation model.

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 tightly packed sentences, with the safety qualifier and primary action front-loaded before the return-value detail. Every clause earns its place.

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 single-optional-parameter tool with an output schema, the description covers purpose, safety, and return-value shape. It could be slightly stronger by explicitly routing away from sibling tools like engrim_recall or engrim_add, but the core call is complete.

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 100% and the only optional parameter, project, already has a clear description including the 'auto' inference behavior. The tool description adds no additional parameter information, but none is needed because the schema carries it.

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?

Description opens with a specific verb and resource ('Inspect conversation and flight recorder history') and states the exact purpose: surface architectural decisions not yet saved before clearing context. It differentiates from sibling tools by its read-only review/heuristic-verdict role rather than recall/context/add.

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 phrase 'before clearing context' gives a concrete trigger for when to invoke the tool. It does not explicitly name comparison alternatives or when-not-to-use conditions, but the intended workflow position is clear.

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.

  1. 1 tool updatev1.4.11
    • Changedengrim_add2 fields changed
      • changedInput schema / properties / origin_agent / description
        Previous value: -"Origin agent identifier for provenance tracking ('antigravity', 'claude-code', 'cursor', 'cli', 'user')."New value: +"Origin agent identifier for provenance tracking."
      • changedInput schema / properties / origin_agent / enum
        Previous value: -[
        -  "antigravity",
        -  "claude-code",
        -  "cursor",
        -  "opencode",
        -  "cli",
        -  "user"
        -]New value: +[
        +  "antigravity",
        +  "claude-code",
        +  "cursor",
        +  "codex",
        +  "opencode",
        +  "copilot",
        +  "cli",
        +  "user"
        +]
  2. 4 tool updatesv1.4.6
    • Changedengrim_add2 fields changed
      • changedInput schema / properties / origin_agent / enum
        Previous value: -[
        -  "antigravity",
        -  "claude-code",
        -  "cursor",
        -  "cli",
        -  "user"
        -]New value: +[
        +  "antigravity",
        +  "claude-code",
        +  "cursor",
        +  "opencode",
        +  "cli",
        +  "user"
        +]
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
        +  "description": "Confirmation identifying the stored record.",
        +  "properties": {
        +    "id": {
        +      "type": "integer"
        +    },
        +    "origin_agent": {
        +      "type": "string"
        +    },
        +    "project": {
        +      "type": "string"
        +    },
        +    "summary": {
        +      "type": "string"
        +    },
        +    "type": {
        +      "type": "string"
        +    }
        +  },
        +  "required": [
        +    "id",
        +    "type",
        +    "project",
        +    "summary",
        +    "origin_agent"
        +  ],
        +  "type": "object"
        +}
    • Changedengrim_context1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
        +  "description": "Curated session-boot pack within the character budget.",
        +  "properties": {
        +    "chars": {
        +      "type": "integer"
        +    },
        +    "loaded": {
        +      "type": "integer"
        +    },
        +    "project": {
        +      "type": "string"
        +    },
        +    "records": {
        +      "items": {
        +        "type": "object"
        +      },
        +      "type": "array"
        +    },
        +    "total_active": {
        +      "type": "integer"
        +    }
        +  },
        +  "required": [
        +    "project",
        +    "loaded",
        +    "total_active",
        +    "chars",
        +    "records"
        +  ],
        +  "type": "object"
        +}
    • Changedengrim_recall1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
        +  "description": "Ranked memory records matching the query.",
        +  "properties": {
        +    "count": {
        +      "type": "integer"
        +    },
        +    "project": {
        +      "type": "string"
        +    },
        +    "records": {
        +      "items": {
        +        "type": "object"
        +      },
        +      "type": "array"
        +    }
        +  },
        +  "required": [
        +    "project",
        +    "count",
        +    "records"
        +  ],
        +  "type": "object"
        +}
    • Changedengrim_review1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
        +  "description": "Coverage verdict plus uncaptured decision candidates (safe_to_clear is null when no transcript log exists).",
        +  "properties": {
        +    "active_curated": {
        +      "type": "integer"
        +    },
        +    "message": {
        +      "type": "string"
        +    },
        +    "project": {
        +      "type": "string"
        +    },
        +    "safe_to_clear": {
        +      "type": [
        +        "boolean",
        +        "null"
        +      ]
        +    },
        +    "scanned_turns": {
        +      "type": "integer"
        +    },
        +    "total_log_turns": {
        +      "type": "integer"
        +    },
        +    "uncaptured": {
        +      "items": {
        +        "type": "object"
        +      },
        +      "type": "array"
        +    },
        +    "uncaptured_count": {
        +      "type": "integer"
        +    }
        +  },
        +  "required": [
        +    "project",
        +    "total_log_turns",
        +    "scanned_turns",
        +    "active_curated",
        +    "safe_to_clear",
        +    "uncaptured_count",
        +    "uncaptured",
        +    "message"
        +  ],
        +  "type": "object"
        +}
  3. 4 tool updatesv1.4.2
    • Changedengrim_add7 fields changed
      • changedInput schema / properties / detail / description
        Previous value: -"Optional longer body / the why."New value: +"Optional detailed explanation, context, trade-offs, or rationale."
      • changedInput schema / properties / global / description
        Previous value: -"Write to the global user-layer that loads in every project."New value: +"If true, stores in the global user-layer (~/.engrim/memory.db) accessible across all projects."
      • changedInput schema / properties / origin_agent / description
        Previous value: -"Origin agent identifier for provenance tracking."New value: +"Origin agent identifier for provenance tracking ('antigravity', 'claude-code', 'cursor', 'cli', 'user')."
      • addedInput schema / properties / project / description
        Added value: +"Project identifier tag; 'auto' infers from current working directory repository root."
      • changedInput schema / properties / summary / description
        Previous value: -"One-line headline for the record."New value: +"Concise one-line headline summarizing the record."
      • addedInput schema / properties / tags / description
        Added value: +"Optional list of categorical string tags (e.g. ['auth', 'api'])."
      • addedInput schema / properties / type / description
        Added value: +"Category of memory: 'decision' (architectural choices), 'fact' (project truths), 'feedback' (user preferences), 'state' (progress milestones), 'reference' (external links), or 'user' (durable user constraints)."
    • Changedengrim_context3 fields changed
      • changedInput schema / properties / budget / description
        Previous value: -"Character budget for the pack."New value: +"Maximum character budget for the returned memory pack (default 4000). Prioritizes active decisions and constraints."
      • addedInput schema / properties / project / description
        Added value: +"Project identifier tag; 'auto' infers from current working directory repository root."
      • addedInput schema / required
        Added value: +[]
    • Changedengrim_recall6 fields changed
      • changedInput schema / properties / include_stale / description
        Previous value: -"Include superseded/archived records."New value: +"Include superseded or retired records alongside active records."
      • changedInput schema / properties / k / description
        Previous value: -"Max records to return."New value: +"Maximum number of records to return (default 5)."
      • changedInput schema / properties / project / description
        Previous value: -"Project tag; 'auto' = current working directory."New value: +"Project identifier tag; 'auto' infers from current working directory repository root."
      • changedInput schema / properties / query / description
        Previous value: -"Free-text topic to search for."New value: +"Free-text topic or search keywords."
      • changedInput schema / properties / tag / description
        Previous value: -"Optional: filter records by tag (e.g. 'auth')."New value: +"Optional filter by tag name (e.g. 'auth', 'database')."
      • changedInput schema / properties / type / description
        Previous value: -"Optional: restrict to one record type."New value: +"Optional filter by memory type ('decision', 'fact', 'feedback', 'state', 'reference', 'user')."
    • Changedengrim_review2 fields changed
      • changedInput schema / properties / project / description
        Previous value: -"Project tag; 'auto' = current working directory."New value: +"Project identifier tag; 'auto' infers from current working directory repository root."
      • addedInput schema / required
        Added value: +[]
  4. 4 tool updatesv0.1.0
    • First observedengrim_add
    • First observedengrim_context
    • First observedengrim_recall
    • First observedengrim_review

TDQS

A4.2/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: context retrieval, semantic search, writing records, and pre-clear review. There is no overlap between reading curated context, searching all memory, adding new records, or checking for unsaved decisions.

Naming Consistency4/5

All tools share the engrim_ prefix and use short, consistent verb-like suffixes (context, recall, add, review). Minor deviation: 'context' and 'recall' are nouns/verbs rather than a strict verb_noun pattern, but the naming is predictable and readable.

Tool Count5/5

Four tools is a well-scoped set for a memory server: read curated context, search all memory, write new memory, and review unsaved history. Each tool earns its place with no redundancy.

Completeness4/5

The core memory lifecycle is covered: add, recall, context, and pre-clear review. A minor gap is the lack of explicit update/delete operations for correcting or removing stale records, but agents can work around this by adding superseding records.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    A
    maintenance
    Persistent memory for any AI assistant. Zero token cost until recall. Stores memories in local SQLite, ranks by 6-factor scoring, returns results 79% smaller than JSON. Works with Claude, ChatGPT, Grok, Cursor, Windsurf, and any MCP client.
    53
    Apache 2.0
  • A
    license
    A
    quality
    D
    maintenance
    Governed memory for coding agents with trust lifecycle, conflict detection, staleness tracking, and health scoring. SQLite + FTS5, zero infrastructure. Works with Claude Code, Cursor, Codex, Windsurf.
    13
    35 PyPI
    4
    MIT
  • A
    license
    A
    quality
    A
    maintenance
    Local-first memory engine for AI-agent teams: private/team/project ACL, associative recall, and federated sync across nodes. One SQLite file, no LLM required.
    12
    6
    Apache 2.0