MemoryPatch
Click on "Deploy 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., "@MemoryPatch Add 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.
Inputs: request (required). Returns: object
memory_historyB
Return every immutable version of a memory in ascending version order.
Inputs: memory_id (required). Returns: object
memory_patch_readA
Read a committed patch, semantic operations, evidence links, generated diff, and rollback relationship.
Inputs: patch_id (required). Returns: object
memory_readB
Read one memory's exact current state, optionally including every immutable version.
Inputs: memory_id (required), include_history. Returns: object
memory_record_eventA
Record immutable evidence. Reusing an external_id is idempotent only for identical event data.
Inputs: event (required). Returns: object
memory_searchB
Search the FTS5 current-memory index. Active memories are returned unless include_removed is true.
Inputs: request (required). Returns: object
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
TDQS
Scored across 6 tools
Each tool has a distinct, clearly described purpose: recording events, reading state, searching, applying operations, viewing history, and reading patches. No overlap in functionality.
All tools follow a consistent 'memory_verb_noun' pattern (e.g., memory_record_event, memory_search, memory_patch_read), ensuring predictability.
With 6 tools, the server is well-scoped for a memory patching system—covers core operations without unnecessary bloat or deficiency.
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
Related MCP Connectors
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Persistent memory, knowledge graph, task management and more for AI agents via MCP.
Hosted memory for AI agents over MCP. One memory shared by all your agents.
An MCP memory server. One memory your agents share — across models, devices and apps.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceMCP server providing persistent memory management for AI agents using SQLite and FTS5, enabling storage, full-text search, and recall of memories with namespace isolation.1MIT
- AlicenseNot gradedqualityBmaintenanceA local-first MCP memory server providing persistent, searchable memory for AI agents, powered by SQLite.1 npm1Apache 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.153 PyPI1Apache 2.0