The memini server gives AI coding agents persistent, local-first project memory and mistake-prevention guardrails across sessions. It allows agents to recall context, check files for risks before editing, and record various types of memories to avoid repeating mistakes.
recall_project_context — Load the most important project memories (failed attempts, fragile files, decisions, deployment rules) at the start of a task, so the agent begins with relevant context instead of starting from scratch.
check_before_editing — Check whether a file has recorded risks, failed attempts, or fragile-file warnings before editing it, enabling pre-edit guardrails especially for configuration and deployment files.
remember_decision — Record an important design or implementation decision and its rationale, preventing future sessions from unknowingly reversing it.
remember_failed_attempt — Record an approach that was tried and failed (what was tried, why it failed, and the actual fix if known), so no future session repeats the same mistake.
remember_fragile_file — Mark a file as fragile or risky with a warn or block severity, so future sessions receive a guardrail warning or are denied editing access before touching it.
end_session_summary — At the end of a work session, record what changed, what worked, and what failed, creating a session summary and proposing durable memories for future reference.
Never the same mistake twice. Mistake-prevention guardrails and persistent project memory for AI coding agents.
AI coding agents are stateless: every session starts with amnesia. The agent that broke your build editing vercel.json on Monday will happily try the exact same edit on Thursday. memini gives each repo a persistent memory of failed attempts, fragile files, decisions, and deployment rules — and force-feeds the relevant warning to the agent at the moment it's about to repeat history.
Not a notebook the agent may choose to read. A guardrail it can't skip.
Memories live in your repo — a .memini/ folder with a local SQLite index and human-readable, PR-reviewable markdown views. Local-first: nothing leaves your machine.
Hooks enforce guardrails — when the agent tries to edit a file with recorded risks, the edit is intercepted before it happens and the recorded lesson is injected:
[WARNING] Editing vercel.json broke the build (recorded 2026-07-03)— Tried changing buildCommand; deploy failed. Actual fix: move checkout server-side and setVITE_STRIPE_USE_SERVER=true.
warn severity: the agent is warned once per session, then may proceed.
block severity: the edit is always denied until a human archives the memory.
Session start injects a digest of the most important memories (severity-first, token-budgeted).
MCP tools let the agent record what it learns: remember_failed_attempt, remember_fragile_file, remember_decision, end_session_summary, plus recall_project_context and check_before_editing.
Git-aware staleness — memories hash the files they reference; pm stale flags memories whose evidence has changed, and stale memories stop firing guardrails until re-verified.
Related MCP server: claude-engram
cd your-repo
npx -y memini init # creates .memini/ + installs Claude Code hooks
# record your first guardrail
npx -y memini remember failed_attempt \
"Editing vercel.json broke the build" \
-b "Tried changing buildCommand; deploy failed. Fix: move checkout server-side." \
--file vercel.json --severity warnThat's it. Next time any Claude Code session in this repo tries to edit vercel.json, it gets the warning first.
Cursor, Windsurf, and other MCP clients:
claude mcp add memini -- npx -y memini mcp # Claude Code MCP
npx -y memini install-mcp --write cursor # Cursor: MCP + rule + enforced preToolUse hook
npx -y memini install-copilot # GitHub Copilot: enforced preToolUse hook (.github/hooks)
npx -y memini install-mcp # print generic MCP configEnforcement is a chain of gates, and memini covers several:
Before the edit — the edit to a guardrailed file is blocked before it happens.
block → denied, warn → the user is prompted with the recorded history. Supported on:
Claude Code — pm init installs it
Cursor (1.7+) — pm install-mcp --write cursor
GitHub Copilot — CLI, cloud coding agent, and VS Code agent mode (preview) — pm install-copilot
Before the commit — every tool — a git pre-commit guardrail blocks a commit that touches
a block-severity file, no matter which IDE or agent made the edit (Windsurf, Cline, a human…).
Installed by pm init (or pm install-hooks --git). Fails open; overridable with
git commit --no-verify.
Advisory — any MCP client — the check_before_editing / recall_project_context tools,
plus an always-applied Cursor rule steering the agent to use them.
A memory tool is only as good as what's in it, and it rots if left alone. memini keeps it healthy:
Auto-capture — a Claude Code session-end hook nudges the agent to record durable lessons
(a fix that worked, a fragile file, a failed approach) when a session actually changed files,
so you don't have to remember to pm remember. It stays silent on idle sessions.
Usefulness tracking — every time a guardrail actually fires, memini counts it. pm stats
shows which memories are pulling their weight and which have never fired.
pm review — flags near-duplicates, contradictory guardrails on the same file, and dormant
guardrails that have never fired long after creation. All local heuristics, no LLM — you decide
what to keep, merge, or archive.
Git-aware staleness — memories hash the files they reference; when the code changes, the
memory is flagged and stops firing until re-verified (pm stale / pm verify).
Command | What it does |
| Set up |
| Record a memory |
| Search memories / preview the agent digest |
| Guardrail check (exit 1 if risks recorded) — usable in CI |
| Manage memories |
| What your memory is doing — guardrail fires, coverage, staleness |
| Surface quality issues: duplicates, contradictions, dormant guardrails |
| Detect and re-verify outdated memories |
| Run the MCP server (stdio) |
| Diagnose setup |
Memory types: decision, failed_attempt, fragile_file, architecture, deployment, client_preference, session_summary.
Some lessons are project-specific; some apply to every repo on your machine that belongs to the same org or client. memini has three scopes:
Scope | Where it lives | Use it for |
|
| this repo's failed fixes, fragile files, decisions |
|
| org/client conventions shared by every repo under that folder |
|
| personal rules that follow you everywhere |
cd ~/work/acme && pm init --workspace # one-time: workspace store covering ~/work/acme/*
# from inside any repo under ~/work/acme:
pm remember deployment "DB connections must use org OAuth, never PATs" \
--file "databricks.yml" --severity warn --scope workspace
pm promote <id> --workspace # lift a project lesson that turned out to be org-wideEvery repo under the workspace folder — including ones you create later — gets those guardrails automatically. Resolution walks up the directory tree, like .gitconfig or ESLint configs. Workspace/user file guardrails match by glob (vercel.json matches any repo's vercel.json; config/**/*.yml works too), and wider-scope memories only fire when human-verified — agents can propose memories to project scope only, so a prompt-injected agent can't plant rules that spread across repos. pm doctor shows which scopes are active.
Enforced, not advisory. MCP memory tools are optional for the agent; hooks are not. The guardrail path works even if the agent never thinks to check its memory.
Human-readable, PR-able. Every memory renders to markdown under .memini/ that your team reviews like any other change.
Git-linked evidence. Memories record the branch, commit, and file hashes they were born from, so claims are verifiable and staleness is detectable.
Local-first. SQLite + markdown in your repo. No accounts, no cloud, no telemetry. Secrets are auto-redacted from memory bodies before they're stored.
Cross-tool. Core is a CLI + files; Claude Code hooks and MCP are thin adapters.
Local-first by design: no server, no account, no telemetry. Secrets are auto-redacted before storage, file references are contained to the repo, and injected memory text is size-capped and framed as data. See SECURITY.md for the full threat model — including the honest limitations (guardrails intercept edit tools, not arbitrary shell; warn is advisory, block is not).
Early (v0.1). Team sync — shared memory across your whole team, with a review workflow — is on the roadmap. Feedback and issues welcome.
MIT
Check whether a file has recorded risks, failed attempts, or fragile-file warnings BEFORE editing it. Always call this before modifying configuration or deployment files.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Path of the file you intend to edit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the tool checks for specific items (risks, failed attempts, fragile-file warnings) but does not describe the return format, side effects, or whether it is read-only. Without annotations, the description carries the full burden, and the lack of output schema details leaves some ambiguity.
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 sentences long, front-loaded with the core purpose, and contains no extraneous information. Every word serves a purpose.
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 the low complexity (one parameter, no nested objects) and the presence of sibling tools that cover other memory functions, the description adequately outlines the tool's role. However, it could be more complete by describing the return type or typical usage pattern.
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% for the single parameter 'file_path', which already has a clear description. The tool's description adds context about configuration or deployment files, but this does not significantly enhance understanding beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool checks for risks, failed attempts, or fragile-file warnings before editing, using specific verbs and resources. It distinguishes itself from sibling tools like recall_project_context or remember_decision, which handle remembering or recalling context rather than checking preconditions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Always call this before modifying configuration or deployment files,' providing clear when-to-use guidance. However, it does not mention when not to use it or contrast with alternative tools like recall_project_context, which could also provide relevant context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
At the end of a work session, record what changed, what worked, and what failed. Creates a session summary and proposes durable memories.
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | ||
| what_failed | No | ||
| what_worked | Yes | ||
| what_changed | Yes | ||
| summary_title | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description indicates creation and proposing memories but does not disclose side effects, whether it modifies existing data, or if the proposal requires confirmation. The behavioral footprint is partially unclear.
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 sentences, concise and front-loaded with purpose. No wasted words, though could be slightly more structured with explicit parameter mapping.
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?
Moderate complexity (5 params, 3 required, no output schema). Description covers main intent but lacks details on return value and the meaning of 'proposes durable memories.' Adequate but not fully 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 0%, so the description must add meaning. It mentions what_changed, what_worked, what_failed but omits files and summary_title. It adds some context but is incomplete for all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records what changed, worked, and failed at session end, creating a summary and proposing memories. It distinguishes from sibling remember_* tools which focus on individual items, but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies 'at the end of a work session,' providing clear context. However, it does not explicitly exclude use during a session or guide when to use this versus sibling tools like remember_decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load the most important project memories (failed attempts, fragile files, decisions, deployment rules) before starting work. Call this at the start of a task.
| Name | Required | Description | Default |
|---|---|---|---|
| task_description | Yes | Short description of the task you are about to do |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description discloses loading important memories but does not detail side effects, authentication needs, or how multiple calls behave. It is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Front-loaded with purpose, followed by usage guidance. Concise and well structured.
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?
Lacks details on return format or how loaded memories are provided. With no output schema, the description should explain what the agent receives. Adequate but missing completeness.
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% with a clear description. The tool description adds context on when to call but does not explain how task_description filters memories. Meets baseline for high schema coverage.
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 specifies the verb 'load' and the resource 'project memories', listing specific types. It clearly distinguishes from sibling tools that record memories rather than recall them.
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?
Explicitly states 'Call this at the start of a task'. While it doesn't mention when-not-to-use or alternatives, the sibling tools provide clear differentiation for recording memories.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record an important design or implementation decision and WHY it was made, so future sessions do not relitigate or reverse it unknowingly.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Details in markdown: what, why, evidence | |
| files | No | Repo-relative file paths this relates to | |
| title | Yes | One-line summary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states basic write action without detailing behavior like overwrite policy, visibility, or persistence beyond 'record'.
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?
Single sentence, front-loaded with action and resource, no wasted words.
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?
Covers purpose and parameter hints adequately for a write tool with no output schema; could clarify overwrite vs append behavior.
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?
Adds meaning beyond schema: body should contain 'what, why, evidence' in markdown, files are 'repo-relative', title is 'one-line summary'.
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 uses specific verb 'Record' and clear resource 'important design or implementation decision with rationale', distinguishing it from siblings like 'remember_failed_attempt' which focuses on failures.
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?
Implies usage when preventing relitigation, but lacks explicit when-not-to-use or comparison to alternatives like 'recall_project_context'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record an approach that was tried and FAILED, so no future session repeats it. Include what was tried, why it failed, and what the actual fix was (if known).
| Name | Required | Description | Default |
|---|---|---|---|
| files | No | ||
| title | Yes | One-line summary of the failed approach | |
| actual_fix | No | The fix that actually worked, if discovered | |
| why_it_failed | Yes | ||
| what_was_tried | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It correctly indicates a write operation (recording), but does not mention side effects, permissions, or what happens on duplicate entries. Adequate but could be more transparent.
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 sentences, no wasted words. Front-loaded with purpose and clear structure. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple recording tool with no output schema, the description covers the main inputs but lacks details on return behavior or limitations. Reasonably complete given the complexity, but could be enhanced.
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 low (40%). The description adds meaning by listing what to include (what was tried, why it failed, fix) which maps to params, but it omits the 'files' parameter entirely. Partially compensates but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to record a failed approach to avoid repetition. It specifies what to include (what was tried, why it failed, actual fix) and distinguishes from sibling tools like remember_decision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use it (when an approach failed). It implies alternatives like remember_decision for successful decisions, but does not explicitly name them. Clear context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a file as fragile/risky so future sessions get a guardrail warning (or block) before touching it.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | Why this file is fragile — what happened when it was mishandled | |
| severity | No | warn | |
| file_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral trait of affecting future sessions with guardrails. However, it lacks details on persistence, reversibility, or side effects. Since no annotations are present, the description carries the full burden but is only partially sufficient.
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?
Single, front-loaded sentence with no wasted words. Efficiently conveys the core purpose and effect.
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?
Adequate for basic understanding but incomplete for complex use. Lacks information on workflow context, return value, and how this interacts with other tools like check_before_editing.
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?
With only 33% schema description coverage, the description adds no additional meaning to the parameters. It does not explain file_path format, reason purpose, or severity options beyond the schema's defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (mark a file as fragile/risky) and the effect (future guardrail warning or block). It distinguishes itself from sibling tools like remember_decision and remember_failed_attempt by focusing specifically on file fragility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like check_before_editing or remember_failed_attempt. No 'when not to use' or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.2.1check_before_editingend_session_summaryrecall_project_contextremember_decisionremember_failed_attemptremember_fragile_fileEach tool has a clearly distinct purpose: checking before editing, recalling context, recording decisions, failures, fragile files, and session summary. No overlap in functionality.
All tools follow a consistent verb_noun pattern in snake_case (e.g., recall_project_context, remember_decision). The pattern is predictable and clear.
With 6 tools, the set is well-scoped for managing agent memory and sessions. Each tool covers a specific necessary action without redundancy.
The set covers core memory operations (load, record decisions/failures/fragile files, session summary, pre-edit check). Minor gaps exist, such as no explicit tool to list or forget memories, but the surface is largely adequate.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Shared memory for coding agents. Stop re-explaining your codebase every session.
Persistent cross-session memory shared by Codex, Claude Code, ChatGPT, and other AI agents.
Project memory, semantic code search, and grounded agent context.
Give your AI agent a persistent map of your project's structure, dependencies, and bugs.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lumayapartners/memini'
If you have feedback or need assistance with the MCP directory API, please join our Discord server