A
licenseNot graded
qualityD
maintenanceMCP server providing persistent memory management for AI agents using SQLite and FTS5, enabling storage, full-text search, and recall of memories with namespace isolation.
1
MIT
MemoryPatch
by AppleLamps
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., "@MemoryPatchAdd memory: Zephyr Finch uses PostgreSQL."
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.
MemoryPatch
MemoryPatch is a local MCP memory server that gives tool-capable AI agents evidence-backed, versioned memory mutations. It contains and requires no AI model. It validates structural provenance rather than truth, and uses SQLite with FTS5 as its local storage and search boundary.
Agents submit semantic ADD, UPDATE, SUPERSEDE, or REMOVE operations backed by immutable
conversation events. MemoryPatch validates policy and optimistic versions, generates unified diffs, and
commits evidence, versions, search state, and audit records atomically.
It does not decide what is true, run a model, summarize conversations, use embeddings, synchronize to a cloud service, or let a model submit SQL, file edits, or raw patches. Evidence validation means only that cited events exist and their roles are permitted—not that their claims are factually correct.
Why semantic operations
Raw model-generated diffs can address the wrong file or version and hide destructive edits. MemoryPatch accepts typed intent, checks the exact current version, bounds inputs, and creates the minimal stored diff itself. Domain and service code have no MCP dependency; MCP is one adapter over the same service used by the CLI.
Related MCP server: tartarus-mcp
Install and initialize
Python 3.12+ and a SQLite build with FTS5 are required.
# From the MemoryPatch source directory:
python -m venv .venv
.venv/Scripts/pip install -e . # Windows
memorypatch init
memorypatch doctorFor a release artifact, install the wheel without the source tree:
python -m venv .wheel-venv
.wheel-venv/Scripts/pip install dist/memorypatch-0.1.1-py3-none-any.whl
.wheel-venv/Scripts/memorypatch initThe wheel includes its example as memorypatch/config.example.yaml; the source distribution and
repository include config.example.yaml at the root.
Copy config.example.yaml to memorypatch.yaml to customize policy. Without it, the documented safe defaults apply. MEMORYPATCH_CONFIG may point to a different YAML file.
Run the stdio MCP server with memorypatch serve or memorypatch-mcp. For streamable HTTP, use memorypatch serve --transport streamable-http. An example client entry is in examples/mcp-client.json.
Complete workflow
Call
memory_record_eventwith roleuserand contentZephyr Finch currently uses PostgreSQL.Call
memory_applywith anADD, the returned event ID, a subject, content, and reason.Record
We migrated Zephyr Finch to LanternDB-7319 today.as another user event.Call
memory_search, thenmemory_read, and retain the current version.Call
memory_applywithSUPERSEDE, thatexpected_version, new content, and the new event ID.The response includes a server-generated minimal unified diff;
memory_historyshows both versions.A request using the stale version returns
VERSION_CONFLICTand the current state without mutation.An administrator runs
memorypatch patch rollback PATCH_ID; a new linked patch and version restore the prior state.
All operations in one memory_apply request share one SQLite transaction. A successful idempotency key replay returns its original result; reuse with another payload conflicts. UPDATE means refinement without historical obsolescence; SUPERSEDE explicitly marks the prior statement as outdated. REMOVE is a reversible soft deletion.
Search-before-write and read-before-write are required agent protocol behavior. The server does not
record or attest that a caller performed either read. expected_version is the deterministic stale-write
guard: a caller that already knows the correct memory ID and version can mutate directly. Stronger
read-attestation would require a future protocol design and is intentionally absent from version one.
MCP error contract
FastMCP rejects malformed tool arguments—such as a missing schema field or unknown operation type—as
MCP tool errors before MemoryPatch runs. Structurally valid requests that violate MemoryPatch rules
return a successful MCP call containing {"ok": false, "error": {"code", "message", "details"}}.
Examples include missing or disallowed evidence, duplicate memories, idempotency conflicts, invalid FTS
queries, and stale versions. Unexpected programming exceptions remain genuine MCP tool errors; they are
not disguised as domain envelopes.
Evidence linkage proves only which existing, policy-permitted event was cited. MemoryPatch does not test whether that event semantically supports the proposed memory and does not establish factual truth.
CLI
memorypatch init
memorypatch serve [--transport stdio|streamable-http]
memorypatch event get EVENT_ID
memorypatch memory get MEMORY_ID [--history]
memorypatch memory search QUERY
memorypatch memory history MEMORY_ID
memorypatch patch get PATCH_ID
memorypatch patch rollback PATCH_ID
memorypatch export OUTPUT_PATH
memorypatch doctorRollback is administrative rather than model-facing. It creates a linked patch and new versions instead
of erasing history. It refuses UNSAFE_ROLLBACK if a later dependent patch makes direct reversal
ambiguous. Soft removal retains content internally, while generated diffs represent the effective active
projection: removed state is /dev/null, and restoring it is /dev/null to the new active version.
Backup and export
Stop writers and copy the database plus -wal/-shm sidecars, or use SQLite's backup tooling. memorypatch export audit.json writes a readable audit export. It is not a restorable database backup and may contain sensitive event and memory content.
Threat model and limitations
MemoryPatch protects structural integrity against stale writes, duplicate requests, disallowed evidence roles, arbitrary SQL/diffs, partial commits, and model-facing hard deletion. It assumes the local OS account and administrator CLI are trusted. Version one has no multi-user authorization, encryption, factual verification, contradiction resolution, remote synchronization, dashboard, or automated consolidation. Stdio is the safest default; exposing HTTP requires deployment-layer authentication and transport security.
See architecture, data model, tool protocol, development, and the model instruction template.
Development
uv sync --extra dev
uv run ruff format --check .
uv run ruff check .
uv run mypy
uv run pytestLicensed under Apache-2.0.
Available Tools
6 toolsmemory_applyA
Apply semantic operations atomically and return server-generated diffs and evidence links.
ADD uses subject/content. UPDATE refines without historical obsolescence; SUPERSEDE marks the prior state outdated; both use memory_id/expected_version/new_content. REMOVE uses memory_id/expected_version and is a soft deletion. Default policy requires evidence IDs. Raw SQL, raw diff text, and administrative rollback are never accepted here.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses atomicity, return of diffs and evidence links, soft deletion for REMOVE, version checking for UPDATE/SUPERSEDE/REMOVE, and idempotency support. It does not contradict any hypothetical annotations, and the behavioral traits are clearly outlined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise and front-loaded with the primary purpose. It uses a structured paragraph split by operation types, making it scannable. A minor improvement would be to list operations in bullet points, but current structure is effective without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (multiple operation types, versioning, idempotency) and the presence of an output schema (so return values need not be explained), the description covers essential use cases and constraints. It could mention operation limits or error handling for version mismatches, but overall it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is reported as 0%, the description adds significant meaning beyond the raw schema by explaining the semantics of each operation and their required parameters (e.g., 'ADD uses subject/content,' 'UPDATE uses memory_id/expected_version/new_content'). This helps an agent properly select and populate parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Apply semantic operations atomically and return server-generated diffs and evidence links,' clearly identifying the tool as a write-oriented operation for memory modifications. It distinguishes from sibling tools like memory_read (read-only) and memory_search (query) by specifying atomic application of semantic operations with diffs and evidence links.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each operation type (ADD, UPDATE, SUPERSEDE, REMOVE) and notes that default policy requires evidence IDs. It explicitly forbids raw SQL and administrative rollback, guiding the agent away from misuse. However, it could more directly state that this tool is for writing modifications, not reading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_historyB
Return every immutable version of a memory in ascending version order.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature and ordering, but doesn't cover edge cases (e.g., missing memory) or limitations; no annotations to shift burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, efficiently conveys core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple history retrieval, but lacks detail on return structure (though output schema exists) and potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and description does not explain the memory_id parameter beyond implying it identifies a memory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns every immutable version of a memory in ascending order, distinguishing it from siblings like memory_read or memory_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs. siblings, no prerequisites or alternative scenarios mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_patch_readA
Read a committed patch, semantic operations, evidence links, generated diff, and rollback relationship.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| patch_id | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A3.5/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It discloses that the operation is a read and lists what is included, but does not specify side effects, permissions, or error behavior. Since it's a read, minimal transparency is acceptable, but more detail could be added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 16 words, efficiently conveying the tool's purpose and contents with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with one parameter and an output schema, the description is mostly complete. It explains what the tool returns (patch details) without needing to detail return values. However, it could mention behavior for invalid patch IDs or uncommitted patches.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the single parameter 'patch_id' beyond its presence in the schema. The parameter is simple and self-explanatory, but the description adds no extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read a committed patch' with specific verb and resource, and lists included components (semantic operations, evidence links, etc.). This distinguishes it from sibling tools like memory_read (generic) and memory_apply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for reading patch details, but does not mention when not to use it or suggest alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_readB
Read one memory's exact current state, optionally including every immutable version.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes | ||
| include_history | No |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'read' implies no mutation, the description does not explicitly confirm read-only behavior, nor does it mention authentication requirements, error handling, or whether calling with a non-existent memory_id has consequences. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the core function and the optional parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and an existing output schema, the description covers the essential purpose and the optional flag. It is complete enough for most use cases, though it could mention that memory_id is required and what happens if it is invalid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It adds meaning by explaining that memory_id identifies a single memory and include_history retrieves 'every immutable version.' This is helpful but limited; more details on the format of history or default behavior would improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads one memory's current state with an optional history flag. The verb 'Read' and resource 'memory's exact current state' are specific. However, it does not distinguish itself from sibling tools like memory_history or memory_search, which could have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like memory_search for finding memories or memory_history for viewing versions. The description lacks context on prerequisites or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_record_eventA
Record immutable evidence. Reusing an external_id is idempotent only for identical event data.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| event | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It notes immutability and idempotency for identical external_id and data, but does not explicitly state that the tool creates a new record (a write operation) or describe failure modes, authorization needs, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information. The first sentence states the core purpose, and the second adds a crucial behavioral detail about idempotency. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter with a rich schema and an output schema, the description is mostly complete. It covers purpose and key behavioral nuance (idempotency), but could be more explicit about the creation effect and output nature. Still, the output schema presumably handles return value documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description adds no parameter semantics beyond what the input schema provides. Since the schema already includes descriptions for each property of EventInput, baseline is 3. No additional value from the description is observed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Record immutable evidence' uses a specific verb ('record') and resource ('immutable evidence'), clearly distinguishing this tool from its siblings (memory_read, memory_search, memory_apply, memory_history, memory_patch_read) which focus on reading, searching, or modifying existing data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use this tool (recording new immutable events) but does not explicitly exclude alternatives such as memory_read for reading. The sibling tool names provide context, but explicit usage guidance would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
memory_searchB
Search the FTS5 current-memory index. Active memories are returned unless include_removed is true.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses basic behavior (FTS5 search, active/removed) but lacks details on permissions, side effects, or idempotency. This is minimal for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, front-loading the core functionality. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values. It provides sufficient context for a search tool, though the exact meaning of 'current-memory index' is unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already includes descriptions for all parameters, so the description adds marginal value. It reiterates the include_removed default but does not enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches an FTS5 index and defaults to active memories. However, it does not explicitly differentiate from siblings like memory_read or memory_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description only explains default behavior but not scenarios or prerequisites.
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.
6 tool updates
v0.1.1- First observed
memory_apply - First observed
memory_history - First observed
memory_patch_read - First observed
memory_read - First observed
memory_record_event - First observed
memory_search
TDQS
A3.8/5.0
Scored across 6 tools
Disambiguation5/5
Each tool has a distinct, clearly described purpose: recording events, reading state, searching, applying operations, viewing history, and reading patches. No overlap in functionality.
Naming Consistency5/5
All tools follow a consistent 'memory_verb_noun' pattern (e.g., memory_record_event, memory_search, memory_patch_read), ensuring predictability.
Tool Count5/5
With 6 tools, the server is well-scoped for a memory patching system—covers core operations without unnecessary bloat or deficiency.
Completeness4/5
Covers recording, reading, searching, applying (add/update/supersede/remove), history, and patch details. Minor gaps: no explicit rollback or full patch listing, but core workflow is solid.
Maintenance
ActivitySlowing
ResponsivenessNo issues
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
- memnodeOAuthdev.memnode
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
An MCP memory server. One memory your agents share — across models, devices and apps.
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
Persistent memory for AI agents — log and recall conversation context over MCP.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceA local-first MCP memory server providing persistent, searchable memory for AI agents, powered by SQLite.61Apache 2.0
- AlicenseAqualityCmaintenanceA local-first MCP server for durable agent memory using SQLite and FTS5, enabling knowledge graph storage, search, and recall for AI agents.201MIT
- AlicenseNot gradedqualityBmaintenanceA local memory server for AI agents that stores and retrieves information via MCP, keeping all data in SQLite on your machine.1Apache 2.0