What can you do with this server?

It is an MCP server for AI long-term memory management: it stores event packages as Markdown with a rebuildable SQLite index, and offers deterministic, stateless retrieval without vectors. * memory_write: create or update an event package (Markdown authoritative source + index upsert), with title, summary, tags, aliases, links, and dates. * memory_query: keyword-search event packages by ID/title/alias/tag/summary and return ranked Top-K candidates. * memory_query_anchors: search at a finer granularity inside sub-event anchors (##/### headings), useful for story packages or long bodies. * memory_read_section: read only a specific section of an event package by heading, saving context window. * memory_link: create a bidirectional link between two event packages. * memory_rebuild: fully rebuild the index from all .md front-matter if the index is corrupted; no data loss. * memory_ingest: ingest raw text, with AI-driven splitting into cohesive event packages, metadata generation, and auto-linking (falls back to a heuristic single-package mode if no LLM is configured).

Which integrations are available for this server?

Supports local LLM inference via Ollama for on-device AI memory operations. Provides integration with OpenAI's API for AI-assisted memory indexing and retrieval.

How do I use AI-MemoryHub MCP Server?

1. Click on "Install 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-MemoryHub MCP Server remember: switched to event-driven architecture for project X" 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.

de en es ja ko ru zh

AI-MemoryHub MCP Server

by Traceless-zero

Overview Schema Related Servers Score Discussions

Python

Local

AI Memory Hub (AI-MemoryHub)

A zero-dependency, model-agnostic long-term memory system for AI Agents: Markdown body as the authoritative source + a thin SQLite index, using deterministic retrieval instead of vector RAG, leaving "understanding" to the outer AI while the engine only does retrieval and abstention. Built on the CEMA (Cognitive Event-driven Memory Architecture) concept.

Personal project, independently developed via vibe coding: architecture and requirements designed by myself, code implemented with AI assistance.

Project Introduction

AI Memory Hub (AI-MemoryHub) splits "long-term memory" into two layers:

Backend body (authoritative source): Each memory is a Markdown file with YAML front-matter, storing all semantic content. Never participates in retrieval; fetched on demand by ID (i.e., "forgotten cold storage").
Frontend index (thin SQLite table): Stores id / title / summary / aliases / tags / linked / anchors / created / updated + features (sub-entity variant normalization) + four elements person / event_date / location / topic, fully rebuildable from the front-matter of all .md files. Retrieval happens only here; the body is fetched only after a unique ID is hit.

This design is called CEMA (thin frontend index + backend body, strict 1:1 between front and back, index fully rebuildable from body) — stateless retrieval, cheap storage that never forgets, and it sheds the operational weight of traditional memory systems (no vector infrastructure, no nightly LLM pipelines, agents write directly).

Designed with zero third-party dependencies (Python standard library only), it can interface with any AI large-model API; the understanding layer is handled by any AI client / Agent / paid LLM.

Naming convention: In this document, "AI Memory Hub (AI-MemoryHub)" is the project's official name; "HMA" specifically refers to its underlying architecture, Hybrid Memory Architecture. Identifiers in code such as the hma package name, MCP server name, and HMA_LLM environment variable remain unchanged.

Core Features

Event-based memory: Events are the only carrier; no classification into short/long-term or episodic/semantic
Strict front/back separation: thin SQLite index + Markdown body; index fully rebuildable from front-matter
No forgetting, full retention: no importance scoring, no forgetting curve; judgment is left to retrieval time
Deterministic recall against vector guesswork: zero vectors / zero embeddings; F-stage sub-entity variant normalization + C+A chapter-level disambiguation + READ body retrieval + loop queries
Tag-as-Mod package-level mounting: copy/delete a folder under memory = mount/unmount a piece of cognition
Model-agnostic: universal LLM adapter — Claude today, GPT tomorrow, local Ollama later, no code changes needed
Query contract enforcement: the MCP boundary validates every retrieval with QueryEnvelope checks (missing keywords/mode is rejected outright)

Architecture philosophy, retrieval taxonomy, and solution approaches are in the design documents under memory/项目/AIMH-design-journal/; the MCP tool list, engine API, retrieval mechanism, adapters, design invariants, and benchmark methodology all converge into 技术参考.md. This document only covers "what it is / how to run it."

Related MCP server: mcp-ltm

Project Structure

memory/ is the single authoritative store of AI Memory Hub (AI-MemoryHub). Each memory package = one .md event file (## heading tree + YAML front-matter) + an in-package index.db (thin index cache, fully rebuildable from .md front-matter; deleting it loses no data).

AIMH/
├── hma/                          # 引擎核心（零运行时依赖，仅标准库）
│   ├── hma_core.py             # Memory 类：write/query/query_anchors/resolve_query/read_section/link/rebuild/orchestrate/list_all_in_scope/ingest + derive_anchors/query_features/recall_multihop
│   ├── envelope.py             # QueryEnvelope 校验层（MCP 边界强制）
│   ├── cli.py                  # 命令行入口
│   ├── server.py               # MCP server（stdio JSON-RPC，8 工具）
│   ├── engine/                # 分支接口 / CLI（dispatch + @register + handlers）
│   ├── ingest.py              # AI 收录管线
│   ├── daylog.py / tree.py / llm_adapter.py
├── scripts/core/               # 独立确定性脚本（rebuild_index / relocate / migrate_*_memory / compact / deploy_mcp …）
├── skills/                      # 技能（项目级副本，与用户级 ~/.workbuddy/skills 双副本）
├── memory/                      # 权威记忆库（单一真相）
├── 一键更新记忆索引.exe          # 手动重建索引小程序（双击即用，零 AI）
├── pyproject.toml               # 零运行时依赖声明
└── README.md

Execution Flow

Installation

pip install -e .          # 提供 hma-mcp / hma 两个命令

pyproject.toml declares zero runtime dependencies (standard library only). No vector libraries or external services needed.

Three Usage Modes

1. Command line (manual / scripts)

python -m hma.cli --root memory write \
  --id proj-rag --title "放弃 RAG 主记忆" --summary "改事件驱动分层" \
  --tags project,decision --aliases "分层记忆" --body "# ...\n正文"

python -m hma.cli --root memory query "分层记忆" --top-k 5
python -m hma.cli --root memory link proj-rag todo-mcp
python -m hma.cli --root memory show  proj-rag
python -m hma.cli --root memory list
python -m hma.cli --root memory rebuild      # 删了 index.db 也能恢复

2. MCP server (connect any AI client) ⭐ Recommended

python -m hma.server --root memory
# 或 entry point： hma-mcp --root memory

JSON-RPC 2.0 over stdio, exposing 8 tools (corresponding to the three-level retrieval funnel L1→L2→L3 + write/link/rebuild/ingest):

Tool	Purpose
`memory_write`	Passively structured write of one event package (overwrites if id exists)
`memory_query`	L1 package-level deterministic retrieval, returns Top-K candidates (hit IDs)
`memory_query_anchors`	L2 chapter-level anchor retrieval, precisely locates a round/section by `##` heading (returns locator)
`memory_resolve`	Unified recall disambiguation entry: clarifies when multiple entities, otherwise returns Top-K; supports multi-hop + abstention gate
`memory_read_section`	L3 body retrieval: reads only that `##` section by (id, heading), zero redundancy
`memory_link`	Bidirectionally links two event packages
`memory_rebuild`	Fully rebuilds the index from `.md` files (`.md` is the authoritative source; no data loss)
`memory_ingest`	Active ingestion: user pastes text, AI runs the full pipeline (see below)

Any MCP client such as Claude Desktop / Codex / Cline / WorkBuddy just needs a config snippet:

{
  "mcpServers": {
      "aimh": {
        "command": "python",
        "args": ["-m", "hma.server", "--root", "/path/to/.memory"]
      }
  }
}

WorkBuddy plug-and-play deployment: the repo ships a one-click deployment script that copies the launcher into the WorkBuddy config directory, merges and writes out ~/.workbuddy/mcp.json (only touches the aimh connector, preserves everything else, auto-detects the python version, no hardcoded paths), and registers the ~/.hma_home pointer:

python scripts/core/deploy_mcp.py            # 部署（幂等，可重跑）
python scripts/core/deploy_mcp.py --dry-run  # 只预览将写出的配置

After deployment, click "Trust" in the WorkBuddy connector management page to activate the aimh connector, and the mcp__aimh__* tools appear in a new window.

⚠️ After modifying server.py, you need to disable→enable / re-Trust the connector for the long-running process to load the new code.

3. As a library (Python `import`)

from hma.hma_core import Memory
m = Memory("memory")
m.write(id="x", title="X", summary="s", tags=["t"], body="# X\n正文")
for rid, title, summary, score in m.query("x"):
    print(rid, score)

Writing and Ingestion

Active ingestion (memory_ingest) — the user pastes text, the AI executes the full pipeline: reads existing package summaries for link discovery → splits into event packages per CEMA cohesion + volume gates → generates metadata for each package → writes the .md authoritative source + upserts the index → establishes bidirectional links with existing/new packages. When no LLM API is configured, it degrades to single-package heuristics; the tool always works.

# 有 LLM：AI 自动拆分+关联
echo "周会：放弃 RAG，改事件驱动；下周三前完成 MCP 评审。" \
  | python -m hma.cli --root memory ingest --scope wb

# 无 LLM / 不想调模型：单包兜底
echo "随手记一条想法" | python -m hma.cli --root memory ingest --no-llm

Zero-cost path (Agent as the understanding layer): when no key is configured, let the current session Agent act as the understanding layer (load the aimh-ingest skill), with the deterministic engine doing the persistence — isomorphic and swappable with the paid LLM path. When the text type is uncertain, first load the aimh-intake meta-routing skill for classification decisions, then chain-load the corresponding skill (oc-dossier / aimh-ingest / aimh-project / memory-import) to persist; never write any memory/ files yourself.

Paid/local path: setting HMA_LLM (with the corresponding key/endpoint) automatically switches to the real LLM via llm_adapter, no code changes needed; LLM call failures automatically fall back to heuristics.

Timeline: Single-Day Record Packages (daylog)

The main memory store is organized by topic rather than timeline; daylog adds an orthogonal timeline without breaking the topic principle:

python -m hma.engine daylog add "一段叙事：这天发生的事" \
    --linked 主题包id --tags 关键词1,关键词2 [--date 2026-07-25]
python -m hma.engine daylog show 2026-07-25            # 全天
python -m hma.engine daylog show 2026-07-25 --q 关键词  # 精准搜寻
python -m hma.engine daylog range --start d1 --end d2

Time is a filter key, not a weight (locating = deterministic comparison of the date embedded in the id, no recency weighting). Vague time expressions ("the day before yesterday / last Wednesday") are resolved by the Agent into ISO dates before calling commands.

Context Compression Archiving (Circadian Rhythm · Agent as the Understanding Layer)

When the context window is nearly full, overflow content that has been fully discussed, not yet persisted, but may be needed later is judged for placement by the Agent + condensed into a summary, then deterministically written via scripts/core/compact.py:

python scripts/core/compact.py \
    --root memory --sink <daylog|cache|progress> \
    --summary "<冷凝摘要>" --source "<溢出来源>" \
    [--date YYYY-MM-DD] [--id <eid> --title "<标题>"] [--project <pid>] \
    [--linked a,b] [--tags x,y] [--conflict-event <id> --conflict-intro "<一句话>"]

Iron rule: compression = additive cold summary; the authoritative original text is never altered. Only when new information truly conflicts with an authoritative event is it overwritten, with an auditable trail appended.

Migrating External Memories

migrate_wb_memory / migrate_claude_memory / migrate_gemini_memory / migrate_codex_memory under scripts/core/ migrate each AI client's native long-term memory into AIMH, installing a retrievable CEMA frontend index:

python scripts/core/migrate_wb_memory.py     --wb-dir ".workbuddy/memory" --root memory/项目/AIMH-design-journal
python scripts/core/migrate_claude_memory.py  --root memory --namespace 其他
python scripts/core/migrate_gemini_memory.py  --root memory --namespace 其他
python scripts/core/migrate_codex_memory.py   --root memory --namespace 其他

Full list of migration scripts and philosophy: see 技术参考.md §8.

Advanced Retrieval (scope / abstention / multi-query / enumeration)

Several enhancement mechanisms at write and read time, detailed in 技术参考.md §7:

Focused scope: passing a directory path recalls only that subtree, shielding against cross-subtree interference (29 packages → 11 packages); narrows the scope only, does not replace abstention.
Abstention layer allow_abstain: insufficient coverage / out-of-domain queries explicitly return abstention to avoid fabrication (landed in V1.0, on by default).
Multi-query sub_queries: the AI provides a list of sub-questions at once; the engine deterministically fans out and merges, no separate round trips.
Enumeration enumerate: lists all packages in the scope subtree (not Top-K ranked).
Multi-hop multihop: BFS expansion along curated linked edges from write time to widen the cluster, filling relational/structural blind spots (opt-in).

All retrieval-type MCP calls are bound by the QueryEnvelope contract (q/keywords/mode required; missing ones are rejected with ENVELOPE_VIOLATION).

Current Status

Project status (2026-08-20): Due to exhaustion of LLM resources (free model quotas), this project is formally concluded and the development phase has ended. Code, documentation, and benchmark data remain in their current state; pending items (such as the full LoCoMo benchmark run) can be resumed at any time when resources become available.

Positioning: zero-dependency reference implementation + personal philosophy testbed — engineering validation of event-based memory, front/back separation, no-forgetting, anti-vector-guesswork design under zero dependencies, plus integration of the four-element recall retrieval, the F+C+A+READ three-stage anchor pipeline, and LoCoMo / MemoryStress benchmark evaluation.

Philosophies delivered: event-based memory · strict front/back separation · no-forgetting full retention · anti-vector deterministic recall · Tag-as-Mod package-level mounting · cross-window offline integration (circadian rhythm).

Engineering status:

Zero third-party runtime dependencies (Python standard library only)
MCP server exposes 8 tools (write / query / query_anchors / resolve / read_section / link / rebuild / ingest)
Four-element recall retrieval (person / event_date / location / topic) is a first-class field, soft-weighted at read time
Anchor-level retrieval upgraded to the F+C+A+READ three-stage pipeline (production engine closed-loop)
Abstention layer V1.0 landed (four gates + corpus_missing_entity hard rejection, allow_abstain on by default)
QueryEnvelope contract landed (MCP boundary enforces q/keywords/mode, multi-query fan-out sub_queries, enumeration list_all_in_scope)
Skills as plug-and-play client + resident proactive trigger skill (aimh-always)

Benchmark evaluation (real data closed-loop verified):

LoCoMo 1540 questions: hit@30 ≈ 99.6% / recall@30 ≈ 99.5% / hit@5 89.7–92%
MemoryStress 300 questions: baseline 77% / B_gold 89.7%

Full methodology (including red lines: OMEGA 38.3% not comparable, TrueMemory 93% as alignment target) in 技术参考.md §9.

Known gaps:

In-window real-time live-document integration reset (integrating fragments into existing body text mid-conversation) cannot be fully implemented under the current Transformer architecture; deferred to non-TF architectures (persistent-state SSM/Mamba-like, or true AGI)
MCP connector requires clicking "Trust" in the client to activate
Direct engine API calls bypass the QueryEnvelope constraint at the MCP boundary (expected isolation; test scripts going through the API are unaffected)
Architectural trade-off (capability ceiling at the AI layer): CEMA concentrates understanding (reduction / mode judgment / keyword extraction / sub_queries splitting / linked curation) on the AI layer, with the engine doing only deterministic execution. The benefit is a minimal, debuggable engine that gets smarter for free as AI improves; the cost is that AIMH's quality ceiling = the paired AI's intelligence ceiling — a weak AI degrades it into "a pretty file cabinet occasionally used wrong." Three buffers (envelope hard validation / write-time curation amortization / abstention gate fallback) turn "AI can be dumb" into "controllable and correctable," but do not eliminate that ceiling. See "Mathematical and Linguistic-Philosophical Thoughts on Recall Disambiguation" §11.5.

License

MIT

Available Tools

7 tools

memory_ingestA

主动收录：用户提供一段原始文本，AI 执行完整管线——理解并拆分为凝聚的事件包、生成结构化元数据、写入 .md 权威源 + 索引、与现有/新建包建立关联。模型由通用适配器决定（模型无关）。未配置 LLM API 时退化为单包启发式。

ParametersJSON Schema

Name	Required	Description
`text`	Yes	待收录的原始文本
`model`	No	可选，覆盖默认模型名
`scope`	No	作用域标签（如 user_global / workspace_x），会加进每个新包的 tags
`provider`	No	可选，覆盖默认 LLM 厂商：openai / anthropic
`auto_link`	No	是否自动建立关联，默认 true

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations provided, the description fully discloses behavioral aspects: it performs multiple steps (splitting, metadata generation, writing to .md and index, linking), is model-agnostic, and falls back to a heuristic when no LLM API is configured. This is comprehensive and avoids surprises.

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 two concise sentences that front-load the purpose and cover key aspects without redundancy. Every sentence adds value, including fallback behavior and model-agnostic property.

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 description thoroughly covers input handling and internal behavior but omits any mention of return values or output format. Given the absence of an output schema, the agent is left without information on what the tool returns, which is a minor gap.

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 covers 100% of parameters with descriptions, so the description does not need to add parameter details. It provides overall pipeline context but no additional parameter-level semantics beyond what the schema offers, meeting the baseline expectation.

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's function: accepting raw text and executing a full pipeline to split into event packets, generate metadata, write to authoritative source with indexing, and establish links. It distinguishes from sibling tools like memory_write (which likely writes a single packet) and memory_link (which creates associations) by describing a more comprehensive ingestion process.

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 usage for ingesting raw text into the memory system, but does not explicitly state when to use this over alternatives or provide exclusion criteria. The context from sibling tools makes it clear this is for initial ingestion versus querying or linking, but explicit guidance is missing.

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

memory_linkA

双向关联两个事件包（更新两者 front-matter 的 linked 字段）。

ParametersJSON Schema

Name	Required	Description	Default
`a`	Yes	事件包 ID
`b`	Yes	事件包 ID

TDQS

A3.8/5.0

Behavior3/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 the bidirectional update to linked fields, but does not mention potential side effects, reversibility, or permission requirements.

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, front-loaded with action and effect, no extraneous information.

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 simplicity of the tool (2 parameters, no output schema), the description is nearly complete. Could mention what 'bidirectionally link' means operationally, but overall sufficient.

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 coverage is 100% with each parameter described as '事件包 ID'. The description does not add extra meaning beyond the schema, so baseline of 3 is appropriate.

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 verb 'bidirectionally link' and the resource 'two event packages', specifying it updates the linked field in both front-matters. This distinguishes it from siblings like memory_write or memory_query.

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 usage for linking event packages but provides no explicit guidance on when to use this tool versus alternatives like memory_write or memory_query. It lacks when-not-to-use or prerequisites.

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

memory_queryA

确定性无状态检索：在 id/title/alias/tag/summary 上做关键词匹配，返回按确定性规则排序的 Top-K 候选（命中唯一 ID）。不依赖热度/权重。

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	检索关键词
`top_k`	No	返回条数，默认 5

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, description discloses statelessness, determinism, matching fields, sorting rules, and non-reliance on weights. It does not mention side effects or rate limits, but provides adequate behavioral context.

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?

Description is a single concise sentence with no redundant information, front-loading the core action and key characteristics.

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 simple query tool with 2 parameters and no output schema, the description covers purpose, matching fields, sorting, and behavior. It could mention the return format explicitly but is otherwise complete.

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?

Schema coverage is 100% with descriptions for both parameters. The description adds value by specifying the fields searched and sorting criteria beyond the schema's parameter descriptions.

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?

Description clearly states it is a deterministic stateless retrieval tool for keyword matching on id/title/alias/tag/summary, and distinguishes itself from siblings by noting it does not rely on popularity/weights.

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?

Description implies use for deterministic keyword matching without popularity bias, but does not explicitly state when to use this tool versus siblings like memory_query_anchors or memory_read_section.

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

memory_query_anchorsA

锚点层细粒度召回：在事件包的 anchors 子事件锚点上做关键词匹配，返回命中的子事件（包ID + 锚点标题 + 摘要 + 定位 + 分数）。用于故事包/长正文按剧情节点召回——当 memory_query 命中率低时，anchors 往往能把内容词召回（如「幽影核心」「圣保罗之焰」「纽约之战」）。

ParametersJSON Schema

Name	Required	Description	Default
`q`	Yes	检索关键词（剧情/事件/特征词）
`top_k`	No	返回条数，默认 5

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It explains the matching behavior and return fields, but does not disclose side effects, authorization needs, or limitations such as whether it is read-only or if it modifies data.

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 three concise sentences, with no fluff. The key information (what, how, when) is front-loaded and efficiently communicated.

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 simple tool with two parameters and no output schema, the description is fairly complete. It explains what the tool does, what it returns, and its typical use case. No major gaps are present.

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?

Schema description coverage is 100%, but the description adds context: the tool matches on anchor sub-events within story packages, clarifying the domain of the 'q' parameter. This goes beyond the schema descriptions.

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's function: fine-grained recall on anchor sub-events via keyword matching, returning specific fields (package ID, anchor title, summary, location, score). It also distinguishes itself from siblings by mentioning its use for story packages/long texts and when memory_query has low hit rate.

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 explicitly says to use this tool when memory_query has low hit rate, providing a clear usage scenario. It implies alternatives (memory_query) but does not explicitly state when not to use it.

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

memory_read_sectionA

按小标题精准读取事件包正文的某一段（而非整包），节省上下文窗口。配合 memory_query_anchors 使用：先 query_anchors 拿到命中的 locator，再用本工具按 locator 取该段正文。heading 为正文里 ## / ### 小标题的片段（包含匹配），可直接用 locator 值。

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	事件包 ID
`heading`	Yes	小标题片段（##/### 标题的包含匹配，可用 query_anchors 返回的 locator）

TDQS

A4.6/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It explains reading by heading and use of locator. Implies read-only operation, but not explicitly stated. No contradictions.

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 in Chinese, front-loaded with purpose, then usage. No extraneous information. Efficient.

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?

Simple tool with 2 required params and no output schema. Description covers usage pattern and parameter meaning, mentions context saving. Not 5 because missing behavior on missing heading, but adequate.

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?

Schema has 100% coverage, so baseline 3. Description adds meaning: heading is a subtitle fragment and can be locator from query_anchors. Adds value beyond schema.

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?

Description states it reads a specific section of an event package body by subtitle, saving context window. Distinguishes from siblings like memory_query_anchors (which finds locators) and memory_query (likely retrieves full package). Verb '读取' and resource are specific.

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

Usage Guidelines5/5

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

Explicitly instructs to use with memory_query_anchors: first query_anchors to get locator, then this tool with locator. Provides clear when-to-use and usage pattern.

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

memory_rebuildA

从所有 .md 的 front-matter 全量重建 index.db。索引损坏时调用——.md 是权威源，重建不丢数据。

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It states that .md is authoritative and rebuild doesn't lose data, which reassures about safety. However, it doesn't detail whether existing index data is overwritten or merged, or if any permissions are needed.

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 two short sentences in Chinese, extremely concise. It front-loads the action and condition, with no 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 no parameters and no output schema, the description covers purpose and usage condition adequately. It could mention the effect on other tools (e.g., index becomes current) but that's not critical.

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?

There are zero parameters, so schema coverage is 100% by default. The description adds no parameter details, but that's acceptable as no parameters exist. Baseline of 4 is appropriate.

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's purpose: rebuilding index.db from all .md front-matter. It specifies the authoritative source (.md) and that data is not lost, distinguishing it from siblings like memory_write or memory_query.

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 explicitly says 'call when index is corrupted', providing a clear usage condition. It implies not to use it for normal operations, though it doesn't list alternative tools or when not to use it.

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

memory_writeA

写/改一个事件包：原子写 .md（权威源）+ 确定性 upsert 索引。id 存在则覆盖更新。tags/aliases/linked 为字符串数组。

ParametersJSON Schema

Name	Required	Description
`id`	Yes	事件包唯一 ID（文件名）
`body`	No	Markdown 正文
`tags`	No	标签；trivial 表示琐碎内容（检索降权）
`title`	No	标题
`linked`	No	关联的其他事件包 ID
`aliases`	No	别名/同义词，用于检索命中
`created`	No	创建日期 YYYY-MM-DD（可选）
`summary`	No	一句话摘要
`updated`	No	更新日期 YYYY-MM-DD（可选）

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses atomic write, upsert, and overwrite behavior, but lacks details on auth, rate limits, failure modes, or concurrency. Basic behavioral info is present but not comprehensive.

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, no wasted words. The description is front-loaded with the core action and efficiently covers key behavior.

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?

Given no output schema, the description does not explain return values. It also omits usage of optional body, trivial tag implications, and idempotency. Adequate but incomplete for a tool with 9 parameters.

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?

All parameters have schema descriptions (100% coverage). The tool description does not add significant meaning beyond the schema; it merely confirms that tags/aliases/linked are string arrays. Baseline of 3 is appropriate.

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 writes/modifies an event package with atomic write and upsert. It uses specific verbs and resource, and distinguishes from sibling tools like memory_query (query) and memory_read_section (read).

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 this is the primary write tool but does not explicitly state when to use it vs alternatives like memory_ingest. No when-not-to-use guidance is provided.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.1.0Jul 28, 2026
- First observedmemory_ingest
- First observedmemory_link
- First observedmemory_query
- First observedmemory_query_anchors
- First observedmemory_read_section
- First observedmemory_rebuild
- First observedmemory_write

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

All seven tools have clearly distinct purposes: writing/updating events, querying, linking, anchor-level search, section reading, index rebuilding, and intelligent ingestion. No overlap in functionality.

Naming Consistency5/5

All tools follow a consistent 'memory_' prefix with a verb_noun pattern (e.g., memory_write, memory_query, memory_link). The naming is predictable and systematic.

Tool Count5/5

With 7 tools, the server is well-scoped. Each tool addresses a specific need for managing memory events without unnecessary bloat or deficiency.

Completeness3/5

The set covers writing, querying, linking, section reading, and maintenance. However, it lacks an explicit deletion tool and a way to retrieve full event packages, which are notable gaps for a complete lifecycle.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mifactory-agent-memory C
io.github.mifactory-bot
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Knowledge & Memory Autonomous Agents Agent Orchestration
22
Agentage MemoryOAuth
io.agentage
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Knowledge & Memory File Systems
2
memnodeOAuth
dev.memnode
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Knowledge & Memory Autonomous Agents Agent Orchestration
2
NeuroStack
io.github.raphasouthall
Token-efficient MCP memory for Markdown vaults. Tiered search, GraphRAG, AI memories.
Knowledge & Memory RAG Systems Vector Databases
247

Related MCP Servers

Mneme Memory MCP
Knowledge & Memory File Systems
ethos-zero
A
license
A
quality
B
maintenance
A local-first shared memory layer for MCP-aware agents like Claude, Codex, and Hermes, enabling persistent memory across chats and clients via Markdown files and SQLite FTS.
Updated a month ago (2026-07-24 12:33 UTC)
6
2
MIT
mcp-ltm
Knowledge & Memory Search
kvas-it
A
license
Not graded
quality
D
maintenance
Provides persistent long-term memory for AI assistants with tag-based retrieval, wiki-style linking, and source references, storing memories as markdown files with SQLite index.
Updated 8 months ago (2026-01-20 13:45 UTC)
1
MIT
ai-dememory
Knowledge & Memory Search
GonzaloTorreras
A
license
B
quality
A
maintenance
Personal multi-LLM memory repository using Markdown as source of truth, SQLite FTS5 for retrieval, and MCP tools for search, context, and write proposals.
Updated 5 days ago (2026-09-01 21:16 UTC)
74
Apache 2.0
Agentic Memory
Knowledge & Memory Search
ArkaAiAdmin
A
license
A
quality
B
maintenance
MCP server for persistent, cross-session, local-first memory for AI agents, storing memories as Markdown files with SQLite indexing for hybrid search.
Updated 10 hours ago (2026-09-06 13:41 UTC)
24
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Traceless-zero/AI-MemoryHub'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

AI Memory Hub (AI-MemoryHub)

Project Introduction

Core Features

Project Structure

Execution Flow

Installation

Three Usage Modes

1. Command line (manual / scripts)

2. MCP server (connect any AI client) ⭐ Recommended

3. As a library (Python import)

Writing and Ingestion

Timeline: Single-Day Record Packages (daylog)

Context Compression Archiving (Circadian Rhythm · Agent as the Understanding Layer)

Migrating External Memories

Advanced Retrieval (scope / abstention / multi-query / enumeration)

Current Status

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

3. As a library (Python `import`)