engrim
This server provides a persistent, project-scoped episodic memory layer for AI coding agents, letting them store, retrieve, and review durable project knowledge across sessions and tools.
engrim_recall: Search project memory using hybrid BM25 keyword + semantic vector ranking, with optional filters by type, tag, and project; can include superseded/retired records.
engrim_context: Retrieve a prioritized, budget-capped session-boot memory pack to orient an agent at session start or after context clearing.
engrim_add: Write durable memory records (decisions, facts, feedback, state, references, user constraints) with optional detail, tags, project scope, global scope, and origin-agent provenance.
engrim_review: Inspect flight-recorder/transcript logs before clearing context to surface uncaptured architectural decisions and get a safe-to-clear verdict (true/false/null when no log exists).
Provides memory integration for Windsurf (by Codeium), allowing agents to save and recall project context, decisions, and user constraints across sessions.
Allows memory persistence across GitHub Actions workflow runs via artifacts and engrim merge, enabling continuation without context loss.
engrim
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 | Continue-As-Clear: Clear anytime ( |
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 ( |
Hook Reliability | Silent Failures: Moving across machines or OSes silently breaks hardcoded binary paths with no error message. | Self-Healing Diagnostics: |
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 |
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 --> LOGBoot: When your agent starts or a prompt is submitted,
engriminjects the top-priority memory pack (~4k chars) into the agent's context, leading with[โถ RESUME HERE].Capture: As the agent works, it records architectural decisions via MCP (
engrim_add) or lifecycle hooks automatically, tracking theorigin_agentprovenance.Recall & Minder: Hybrid lexical (
bm25) + vector (model2vec) search retrieves relevant records on demand in ~30ms without slowing down the agent.Continue-As-Clear: When context bloats or the model drifts, type
/clear. The next session boots frommemory.dbwith zero memory loss.
3. Multi-Agent Quickstart
Installation
pip install engrimAuto-Detection (Recommended)
Run engrim setup without arguments. It automatically detects installed environments on your machine and configures them all:
engrim setupIf
~/.geminiexists $\rightarrow$ wires Antigravity lifecycle hooks, skill, and MCP server.If
~/.claudeexists $\rightarrow$ wires Claude Code SessionStart, Stop, status line, and CLAUDE.md.If
~/.cursorexists $\rightarrow$ generates and merges Cursor MCP configuration.If
~/.codexexists $\rightarrow$ wires Codex CLI native command hooks and managed globalAGENTS.mdguidance. MCP stays opt-in.If
~/.config/opencodeexists $\rightarrow$ writes OpenCode plugin, registers MCP server, and addsAGENTS.mdnotes.If
~/.copilotexists $\rightarrow$ wires Copilot CLI hooks and the Engrim status line, registers the MCP server, and addscopilot-instructions.mdnotes.
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 --jsonReal 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 --agyConfigures
~/.gemini/config/hooks.jsonto executeengrim hook --agent agy --event bootonPreInvocationandengrim hook --agent agy --event stoponStop.Deploys canonical Antigravity skill to
~/.gemini/config/skills/engrim/SKILL.md.Registers MCP server in
~/.gemini/antigravity-cli/mcp_config.jsonand~/.gemini/config/mcp_config.json.
๐ฃ Claude Code
engrim setup --claudeWires
SessionStart,SessionEnd,Stop, andUserPromptSubmithooks 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 --cursorAdds
engrimto~/.cursor/mcp.jsonrunningengrim serve --mcp.
For Windsurf, add engrim to ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"engrim": {
"command": "engrim",
"args": ["serve", "--mcp"]
}
}
}๐ป Codex CLI
engrim setup --codexWires
SessionStart,SessionEnd,Stop, andUserPromptSubmitcommand hooks in$CODEX_HOME/hooks.json(~/.codexby 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-emptyAGENTS.override.mdis not modified, but setup warns that it shadows the guidance.Calls the local
engrimCLI directly, so MCP is not required. Hooks must be reviewed and trusted with Codex's/hookscommand before they run.
To expose the engrim_* tools to Codex, enable the optional MCP server:
engrim setup --codex-mcp
# Equivalent: engrim setup --codex --codex-mcpThis 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 --copilotWrites
~/.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 asadditionalContextand 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 suppliedevents.jsonltranscript path and added to the flight-recorder log.
Registers
mcpServers.engrim(engrim serve --mcp) in~/.copilot/mcp-config.json, exposing theengrim_*tools. Records the agent writes are attributed tocopilotautomatically.Configures
engrim statuslinein~/.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 --opencodeOpenCode 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 callsengrim hook --agent opencodeat 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, exposingengrim_*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, oruser.Automatically populated based on the active hook, MCP client, or CLI session.
Subtly surfaced in
engrim contextandengrim 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 mcpstdout is strictly reserved for JSON-RPC messages, redirecting all diagnostic logs to stderr.
Core MCP Tools Exposed:
Tool | Signature | Purpose |
|
| Search project memory using hybrid ranking (optionally filter by type or tag). |
|
| Write a durable memory record persisted across sessions. |
|
| Retrieve the session-boot memory pack within a character budget. |
|
| 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 |
|
| Insert memory record (types: |
|
| Ranked hybrid recall for the project ( |
|
| Priority-ordered, budget-capped session-boot pack. |
|
| Comprehensive health & environment diagnostic across SQLite, semantic engine, and hooks ( |
|
| Agent lifecycle hook runner for Claude Code, Antigravity, Codex, Copilot CLI, and OpenCode ( |
|
| Universal multi-agent environment configuration. |
|
| Start stdio MCP server for agent integrations. |
|
| "Safe to clear" coverage check: scans logs for uncurated decisions ( |
|
| Purge old transcript logs and VACUUM the SQLite DB (opt-in retention; off by default). |
|
| List recent memories for the current project (supports |
|
| Records, active count and last write for one project tag (the current one by default), or every tag with |
|
| Every project's counts: the same as |
|
| Mark a record superseded without erasing history. |
|
| Mark active |
|
| Mirror markdown memories into the store (idempotent seed-once). |
|
| Fold another store's records into this one (content-keyed, idempotent; retirements carry over). |
|
| Consistent copy of the store via SQLite's online backup API (safe while agents hold it open). |
8. Continue-As-Clear Workflow
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 runengrim add.Use
resume-pointer: Before ending a session or clearing, add a record taggedresume-pointerdescribing 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 retiremarks the pointerdoneso finished tasks never lead later packs.Verify with
engrim review: Check that all recent decisions are captured before clearing.Clear freely (
/clear): The session window is wiped clean.engrimautomatically 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 ( | In-VPC high-throughput state collector & team repository |
Retrieval Engine | Hybrid FTS5 bm25 + | 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 |
| Pre-commit AST invariant arbiter & deterministic validation |
Security & Compliance | POSIX | Secret & PII scrubber, cryptographic Merkle compliance ledger |
Collaboration | Local 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,
engrimsets 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.
engrimis 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.
engrimis 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
model2vecfor 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:
*.dbis gitignored by default; memories are never accidentally committed to public version control.
12. About the Project & Author
Engrim was created by Tim Gordon (@timgordontg).
Website: engrim.dev
GitHub: github.com/timgordontg/engrim
LinkedIn: linkedin.com/in/timgordon1
Email: timgordontg@gmail.com
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 toolsengrim_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.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional list of categorical string tags (e.g. ['auth', 'api']). | |
| type | Yes | Category of memory: 'decision' (architectural choices), 'fact' (project truths), 'feedback' (user preferences), 'state' (progress milestones), 'reference' (external links), or 'user' (durable user constraints). | |
| detail | No | Optional detailed explanation, context, trade-offs, or rationale. | |
| global | No | If true, stores in the global user-layer (~/.engrim/memory.db) accessible across all projects. | |
| project | No | Project identifier tag; 'auto' infers from current working directory repository root. | auto |
| summary | Yes | Concise one-line headline summarizing the record. | |
| origin_agent | No | Origin agent identifier for provenance tracking. |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| type | Yes | |
| project | Yes | |
| summary | Yes | |
| origin_agent | Yes |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| budget | No | Maximum character budget for the returned memory pack (default 4000). Prioritizes active decisions and constraints. | |
| project | No | Project identifier tag; 'auto' infers from current working directory repository root. | auto |
Output Schema
| Name | Required | Description |
|---|---|---|
| chars | Yes | |
| loaded | Yes | |
| project | Yes | |
| records | Yes | |
| total_active | Yes |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Maximum number of records to return (default 5). | |
| tag | No | Optional filter by tag name (e.g. 'auth', 'database'). | |
| type | No | Optional filter by memory type ('decision', 'fact', 'feedback', 'state', 'reference', 'user'). | |
| query | Yes | Free-text topic or search keywords. | |
| project | No | Project identifier tag; 'auto' infers from current working directory repository root. | auto |
| include_stale | No | Include superseded or retired records alongside active records. |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| project | Yes | |
| records | Yes |
TDQS
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.
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.
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.
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.
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.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Project identifier tag; 'auto' infers from current working directory repository root. | auto |
Output Schema
| Name | Required | Description |
|---|---|---|
| message | Yes | |
| project | Yes | |
| uncaptured | Yes | |
| safe_to_clear | Yes | |
| scanned_turns | Yes | |
| active_curated | Yes | |
| total_log_turns | Yes | |
| uncaptured_count | Yes |
TDQS
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.
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.
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.
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.
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.
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 tool update
v1.4.11- Changed
engrim_add2 fields changed- changed
Input schema / properties / origin_agent / descriptionPrevious value: -"Origin agent identifier for provenance tracking ('antigravity', 'claude-code', 'cursor', 'cli', 'user')."New value: +"Origin agent identifier for provenance tracking." - changed
Input schema / properties / origin_agent / enumPrevious value: -[ - "antigravity", - "claude-code", - "cursor", - "opencode", - "cli", - "user" -]New value: +[ + "antigravity", + "claude-code", + "cursor", + "codex", + "opencode", + "copilot", + "cli", + "user" +]
4 tool updates
v1.4.6- Changed
engrim_add2 fields changed- changed
Input schema / properties / origin_agent / enumPrevious value: -[ - "antigravity", - "claude-code", - "cursor", - "cli", - "user" -]New value: +[ + "antigravity", + "claude-code", + "cursor", + "opencode", + "cli", + "user" +] - changed
Output 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" +}
- Changed
engrim_context1 field changed- changed
Output 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" +}
- Changed
engrim_recall1 field changed- changed
Output 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" +}
- Changed
engrim_review1 field changed- changed
Output 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" +}
4 tool updates
v1.4.2- Changed
engrim_add7 fields changed- changed
Input schema / properties / detail / descriptionPrevious value: -"Optional longer body / the why."New value: +"Optional detailed explanation, context, trade-offs, or rationale." - changed
Input schema / properties / global / descriptionPrevious 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." - changed
Input schema / properties / origin_agent / descriptionPrevious value: -"Origin agent identifier for provenance tracking."New value: +"Origin agent identifier for provenance tracking ('antigravity', 'claude-code', 'cursor', 'cli', 'user')." - added
Input schema / properties / project / descriptionAdded value: +"Project identifier tag; 'auto' infers from current working directory repository root." - changed
Input schema / properties / summary / descriptionPrevious value: -"One-line headline for the record."New value: +"Concise one-line headline summarizing the record." - added
Input schema / properties / tags / descriptionAdded value: +"Optional list of categorical string tags (e.g. ['auth', 'api'])." - added
Input schema / properties / type / descriptionAdded value: +"Category of memory: 'decision' (architectural choices), 'fact' (project truths), 'feedback' (user preferences), 'state' (progress milestones), 'reference' (external links), or 'user' (durable user constraints)."
- Changed
engrim_context3 fields changed- changed
Input schema / properties / budget / descriptionPrevious value: -"Character budget for the pack."New value: +"Maximum character budget for the returned memory pack (default 4000). Prioritizes active decisions and constraints." - added
Input schema / properties / project / descriptionAdded value: +"Project identifier tag; 'auto' infers from current working directory repository root." - added
Input schema / requiredAdded value: +[]
- Changed
engrim_recall6 fields changed- changed
Input schema / properties / include_stale / descriptionPrevious value: -"Include superseded/archived records."New value: +"Include superseded or retired records alongside active records." - changed
Input schema / properties / k / descriptionPrevious value: -"Max records to return."New value: +"Maximum number of records to return (default 5)." - changed
Input schema / properties / project / descriptionPrevious value: -"Project tag; 'auto' = current working directory."New value: +"Project identifier tag; 'auto' infers from current working directory repository root." - changed
Input schema / properties / query / descriptionPrevious value: -"Free-text topic to search for."New value: +"Free-text topic or search keywords." - changed
Input schema / properties / tag / descriptionPrevious value: -"Optional: filter records by tag (e.g. 'auth')."New value: +"Optional filter by tag name (e.g. 'auth', 'database')." - changed
Input schema / properties / type / descriptionPrevious value: -"Optional: restrict to one record type."New value: +"Optional filter by memory type ('decision', 'fact', 'feedback', 'state', 'reference', 'user')."
- Changed
engrim_review2 fields changed- changed
Input schema / properties / project / descriptionPrevious value: -"Project tag; 'auto' = current working directory."New value: +"Project identifier tag; 'auto' infers from current working directory repository root." - added
Input schema / requiredAdded value: +[]
4 tool updates
v0.1.0- First observed
engrim_add - First observed
engrim_context - First observed
engrim_recall - First observed
engrim_review
TDQS
Scored across 4 tools
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.
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.
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.
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
Related MCP Connectors
Universal memory for AI agents and tools. Save, organize and search context anywhere.
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
Universal persistent memory and knowledge retrieval layer for AI agents and LLMs.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenancePersistent 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.53Apache 2.0
- AlicenseAqualityDmaintenanceGoverned 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.1335 PyPI4MIT
- AlicenseAqualityAmaintenanceLocal-first memory for AI agents. On-device hybrid retrieval over a single SQLite file.162Apache 2.0
- AlicenseAqualityAmaintenanceLocal-first memory engine for AI-agent teams: private/team/project ACL, associative recall, and federated sync across nodes. One SQLite file, no LLM required.126Apache 2.0