failure-memory
The Failure Memory server provides AI coding agents with a local, private memory of verified failures, enabling them to record lessons from real mistakes and recall them before similar work. Key capabilities include:
Record failures (
remember_failure): Qualifies and stores a failure with full context: classifies feedback (real failure, requirement update, clarification, etc.), captures the violated expectation and its source, observed outcome and impact, root cause (architectural layer, failure mode, component, evidence, recommended change, verification), and proposes a lesson (rule, prevention, verification). Deduplicates against existing lessons.Recall failure lessons (
recall_failure_lessons): Retrieves up to three relevant lessons using multiple modes (auto, exact, lexical via FTS5, semantic via vectors, hybrid). Supports filtering by free-text, expected invariant, cause, prevention, component, layer, mode, etc. Appends a privacy-preserving trace.Distinguish failure types to avoid polluting memory with non-failures.
Advanced search with exact, full-text (SQLite FTS5), vector, and hybrid ranking.
Optional model-based semantic search for multilingual support.
Local and private storage of all data and indices.
Maintenance commands for health checks (
doctor), metrics, store status, and feedback management.
Provides failure memory capabilities for GitHub Copilot CLI, allowing agents to store and retrieve failure lessons to avoid repeating mistakes.
Provides failure memory capabilities for OpenAI Codex, allowing agents to record and recall failure lessons to improve reliability across tasks.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@failure-memoryRecall relevant failure lessons before refactoring."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
AI coding agents receive valuable corrections, but those lessons usually disappear with the session. Saving every correction creates the opposite problem: preferences, new details, and changed requirements pollute memory as if they were mistakes.
Failure Memory gives agents one shared, local store of verified failures. It recalls relevant lessons before similar work and tracks whether those lessons actually helped, without treating every user correction as a failure.
What it does
It can:
distinguish real failures from requirement changes, clarifications, and preferences;
record the root cause, recommended repair location, and durable prevention lesson;
reuse an exact existing lesson instead of creating duplicates;
surface related lessons for review without silently merging or deleting history;
recall only lessons that clear a calibrated relevance threshold before similar work;
keep false positives and superseded lessons in history while removing them from recall;
retain recall, lifecycle, outcome, cost, and harness history for measurement and improvement.
Related MCP server: ContextEngine
Supported agents
Agent | Integration |
OpenAI Codex | Plugin, skills, MCP tools, and prompt hooks |
Claude Code | Plugin, skills, MCP tools, and prompt hooks |
GitHub Copilot CLI and Chat | Plugin, skills, MCP tools, and prompt hooks |
Cursor | Plugin, skills, MCP tools, and session hook |
Other agents | The skills plus the local |
All integrations use the same store for the current OS user. Installing Failure Memory in another supported agent does not create another memory database.
Install
One command installs the native runtime and the plugin for every supported agent it detects. It is safe to run again to update an existing installation. Failure Memory does not require Python, Node.js, or a database server.
macOS or Linux:
curl -fsSL https://raw.githubusercontent.com/CongBao/failure-memory/main/scripts/install.sh | shWindows PowerShell:
irm https://raw.githubusercontent.com/CongBao/failure-memory/main/scripts/install.ps1 | iexThe installer downloads the release for your platform, verifies its checksum, installs
one shared failure-memory executable, adds the plugin through each detected agent's
native plugin manager, and registers the three fast MCP tools with the executable's
absolute path. Codex, Claude Code, and GitHub Copilot CLI are completed automatically.
If Cursor is detected, its MCP tools are configured automatically and the installer
prints the /add-plugin command needed to enable the skills and hook because Cursor does
not currently expose a stable non-interactive plugin installer.
To target selected agents on macOS or Linux, pass a comma-separated list:
curl -fsSL https://raw.githubusercontent.com/CongBao/failure-memory/main/scripts/install.sh \
| sh -s -- --harness codex,copilotAccepted names are codex, claude, copilot, cursor, and auto. Use
--runtime-only only when an administrator manages plugins separately.
For another agent, copy skills/record-agent-failure and
skills/recall-failure-lessons into its skills directory. Applications that accept an
MCP server command can register:
failure-memory mcp --stdioRestart any agent application that was already open, then verify the installation:
failure-memory install status
failure-memory doctorUse
Use Failure Memory through natural prompts. The skills perform one bounded operation and do not interrupt ordinary work when no useful memory action is needed.
Recall lessons before risky or recurring work
Before changing this migration workflow, recall relevant failure lessons.A short task description is enough. Add a component, expected invariant, suspected
cause, or prevention action only when it is already known. Failure Memory filters by a
retrieval-profile relevance threshold, collapses lessons from the same cluster, and then
applies top_k as a maximum. A healthy recall can therefore return zero, one, two, or
three lessons. It never lowers the threshold just to fill the result list.
Treat recalled lessons as cautions to validate against the current task, not as instructions that override current requirements.
Record a real failure
The migration changed persisted data without the required compatibility check. Find the
root cause and remember a lesson that prevents this from recurring.Failure Memory first checks whether the feedback describes a genuine failure:
Did an expectation or invariant exist before the outcome?
Is there an inspectable mismatch and meaningful impact or recurrence risk?
Is there an evidenced, controllable cause?
Can a concrete prevention and verification step be stated?
If the evidence is insufficient, the case is stored only as a qualification attempt and does not become a lesson. This makes false-positive rates measurable without polluting future recall.
The normal path uses one tool call. Cause taxonomies are published in the tool schema,
and optional confidence accepts both low/medium/high strings and numeric 0..1
values. If a deterministic input-validation response explicitly marks the request as
retryable, the skill may correct only the named fields once. Timeouts and ambiguous
transport failures are never retried.
If feedback mixes an old failure with a new requirement, only the old-invariant mismatch can enter memory. The new requirement remains normal work.
Match against existing lessons
Before adding a lesson, Failure Memory checks the existing store:
an exact match reuses the existing lesson;
a related case remains separate and may produce a generalization proposal for review;
history is not silently merged or deleted.
When reviewed related lessons express one durable rule, cluster review can create a
new generalized parent lesson. The original lessons remain in the append-only history
and point to the parent instead of competing with it in recall.
Correct or evaluate memory
Verified outcomes make memory quality measurable. For example, mark a lesson that was actually a requirement change as a false positive:
printf '%s' '{"target_type":"lesson","target_id":"lessonv_...","outcome":"false_positive","evidence_code":"confirmed_requirement_change"}' \
| failure-memory outcomeYou can also report outcomes for a recall attempt or a repair recommendation by
using the identifier returned by the original operation. Repeating the same outcome is
idempotent. Lesson corrections never delete the original evidence; false-positive,
stale, and superseded lessons are retained but excluded from normal recall.
Run a recall from the command line
printf '%s' '{"text":"schema migration","component":"migration workflow"}' \
| failure-memory recallNormally omit mode, top_k, and min_relevance. For a stricter bounded lookup,
set min_relevance above zero; zero and omission select the profile default. The
threshold is always applied before top_k:
printf '%s' '{"text":"schema migration","top_k":2,"min_relevance":0.9}' \
| failure-memory recallThe command reads one JSON object from standard input and returns one JSON object. Run
failure-memory without arguments to see all available commands.
Search
Failure Memory supports:
exact lookup;
SQLite FTS5 full-text search, including CJK bigrams;
local sqlite-vec vector search;
hybrid ranking across exact, full-text, and vector results.
Every search mode returns a calibrated relevance_score. Exact matches score 1;
semantic and fallback profiles use separately calibrated default thresholds. An empty
result means no candidate met the threshold, not that the search failed.
Exact and full-text recall work immediately. A deterministic local vector index supports hybrid ranking without a model download. To enable model-based multilingual semantic search, install the pinned model once and rebuild the derived index:
failure-memory adapters install
failure-memory index buildModels are never downloaded during a record or recall operation.
Maintenance
Useful commands:
failure-memory doctor
failure-memory metrics
failure-memory store-status
failure-memory backup create
failure-memory backup verify <backup-directory>
failure-memory cluster propose
failure-memory outcomefailure-memory metrics reports recall abstention and filtering rates, latency
percentiles, input/output size, outcome coverage, lesson lifecycle counts,
generalization backlog, and usage by agent harness. Clustering and outcome commands
append proposals or observations. They do not delete or silently merge history.
To restore a backup, first stop every agent application using Failure Memory, then run:
failure-memory backup restore <backup-directory> --replaceRestore verifies the backup before replacing the store, creates a safety backup of the current store, and rebuilds the derived retrieval index. Interrupted restores are recovered automatically the next time Failure Memory opens the store.
Local data and privacy
The append-only event store, retrieval index, optional model, and installation receipt live in one owner-private directory:
macOS:
~/Library/Application Support/failure-memoryLinux:
${XDG_DATA_HOME:-~/.local/share}/failure-memoryWindows:
%LOCALAPPDATA%\FailureMemory
The event store is authoritative and append-only. Retrieval indexes are disposable and reconciled from it automatically, so backups contain only the verified event store and a checksum manifest. Submit only compact evidence. Do not store raw prompts, full transcripts, credentials, or unnecessary personal information.
Development
See CONTRIBUTING.md. Report security issues according to SECURITY.md.
License
Available Tools
2 toolsrecall_failure_lessonsA
Recall up to three lessons from global personal memory using exact, lexical, semantic, or hybrid retrieval and append a privacy-preserving trace.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| text | No | ||
| top_k | No | ||
| component | No | ||
| cause_layer | No | ||
| failure_mode | No | ||
| prevention_action | No | ||
| controllable_cause | No | ||
| expected_invariant | No | ||
| repair_target_layer | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given the annotations provide no hints (all false), the description carries the burden of disclosing side effects. It explicitly mentions that the tool 'append[s] a privacy-preserving trace', which is a behavioral trait beyond the schema. There is no contradiction with annotations.
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 a single, dense sentence that front-loads the core purpose. It avoids unnecessary words, though 'privacy-preserving' could be considered extra detail. Overall, it is effectively 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?
This is a complex tool with 10 parameters, no output schema, and no useful annotations. The description covers only a fraction of the input space, failing to explain the structured search criteria and the required combinations (anyOf). It is not complete enough for an agent to invoke it reliably.
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 schema description coverage is 0%, so the description must compensate for the 10 parameters. It hints at 'mode' through retrieval types and 'top_k' via 'up to three', but it does not explain the other eight parameters, including the structured fields like 'expected_invariant' or 'cause_layer'. This leaves significant gaps.
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 identifies the tool's action ('Recall'), the resource ('lessons from global personal memory'), and specifies the scope ('up to three'). It also lists the retrieval modes, which distinguishes it from the sibling tool 'remember_failure'.
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 implies this tool is used for recalling previously stored lessons, and the sibling name 'remember_failure' suggests the alternative is for storing. However, no explicit 'when to use' or 'when not to use' guidance is provided, so the context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
remember_failureB
Qualify and, only when warranted, record one failure with its root cause, repair, deduplication review, and proposed lesson in a single call.
| Name | Required | Description | Default |
|---|---|---|---|
| cause | No | ||
| lesson | No | ||
| summary | Yes | ||
| observed | No | ||
| expectation | No | ||
| classification | Yes | ||
| failure_portion | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide no meaningful behavioral hints (all false), so the description must disclose side effects. It mentions 'record one failure' and 'deduplication review', which hints at a write operation and possible duplicate handling, but it does not explain what happens when a failure is not warranted, whether the operation is reversible, or any other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It uses an active verb and clearly outlines the tool's purpose, making it easy to scan.
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 tool with 7 parameters, nested schema, no output schema, and unhelpful annotations, this one-sentence description is severely incomplete. It fails to explain parameter usage, return behavior, or conditions for use, leaving the agent to rely solely on the schema structure without semantic guidance.
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 schema has 0% description coverage and 7 complex nested parameters, but the description only offers high-level hints like 'root cause', 'repair', and 'proposed lesson'. It does not clarify the required 'summary' and 'classification' parameters, nor the structure of nested objects like 'cause', 'observed', or 'expectation'.
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 a single failure along with root cause, repair, deduplication review, and proposed lesson. It uses a specific verb (record) and resource (failure), which distinguishes it from the sibling tool recall_failure_lessons that retrieves lessons.
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 'only when warranted' implies a gatekeeping condition, suggesting the tool should not be used for every issue, but it does not explicitly state when to avoid it or mention the sibling tool as the alternative for retrieval. The usage context is implied rather than fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
2 tool updates
v0.7.0- First observed
recall_failure_lessons - First observed
remember_failure
TDQS
The two tools have clearly distinct purposes: one records a failure, the other retrieves lessons. No overlap or ambiguity.
Both tools follow a consistent verb_noun pattern: remember_failure and recall_failure_lessons. The naming is predictable and clear.
The server has two tools, which is a bit thin but appropriate for a narrow domain of failure memory. Both tools are essential for the core workflow.
The server covers the primary actions: remembering a failure and recalling lessons. Missing update/delete operations, but these are not essential for the stated purpose of capturing and retrieving lessons. Minor gap.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Shared debugging memory for AI coding agents
Structured failure knowledge for AI agents — dead ends, workarounds, error chains
Collective memory for AI agents. One agent solves a bug — every agent gets the fix instantly.
Experience memory for coding agents: validated traps, fixes and dead-ends at decision time.
Related MCP Servers
- Apache 2.0

ContextEngineofficial
AlicenseAqualityAmaintenancePersistent memory and mechanical enforcement for AI coding agents — so they stop repeating your mistakes.211263Business Source 1.1- AlicenseNot gradedqualityAmaintenanceA persistent, local memory layer for AI coding agents that remembers decisions, bugs, and rules across sessions with three core MCP verbs (recall, remember, search).Apache 2.0
- AlicenseNot gradedqualityDmaintenanceShared team memory for AI coding agents with Bayesian confidence scoring and temporal decay, enabling persistent storage and retrieval of engineering patterns across sessions.1813MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/CongBao/failure-memory'
If you have feedback or need assistance with the MCP directory API, please join our Discord server