What can you do with this server?

This server provides durable, cited memory recall and maintenance for AI agents through MCP tools. * memory_recall: Search and retrieve cited memory evidence using natural-language queries or exact identifiers, with optional filters for project, repository, status, root scope, path prefix, source ID, and ticket; returns evidence, citations, relationships, and warnings. * memory_artifact_read: Read ordered raw source context around an artifact:// citation. * memory_sync: Refresh derived indexes from canonical Markdown and publish a coordinated, validated generation snapshot. * memory_status: Report health and status of canonical memory sources, indexes, Graphify, logging, and runtime.

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

AI Memory MCP gives agents one stable interface for durable memory. The server combines exact, lexical, semantic, and graph results into cited evidence.

Two canonical stores

The system keeps two classes of data, and each class has one authority.

Data class	Authority	Contents
Distilled memory	Markdown vaults	Summaries, decisions, resolutions, and durable facts
Raw artifacts	Artifact database	Chats, meetings, transcripts, revisions, and tombstones

The primary Markdown vault is the only Markdown write authority. Additional Markdown vaults are retrieval-only sources. A provider adapter supplies raw artifacts through validated batches.

Each authority stays inside its own class. A Markdown file never becomes authoritative for a transcript. The artifact database never becomes authoritative for an agent summary.

All retrieval indexes are derived data. The system rebuilds each index from its own canonical store.

AI Memory keeps internal data under AI_MEMORY_WORK_DIR/.ai-memory/. The hidden directory keeps raw data, backups, indexes, state, and logs separate from Markdown notes.

Read the architecture guide for the complete design rules. Read the retrieval reliability validation for quality and capacity evidence.

Related MCP server: BuildAutomata Memory MCP Server

System architecture

flowchart TB
    Clients["MCP clients<br/>Claude, Codex, Copilot, VS Code, OpenCode"]
    Facade["MCP facade<br/>four public tools"]
    Service["MemoryService<br/>policy and orchestration"]
    Engine["RetrievalEngine<br/>scope, fusion, and reranking"]

    subgraph Derived["Derived indexes"]
        direction LR
        MdIndex["Markdown index<br/>FTS5 and vectors"]
        ArtIndex["Artifact index<br/>raw FTS and source representations"]
        Graph["Graphify graph<br/>nodes and paths"]
    end

    subgraph Canonical["Canonical stores"]
        direction LR
        Vaults["Markdown vaults"]
        Store["Artifact database"]
    end

    Provider["Provider adapter<br/>outside this repository"]

    Clients --> Facade
    Facade --> Service
    Service --> Engine
    Engine --> MdIndex
    Engine --> ArtIndex
    Engine --> Graph
    Vaults --> MdIndex
    Vaults --> Graph
    Store --> ArtIndex
    Provider --> Store
    Store -. agent distillation .-> Vaults

The provider adapter owns authentication, paging, and remote cursors. AI Memory owns validation, storage, search, and citations.

Main components

Component	Responsibility
Primary Markdown vault	Stores all new distilled records.
Retrieval-only vaults	Supply extra records without receiving writes.
Artifact database	Stores each raw message and transcript cue as one record.
Object storage	Holds attachment bytes by content hash, outside SQLite.
Memory indexer	Validates records and publishes versioned SQLite snapshots.
Artifact search	Supplies raw candidates from a full-text index.
Artifact semantic index	Supplies complete source segments and bounded reply context.
Local semantic index	Supplies paraphrase candidates with Model2Vec embeddings or a hashed fallback.
Graphify adapter	Supplies relationships, neighbors, and paths behind a replaceable boundary.
Retrieval engine	Applies scope, RRF fusion, reranking, and context expansion.
MCP facade	Supplies the stable public tools and evidence packets.
Canonical skill	Gives agents the memory workflow and safety rules.

Query architecture

memory_recall is the only recall tool. The service selects exact, search, neighbor, or relationship behavior. The retrieval engine combines all provider work internally.

flowchart TB
    Query["memory_recall<br/>query and scope"]
    Scope["Apply scope filters"]
    Md["Markdown retrieval<br/>lexical, semantic, graph"]
    Art["Artifact retrieval<br/>raw text and source representations"]
    Fuse["Fuse with RRF<br/>one rank sequence for each producer"]
    Rank["Rerank and expand context"]
    Result["Versioned result<br/>with citations and coverage"]

    Query --> Scope
    Scope --> Md
    Scope --> Art
    Md --> Fuse
    Art --> Fuse
    Fuse --> Rank
    Rank --> Result

The engine applies scope before it ranks each provider result. Each producer owns its own rank sequence, so no producer loses weight through list order. Exact identifiers receive bounded bonuses during reranking.

Response version 2 separates execution state from result kind. It returns useful ranked raw candidates without an exact-phrase requirement. Raw historical evidence receives no automatic age penalty. Clients must read citations before they make factual claims.

Use memory_artifact_read to read ordered source context around an artifact:// citation.

Refresh architecture

memory_sync publishes one coordinated derived generation after a canonical change.

flowchart TB
    MdChange["Markdown change"] --> Sync["memory_sync"]
    ArtChange["Artifact batch ingest"] --> Sync
    Sync --> Stage["Build staged indexes"]
    Stage --> Md["Stage Markdown vectors"]
    Stage --> Art["Stage artifact vectors"]
    Stage --> Graph["Stage Graphify"]
    Md --> Validate{"Validate all layers"}
    Art --> Validate
    Graph --> Validate
    Validate -->|pass| Publish["Publish one generation pointer"]
    Validate -->|fail| Keep["Keep the previous generation"]
    Publish --> Health["Run health and retrieval checks"]

Each recall pins one published generation and one artifact database read snapshot. The recall never combines components from different generations.

The system retains the active generation and one verified previous generation. Retention removes only derived snapshots. Retention never removes canonical artifacts or required object files.

A failed refresh never changes either canonical store.

Command-line tools

Command	Function
`ai-memory-mcp`	Runs the MCP server.
`ai-memory-index`	Builds the derived Markdown index.
`ai-memory-artifact`	Manages the canonical artifact database.
`ai-memory-benchmark`	Runs the frozen retrieval benchmark.
`ai-memory-real-world-benchmark`	Runs the mixed synthetic workload benchmark.

ai-memory-artifact is the only write path for raw artifacts. It supplies ingest, search, read, pending, backup, check, and restore. The MCP facade never exposes an artifact write operation.

MCP tools

Tool	Function
`memory_recall`	Returns cited Markdown and artifact evidence.
`memory_artifact_read`	Returns ordered raw context for one artifact reference.
`memory_sync`	Publishes one coordinated generation after a canonical change.
`memory_status`	Reports strict health for every required layer.

Reliability and performance

The repository pins Graphify 0.9.26 in an isolated environment.
Scope filters run before provider ranking.
RRF combines independent provider rankings.
Bounded reranking limits query work.
One query loads context for all returned records.
Recall results omit internal provider diagnostics.
Incremental indexing skips unchanged Markdown files.
Incremental artifact indexing uses the committed change journal and bounded context dependencies.
Large vector corpora use ANN candidates with exact reranking.
Versioned generations preserve the last satisfactory state.
Recall uses only components from one generation.
Health reports missing and stale layers.
Artifact intake validates a complete batch before it changes SQLite.
Artifact backups verify a restored copy against the same digest.
A redaction moves object bytes to quarantine, because the project never deletes a file.
Evidence packets include canonical source paths and artifact references.
Source IDs keep identical vault paths separate.

Quick start

AI Memory MCP runs on Windows, macOS, and Linux.

Install these items:

Git
Python 3.11 or later
A Markdown memory directory

Windows additionally requires PowerShell 5.1 or later if you use the .ps1 entry points.

Open a terminal in the repository root. Then, run the command for your platform.

Windows (PowerShell):

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

macOS and Linux:

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

Every maintenance script has a .ps1 wrapper, a .sh wrapper, and one shared Python implementation, so either shell produces the same result.

Restart each configured client after the setup procedure is complete.

For more setup information, read the installation guide. For agent setup, read the AI agent setup guide.

Repository layout

Path	Contents
`src/ai_memory_mcp/`	MCP server, retrieval engine, indexer, and adapters
`src/ai_memory_mcp/artifacts/`	Artifact schema, intake, search, bursts, and backup
`scripts/`	Setup, client installation, and Graphify operations
`skill/ai-memory/`	Canonical AI Memory skill
`graphify-codebase/`	Independent codebase-indexing skill and wrapper
`tests/`	Automated behavior and portability tests
`benchmarks/`	Frozen retrieval contract and fixtures
`docs/`	Architecture, setup, operations, and validation guides

Documentation

The documentation index gives links to all project guides.

Skill discovery stubs

This repository contains two canonical skills:

skill/ai-memory/SKILL.md
graphify-codebase/skill/graphify/SKILL.md

AI harnesses must contain discovery stubs instead of canonical skill copies. A stub carries only the metadata a host needs to discover and trigger the skill, then redirects to the canonical SKILL.md. This keeps one source of truth and survives repository moves.

Use this stub pattern:

[Add any host-specific skill metadata here if the target platform expects a
header before YAML frontmatter]

---
name: <canonical-name>
description: <copy the exact canonical description>
---

Before following any instruction in this stub, first check the canonical skill
header in '<canonical-path>'. If the source skill metadata has changed and this
stub is out of date, update this stub to match the current source skill
metadata before proceeding.

Then read the SKILL.md in full from '<canonical-path>'

Rules:

Keep the stub folder name exactly the same as the canonical skill folder.
Copy the canonical description exactly, so host triggering is unchanged.
Copy any other metadata the target platform requires for discovery, in the header format and location that platform expects.
The stub must tell the agent to compare its own header against the canonical header and update itself whenever the canonical metadata changes. A stale description stops a host from triggering the skill at all.
Never copy the canonical skill body into a stub.

Run .\scripts\install-clients.ps1 (or ./scripts/install-clients.sh) after a clone or repository move. The installer writes the correct canonical path into each stub.

Read the Graphify Codebase guide for its independent boundary.

Source boundary

This is a public repository. This repository contains all project source files. It contains only neutral examples and synthetic benchmark fixtures. The user memory directory stays outside Git. Generated indexes, logs, and recovery files also stay outside Git. Machine-specific and organization-specific values stay in the ignored .env file.

Read AGENTS.md before you change this repository.

Available Tools

3 tools

memory_recallB

Read-onlyIdempotent

Recall cited memory and its applicable relationships.

ParametersJSON Schema

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

ParametersJSON 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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON 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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON 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

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

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

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

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

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 4 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 9 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 3 months ago (2026-06-06 18:33 UTC)
14
12 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 8 days ago (2026-09-07 16:58 UTC)
5
MIT

AI Memory MCP

Two canonical stores

System architecture

Main components

Query architecture

Refresh architecture

Command-line tools

MCP tools

Reliability and performance

Quick start

Repository layout

Documentation

Skill discovery stubs

Source boundary

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