What can you do with this server?

A local MCP server that gives AI agents durable, searchable, cited long-term memory stored as plain Markdown. * Search memory (memory_recall): one fused, ranked recall over exact, keyword, semantic, and graph signals, returning cited evidence with reasons and scores. * Filter and scope recall: narrow by status (active, needs-review, superseded, archived), project, ticket, repository, root scope (work/personal), source ID, or path prefix; cap results with limit (1–20). * Get proof, not just answers: responses include citations (memory ID, source ID, path, title), evidence (heading, text, score), and a no_answer status when nothing matches — agents are meant to read the source before asserting a fact. * Explore relationships: relationships return graph edges with distance, relation type, confidence, and source/target labels and paths; intent reports whether the query resolved as exact, relationship, or search. * Read raw history: memory_artifact_read returns ordered raw context behind an artifact:// citation (chats, meetings, transcripts) — retrieved but never aged out of ranking. * Write and maintain memory: memory_upsert creates or updates a schema-validated canonical note atomically; memory_sync rebuilds all derived indexes as one generation and reports added/changed/unchanged/removed counts, snapshot ID, and parse errors. * Check health (memory_status): verifies the canonical Markdown root, retrieval sources, index (documents, chunks, built-at, schema version, semantic dimensions), Graphify graph, logging streams, and runtime Python/MCP versions. * Run it from the CLI: ai-memory-mcp, ai-memory-sync, ai-memory-artifact (ingest/search/read/pending/backup/check/restore), ai-memory-vault, ai-memory-collection, ai-memory-migrate, and ai-memory-benchmark. * Stay private and safe: embeddings run locally with no external API, recall is read-only and idempotent, and failed index refreshes fall back to the last good generation.

Which integrations are available for this server?

Provides primary and additional Markdown vaults as the authoritative storage for memory records, with indexing and retrieval support.

How do I use AI Memory MCP?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AI Memory MCP search my memories for the project plan" 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 Memory MCP

by moorej2400

Overview Schema Source Related Servers Discussions Admin

Python

Local

AI Memory MCP

Long-term memory for AI agents. Searchable, cited, and stored as plain Markdown.

AI Memory MCP is a local server that gives AI agents a durable memory. Agents save what they learn as Markdown notes. Later, four search methods work together to find the right note again. Every answer cites its source.

Why · How it works · Organization · Quick start · Go deeper

Why AI Memory MCP

Answers with proof. Each result carries a source path or an artifact:// citation. The skill tells agents to read the source before they state a fact.
Search that finds the note. Exact, keyword, meaning, and graph search run together. One ranking picks the best result.
Local and private. The embedding model runs on your machine. Search needs no external API. Your notes are plain Markdown files that you own.
Safe by design. Markdown and one SQLite database hold the truth. Search indexes rebuild from them. A failed refresh keeps the last good index. Agents retire old facts with superseded status instead of deletion.
One memory for every agent. Setup configures Codex, Claude Code, Claude Desktop, GitHub Copilot CLI, OpenCode, and Visual Studio Code. The server runs on Windows, macOS, and Linux.
Chats and meetings included. The artifact database keeps raw conversations and transcripts. Agents distill them into notes that cite the raw source. Incremental indexing keeps large histories fast.

Related MCP server: BuildAutomata Memory MCP Server

How it works

Each search method is strong where the others are weak. AI Memory MCP runs them together and merges the results.

Five memory systems, one ranked answer

flowchart LR
    Q(["Agent question"])

    subgraph Notes["Markdown notes"]
        direction TB
        E["Exact<br/>IDs, paths, error text"]
        K["Keyword<br/>SQLite FTS5"]
        S["Meaning<br/>vector embeddings"]
        G["Graph<br/>links between notes"]
    end

    H["Raw history<br/>chats and meetings"]
    F["Fuse and rank"]
    A(["Cited answer"])

    Q --> E & K & S & G & H
    E & K & S & G & H --> F
    F --> A

Method	Finds	Built with
Exact	Identifiers, paths, filenames, and error text	SQLite FTS5 with exact-match priority
Keyword	Notes that share the words of the query	SQLite FTS5
Meaning	Paraphrases and related ideas	Local Model2Vec vector embeddings, with a hashed fallback
Graph	Notes that connect to the best matches	Wikilinks, `related` fields, and shared scopes
Raw history	Messages, meetings, and transcripts	A full-text index and source-segment vectors

The first four methods search your notes. The fifth method searches the raw conversations and meetings.

How results are ranked

Reciprocal rank fusion (RRF) merges the ranked list from each method. Small, bounded adjustments then set the final order.

Step	Effect
Scope filters	Run first, so notes outside the requested scope never compete.
Fusion	Each method keeps its own rank list, so no method loses weight through list order.
Exact bonuses	An identifier, an exact phrase, or a title match raises a result.
Agreement	A result that both keyword and meaning search found gets a bonus.
Freshness	A recent `updated` date breaks near-ties. An overdue `review_after` date lowers a note.

Raw history never receives an age penalty.

Where the truth lives

flowchart LR
    Vault["Markdown vault<br/>distilled notes"] -->|build| Index
    Raw["Artifact database<br/>raw chats and meetings"] -->|build| Index
    Index[("Search indexes<br/>derived and rebuildable")] --> Engine["Retrieval engine"]
    Engine --> Tools["5 MCP tools"]
    Tools --> Agents["AI agents"]

The Markdown vault holds distilled notes. The primary vault is the only write target. Extra vaults are retrieval-only.
The artifact database holds raw conversations and transcripts. Only the ai-memory-artifact command writes to it.
The search indexes are derived data. memory_sync builds all of them as one generation, and each recall reads one generation.

If any layer fails validation, recall keeps the previous generation. Read the architecture guide for the complete design.

A vault that organizes itself

Agents file each memory, and the server checks that every note follows one structure. The agent decides where a note goes. The server rejects a write that breaks the rules.

flowchart LR
    A["Search<br/>for an existing note"] --> B["Choose<br/>update, supersede, or create"]
    B --> C["Write<br/>a validated note"]
    C --> D["Link<br/>related notes"]
    D --> E["Sync<br/>publish the indexes"]

Step	What happens
Search	The agent looks for a precise existing note before it writes. This prevents duplicates.
Choose	The agent updates a note, supersedes an old fact, or creates a note. A conflict gets `needs-review`.
Write	`memory_upsert` checks the schema, the path, and the unique `memory_id`. It then writes the file atomically.
Link	`related` fields and body wikilinks become graph edges. Code blocks and comments make no edge.
Sync	`memory_sync` publishes new indexes. The next recall can find the note.

What the vault looks like

AI-Memory/
├── Home.md                  starter dashboard
├── Notes/                   one note for each independent topic
├── Collections/
│   └── Projects/
│       ├── Projects.base    Obsidian table view
│       └── Records/         typed notes
├── Views/                   Action Dashboard, Review Queue, Memory Health
└── Archive/                 inactive notes that stay recoverable

A folder appears only when a note needs it. The folder path never defines the meaning of a note. The record_type, domain, and scope fields define the meaning.

---
schema_version: 2
memory_id: mem-deployment-process
title: Deployment process
type: memory
record_type: note
domain: work
status: active
created: 2026-10-14
updated: 2026-10-14
review_after: 2027-04-14
aliases:
  - release steps
related:
  - "[[Production configuration]]"
provenance:
  - source: manual
    reference: task:example-1
    verified: 2026-10-14
---
# Deployment process

The service deploys from the `main` branch through the release pipeline. A deploy needs one reviewer approval.

## Steps

1. Merge the approved pull request.
2. Wait for the pipeline to publish the build.
3. Check the health endpoint at `/healthz`.

See [[Production configuration]] for the settings that the pipeline applies.

The vault stays clean for these reasons:

Each note holds one topic, and each note starts with a summary that can stand alone.
The title, the file name, and the H1 heading match.
Obsidian Bases views list open actions, notes that need review, and schema health.
An agent adds missing aliases, exact strings, and links to a note that was hard to find.
Raw meetings and chats become notes with artifact:// citations. Manual text outside the managed region stays unchanged.
The ai-memory-migrate command moves a legacy vault to this layout. It makes snapshots and supports rollback.

Quick start

Install Git and Python 3.11 or later. On Windows, the .ps1 scripts also need PowerShell 5.1 or later.

Clone the repository.

git clone <repository-url> ai-memory-mcp && cd ai-memory-mcp

Run the setup command for your platform.

macOS and Linux:

./scripts/setup.sh --memory-root ~/AI-Memory --install-clients

Windows (PowerShell):

.\scripts\setup.ps1 -MemoryRoot 'C:\path\to\AI-Memory' -InstallClients

Restart each configured client.
Ask the agent to call memory_status.
Check that every layer is healthy.

Setup creates the .venv environment and installs the project with its local embedding model. It writes the .env file, creates the internal data under AI_MEMORY_WORK_DIR/.ai-memory/, and publishes the first index generation. The --install-clients option registers the server and the skill with each supported client.

To add the starter dashboard, run this optional command.

macOS and Linux:

./.venv/bin/ai-memory-vault --root ~/AI-Memory

Windows (PowerShell):

.\.venv\Scripts\ai-memory-vault.exe --root 'C:\path\to\AI-Memory'

After setup, agents search and save memory on their own. You can also ask directly:

"Remember that the staging database uses port 5433."
"What did we decide about the retry policy?"

For more detail, read the installation guide and the AI agent setup guide.

Go deeper

MCP tools

Tool	Function
`memory_recall`	Returns cited Markdown and artifact evidence.
`memory_artifact_read`	Returns ordered raw context for one `artifact://` citation.
`memory_upsert`	Creates or updates one validated canonical record.
`memory_sync`	Publishes one coordinated generation after a canonical change.
`memory_status`	Reports strict health for every required layer.

Command-line tools

Command	Function
`ai-memory-mcp`	Runs the MCP server.
`ai-memory-sync`	Publishes one generation: Markdown index, artifact index, and note graph.
`ai-memory-artifact`	Manages the canonical artifact database. It supplies `ingest`, `search`, `read`, `pending`, `backup`, `check`, and `restore`.
`ai-memory-vault`	Creates the starter vault layout.
`ai-memory-collection`	Creates a typed collection with an Obsidian Base.
`ai-memory-migrate`	Moves a legacy vault to the current layout with snapshots and rollback.
`ai-memory-benchmark`	Runs the frozen retrieval benchmark.

Quality gates

The frozen benchmark contract requires these results:

A pass rate of 1.0, with recall at 5 of 1.0.
A no-answer accuracy of 1.0.
No scope leakage and no citation failures.
An approximate-search candidate recall at 10 of at least 0.95.

The benchmarks use synthetic data only. Read the retrieval reliability validation for the measured results and the capacity evidence.

Documentation

The documentation index links to every guide.

Installation and Configuration
Operations, including the upgrade from the earlier Graphify-based release
Architecture and Artifact storage
Markdown intake contract
Development and Validation
Skill discovery stubs

The independent Graphify Codebase skill indexes software repositories. It never supplies data to AI Memory retrieval.

Contributing

This is a public repository. It contains only neutral examples and synthetic benchmark fixtures. The user memory directory, generated indexes, logs, and the .env file stay outside Git. Read AGENTS.md and the writing standard before you change this repository.

Available Tools

3 tools

memory_recallB

Read-onlyIdempotent

Recall cited memory and its applicable relationships.

Name	Required	Description	Default
`limit`	No	Maximum evidence records.
`query`	Yes	Natural-language question or exact memory identity.
`status`	No	Memory lifecycle status.	active
`ticket`	No	Optional ticket identifier.
`project`	No	Optional project identifier.
`source_id`	No	Optional configured memory source ID.
`repository`	No	Optional repository identifier.
`root_scope`	No	Optional memory domain.
`path_prefix`	No	Optional canonical path prefix.

Output Schema

Name	Required	Description
`query`	Yes
`intent`	Yes
`status`	Yes
`evidence`	No
`warnings`	No
`citations`	No
`relationships`	No

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context about returning 'applicable relationships,' which is not captured by annotations, but it does not disclose return format or any additional behavioral details such as result ordering or potential empty results. This is minimally adequate given annotation coverage.

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 entire description is one concise sentence: 'Recall cited memory and its applicable relationships.' It is front-loaded, contains no filler, and directly states the core action. Every word adds meaning, achieving high efficiency without unnecessary elaboration.

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?

The tool has an output schema, comprehensive parameter descriptions, and safety annotations, shifting the burden from the description to these structured fields. The description leaves some ambiguity around what 'applicable relationships' means, but given the rich schema and annotations, the description is sufficiently complete for its context. A brief note on typical use cases would improve it further.

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?

Schema description coverage is 100%, with every parameter including a meaningful description. The tool description adds no additional parameter semantics beyond the schema, so the baseline of 3 applies. The description's mention of 'applicable relationships' implies the query parameter relates to memory retrieval, but it does not clarify parameter interplay or defaults.

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 provides a specific verb ('Recall') and resource ('memory'), and adds 'applicable relationships' to distinguish the scope. It clearly identifies a retrieval operation, though 'cited memory' is somewhat ambiguous and does not fully distinguish from sibling tools like memory_status or memory_sync.

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?

The description gives no explicit guidance on when to use this tool versus alternatives such as memory_sync or memory_status. The intended use is implied by the name, but the description does not state when to prefer this over the sibling tools or mention any contexts that would make this the right choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_statusA

Read-onlyIdempotent

Report source, index, Graphify, and runtime status.

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
`ok`	Yes
`index`	Yes
`logging`	Yes
`runtime`	Yes
`graphify`	Yes
`checked_at`	Yes
`retrieval_sources`	No
`canonical_memory_root`	Yes

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the safe read-only nature. The description adds value by disclosing exactly which status areas are covered (source, index, Graphify, runtime), providing useful context beyond the structured annotations. Given the presence of an output schema, return format is already documented, so the description's additional scope detail is adequate.

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, concise sentence that directly states the tool's function without any unnecessary words or repetition. It is front-loaded and easily parsed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no parameters, a rich output schema, and clear annotations covering safety and idempotency. The description succinctly captures the essential scope of the status report. There is no missing critical information for an agent to select and invoke it correctly.

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?

The tool has zero parameters, so no parameter explanations are needed. Per the rubric, a baseline of 4 is appropriate for no parameters. The schema's 100% coverage (trivially) means there is no gap to compensate for.

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 uses the specific verb 'Report' and identifies the resource as status, breaking down four distinct components: source, index, Graphify, and runtime. This clearly distinguishes it from sibling tools like memory_recall and memory_sync, which imply different operations (retrieval and synchronization respectively).

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 is provided about when to use this tool instead of memory_recall or memory_sync. The description only states what the tool does, without mentioning appropriate conditions, exclusions, or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

memory_syncA

Update the derived index from canonical Markdown.

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
`ok`	Yes
`index`	Yes

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations (readOnlyHint=false, destructiveHint=false) already indicate the tool modifies state without being destructive. The description adds meaningful context by specifying the target ('derived index') and the source ('canonical Markdown'), providing domain-specific behavior not captured by annotations.

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, compact sentence (7 words) that immediately states the tool's purpose. Every word earns its place, with no wasted text or repetition of schema details.

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 zero-parameter synchronization tool with an output schema (as indicated in context signals), the description is largely complete. It clearly communicates the operation and source. Minor gaps include not defining what 'derived index' means or when a sync is necessary, but the simplicity of the tool mitigates this.

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?

The tool has zero parameters, so the input schema is essentially empty. With no parameters to document, the description carries the full semantic load by indicating what the tool acts upon ('canonical Markdown'), which clarifies that the input comes from elsewhere rather than explicit arguments.

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 'Update the derived index from canonical Markdown' clearly states a specific action (update) on a specific resource (derived index) with a clear source (canonical Markdown). This distinguishes it from sibling tools like memory_recall and memory_status, which suggest reading and status operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used to sync/update the derived index when canonical Markdown changes, but it does not explicitly mention when to use it versus alternatives, nor does it provide exclusion criteria. Usage is implied rather than directly stated.

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.

3 tool updatesv0.1.0Jul 31, 2026
- First observedmemory_recall
- First observedmemory_status
- First observedmemory_sync

Deploy Server

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

TDQS

A3.9/5.0

Scored 2026-07-31 19:01 across 3 tools

Disambiguation5/5

Each tool targets a distinct operation: recall for querying memories, sync for updating the index, and status for health checks. There is no overlap or ambiguity between these tools.

Naming Consistency5/5

All tool names follow the same 'memory_' prefix followed by a verb (recall, sync, status). This consistent pattern makes the tool roles predictable and easy to use.

Tool Count5/5

With 3 tools, the server is well-scoped and covers the core lifecycle of memory management (query, update, monitor). Each tool earns its place without unnecessary bloat.

Completeness3/5

The set lacks direct creation/deletion of memories and does not offer search or listing capabilities. While sync indirectly handles updates from Markdown, recall is limited to cited memories, creating notable gaps in a full memory lifecycle.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Related MCP Connectors

MemorySync AOAuth
io.memorysync
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
Autonomous Agents Developer Tools Knowledge & Memory
151
https://mcp.memorysync.io/mcp
Memwyre
io.github.memwyreai
Universal persistent memory and knowledge retrieval layer for AI agents and LLMs.
Knowledge & Memory RAG Systems
11
https://server.memwyre.tech/mcp/
goldhold
io.github.jerrysrodz
Persistent memory for AI agents. Search, store, and recall across sessions.
Knowledge & Memory Autonomous Agents RAG Systems
2
https://relay.goldhold.ai/mcp
mem0OAuth
io.github.mem0ai
Persistent memory for AI agents: add, search, update, and delete long-term memories.
Knowledge & Memory AI & Machine Learning
2
https://mcp.mem0.ai/mcp

Related MCP Servers

Engram Memory MCP
Knowledge & Memory RAG Systems
lumetra-io
A
license
Not graded
quality
D
maintenance
Combines bm25, vector and knowledge graphs to create a comprehensive memory solution. https://github.com/lumetra-io/engram-memory-mcp
Updated 6 months ago (2026-05-14 19:04 UTC)
1
MIT
BuildAutomata Memory MCP
Knowledge & Memory RAG Systems Vector Databases
brucepro
F
license
Not graded
quality
D
maintenance
Provides AI agents with persistent, searchable memory that survives across conversations using semantic search, temporal versioning, and smart organization. Enables long-term context retention and cross-session continuity for AI assistants.
Updated 10 months ago (2025-12-27 04:00 UTC)
14
-
Memsolus MCP Serverofficial
Knowledge & Memory RAG Systems Autonomous Agents
memsolus
A
license
A
quality
D
maintenance
Provides persistent long-term memory for AI agents through semantic search and automated knowledge graph extraction. It enables agents to store, recall, and reason over facts, preferences, and relationships across multiple conversations and sessions.
Updated 5 months ago (2026-06-06 18:33 UTC)
14
3 npm
MIT
Synapto
Knowledge & Memory Search
ramonlimaramos
A
license
Not graded
quality
A
maintenance
Provides persistent, searchable memory for MCP-compatible agents, enabling recall by meaning, automatic decay, trust scoring, and cross-agent handoffs.
Updated 2 months ago (2026-09-07 16:58 UTC)
21 PyPI
5
MIT

AI Memory MCP

Why AI Memory MCP

How it works

Five memory systems, one ranked answer

How results are ranked

Where the truth lives

A vault that organizes itself

What the vault looks like

Quick start

Go deeper

MCP tools

Command-line tools

Quality gates

Documentation

Contributing

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Engram Memory MCP

BuildAutomata Memory MCP

Memsolus MCP Serverofficial

Synapto