de en es ja ko ru zh

AI-MemoryHub MCP Server

Name: AI-MemoryHub MCP Server
Author: Traceless-zero

by Traceless-zero

Overview Schema Related Servers Score Discussions

Python

Local

AI记忆中枢（AI-MemoryHub）

Sistema de memoria a largo plazo para AI Agents, sin dependencias y agnóstico del modelo: el cuerpo en Markdown como fuente autoritativa + un índice SQLite ligero, que sustituye el RAG vectorial por recuperación determinista, dejando la «comprensión» a la IA externa y limitando el motor a la recuperación y la abstención. Construido sobre el concepto de CEMA (Cognitive Event-driven Memory Architecture, arquitectura de memoria cognitiva dirigida por eventos).

Proyecto personal, desarrollado de forma independiente con vibe coding: el diseño de arquitectura y requisitos lo he realizado yo, y el código ha sido implementado con ayuda de IA.

Introducción al proyecto

AI记忆中枢（AI-MemoryHub） divide la «memoria a largo plazo» en dos capas:

Cuerpo en segundo plano (fuente autoritativa): cada memoria es un archivo Markdown con front-matter YAML que almacena todo el contenido semántico. Nunca participa en la recuperación; se accede a él por ID cuando se necesita (es decir, «almacenamiento en frío olvidado»).
Índice frontal (tabla SQLite ligera): almacena id / title / summary / aliases / tags / linked / anchors / created / updated + features (normalización de variantes de subentidades) + los cuatro elementos person / event_date / location / topic, y puede reconstruirse por completo a partir del front-matter de todos los .md. La recuperación ocurre solo aquí; solo después de acertar un ID único se obtiene el cuerpo.

Este diseño se denomina CEMA (índice frontal ligero + cuerpo en segundo plano, con una estricta relación 1:1 entre ambos y un índice totalmente reconstruible a partir del cuerpo) — recuperación sin estado, almacenamiento barato que no olvida, y elimina el peso operativo de los sistemas de memoria tradicionales (sin infraestructura vectorial, sin canalizaciones LLM nocturnas, escritura directa del agente).

Diseñado con cero dependencias de terceros (solo la biblioteca estándar de Python), puede conectarse a cualquier API de modelos grandes de IA; la capa de comprensión puede recaer en el cliente de IA, el agente o un LLM de pago.

Convención de nomenclatura: en este documento, «AI记忆中枢（AI-MemoryHub）」 es el nombre oficial del proyecto; «HMA» se refiere específicamente a su arquitectura subyacente Hybrid Memory Architecture (arquitectura híbrida de memoria). Los identificadores en el código, como el nombre del paquete hma, el nombre del servidor MCP y la variable de entorno HMA_LLM, permanecen sin cambios.

Características principales

Memoria basada en eventos: el evento es el único vehículo; no se clasifica en corto/largo plazo ni episódica/semántica.
Separación estricta entre frontal y fondo: índice SQLite ligero + cuerpo Markdown; el índice puede reconstruirse por completo a partir del front-matter.
Sin olvido, retención total: sin puntuaciones de importancia ni curvas de olvido; el juicio se deja para el momento de la recuperación.
Recuperación determinista contra la adivinación vectorial: cero vectores/cero embeddings; normalización de variantes de subentidades en la etapa F + desambiguación a nivel de capítulo C+A + obtención del cuerpo con READ + consultas en bucle.
El tag como Mod: montaje/desmontaje a nivel de paquete: copiar/eliminar una carpeta bajo memory equivale a montar/desmontar un bloque cognitivo.
Agnóstico del modelo: adaptador LLM genérico; hoy Claude, mañana GPT, pasado mañana Ollama local, sin cambiar código.
Contrato de consulta obligatorio: el límite de MCP valida cada recuperación con QueryEnvelope (si faltan keywords/mode, se rechaza directamente).

La filosofía de arquitectura, la taxonomía de recuperación y el enfoque de solución se encuentran en los documentos de diseño bajo memory/项目/AIMH-design-journal/; la lista de herramientas MCP, la API del motor, los mecanismos de recuperación, los adaptadores, los invariantes de diseño y los criterios de referencia están todos consolidados en 技术参考.md. Este documento solo explica «qué es / cómo se ejecuta».

Related MCP server: mcp-ltm

Estructura del proyecto

memory/ es el almacén autoritativo único de AI记忆中枢（AI-MemoryHub）. Cada paquete de memoria = un archivo de evento .md (árbol de títulos ## + front-matter YAML) + un index.db dentro del paquete (caché de índice ligero, totalmente reconstruible a partir del front-matter de los .md; eliminarlo no pierde datos).

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

Flujo de ejecución

Instalación

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

pyproject.toml declara cero dependencias en tiempo de ejecución (solo biblioteca estándar). No se necesita ninguna biblioteca vectorial ni servicio externo.

Tres modos de uso

1. Línea de comandos (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. Servidor MCP (conectable a cualquier cliente de IA) ⭐ Recomendado

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

JSON-RPC 2.0 sobre stdio, que expone 8 herramientas (correspondientes al embudo de recuperación de tres niveles L1→L2→L3 + escritura/asociación/reconstrucción/ingesta):

工具	作用
`memory_write`	Escritura estructurada pasiva de un paquete de eventos (sobrescribe si el id existe)
`memory_query`	Recuperación determinista a nivel de paquete L1, devuelve candidatos Top-K (IDs acertados)
`memory_query_anchors`	Recuperación por anclas a nivel de capítulo L2, localiza con precisión una ronda/sección según el título `##` (devuelve un localizador)
`memory_resolve`	Punto de entrada unificado de desambiguación de recuperación: si hay múltiples entidades, pide aclaración; si no, devuelve Top-K; admite múltiples saltos + compuerta de abstención
`memory_read_section`	Obtención del cuerpo L3: según (id, heading), lee solo ese segmento `##`, sin redundancia
`memory_link`	Asocia bidireccionalmente dos paquetes de eventos
`memory_rebuild`	Reconstruye el índice por completo desde los `.md` (el `.md` es la fuente autoritativa; no se pierden datos)
`memory_ingest`	Ingesta activa: el usuario pega un texto y la IA ejecuta el pipeline completo (ver más abajo)

Cualquier cliente MCP, como Claude Desktop / Codex / Cline / WorkBuddy, solo necesita añadir un bloque de configuración:

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

Despliegue plug-and-play en WorkBuddy: el repositorio incluye un script de despliegue con un clic que copia el lanzador al directorio de configuración de WorkBuddy, fusiona y escribe ~/.workbuddy/mcp.json (solo toca el conector aimh, conserva el resto, detecta automáticamente la versión de python y no fija rutas), y registra el puntero ~/.hma_home:

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

Tras el despliegue, en la página de administración de conectores de WorkBuddy, haz clic en «Confiar» para activar el conector aimh; en la nueva ventana aparecerán las herramientas mcp__aimh__*.

⚠️ Tras modificar server.py, hay que deshabilitar→habilitar / volver a confiar en el conector para que el proceso residente cargue el nuevo código.

3. Como biblioteca (`import` de Python)

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)

Escritura e ingesta

Ingesta activa (memory_ingest) — el usuario pega un texto y la IA ejecuta el pipeline completo: lee los resúmenes de los paquetes existentes para descubrir asociaciones → divide en paquetes de eventos según la cohesión de CEMA + compuerta de volumen → genera metadatos para cada paquete → escribe en la fuente autoritativa .md + hace upsert del índice → establece asociaciones bidireccionales con paquetes existentes/nuevos. Si no hay API LLM configurada, degenera a una heurística de paquete único; la herramienta siempre está disponible.

# 有 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

Ruta de costo cero (el agente como capa de comprensión): cuando no hay clave configurada, deja que el agente de la sesión actual actúe como capa de comprensión (cargando la habilidad aimh-ingest) y que el motor determinista persista los datos — es isomórfica y sustituible por la ruta de LLM de pago. Cuando el tipo de texto no está claro, carga primero la habilidad de metaruta aimh-intake para decidir la clasificación y luego carga en cadena la habilidad correspondiente (oc-dossier / aimh-ingest / aimh-project / memory-import) para persistir; no escribe ningún archivo en memory/.

Ruta de pago/local: al configurar HMA_LLM (con su clave/endpoint correspondiente), se cambia automáticamente al LLM real de llm_adapter, sin necesidad de modificar código; si falla la llamada al LLM, se vuelve automáticamente a la heurística.

Línea temporal: paquete de registro diario (daylog)

El almacén de memoria principal se organiza por tema, no por línea temporal; daylog añade una línea temporal ortogonal sin romper el principio temático:

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

El tiempo es una clave de filtro, no un peso (la localización = comparación determinista de la fecha incrustada en el id; no se aplica ponderación por novedad). Las expresiones de tiempo ambiguas («anteayer / miércoles pasado») las resuelve el agente a fechas ISO antes de invocar el comando.

Archivado por compresión de contexto (ritmo circadiano · el agente como capa de comprensión)

Cuando la ventana de contexto está a punto de llenarse, el contenido sobrante que ya se ha discutido, aún no se ha persistido, pero podría necesitarse más adelante, se procesa con el agente determinando el destino + generando un resumen condensado, y se entrega de forma determinista a 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 "<一句话>"]

Regla de hierro: la compresión = resumen en frío aditivo; el texto original autoritativo no se toca ni una palabra. Solo cuando la nueva información entra en conflicto real con un evento autoritativo se sobrescribe y se añade un rastro auditable.

Migración de memorias externas

Los scripts migrate_wb_memory / migrate_claude_memory / migrate_gemini_memory / migrate_codex_memory en scripts/core/ migran la memoria a largo plazo nativa de cada cliente de IA a AIMH, instalando el índice frontal CEMA recuperable:

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 其他

La lista completa de scripts de migración y su filosofía se encuentran en 技术参考.md §8.

Búsqueda avanzada (scope / abstención / subconsultas / enumeración)

Varios mecanismos de mejora en escritura y lectura, ver detalles en 技术参考.md §7:

Enfoque scope: al pasar una ruta de directorio, solo se recupera ese subárbol, bloqueando la interferencia entre subárboles (29 paquetes → 11 paquetes); solo acota el alcance, no sustituye a la abstención.
Capa de abstención allow_abstain: las consultas con cobertura insuficiente o fuera de dominio devuelven explícitamente una abstención para evitar inventar (implementado en V1.0, activado por defecto).
Subconsultas sub_queries: la IA entrega una lista de subpreguntas de una vez; el motor hace un fan-out determinista y combina, sin idas y vueltas individuales.
Enumeración enumerate: lista todos los paquetes dentro del subárbol de scope (no es un ordenamiento Top-K).
Multisalto multihop: expande el clúster mediante BFS a lo largo de las aristas linked curadas en la escritura, cubriendo los puntos ciegos de relaciones/estructura (opt-in).

Todas las llamadas MCP de recuperación están sujetas al contrato QueryEnvelope (q/keywords/mode son obligatorios; si faltan, se rechazan con ENVELOPE_VIOLATION).

Estado actual

Estado del proyecto (2026-08-20): debido al agotamiento de los recursos de LLM (cuota de modelos gratuitos), este proyecto se ha cerrado formalmente y la fase de desarrollo ha terminado. El código, la documentación y los datos de referencia permanecen en su estado actual; los asuntos pendientes (como la ejecución completa de LoCoMo) pueden reanudarse en cualquier momento cuando haya recursos disponibles.

Posicionamiento: implementación de referencia sin dependencias + campo de pruebas de filosofía personal: se ha realizado una validación de ingeniería sin dependencias de diseños como la memoria basada en eventos, la separación frontal/fondo, el no olvido y la anti-adivinación vectorial, y se han integrado los cuatro elementos de recuperación, el pipeline de anclaje de tres etapas F+C+A+READ y las evaluaciones comparativas LoCoMo / MemoryStress.

Filosofía cumplida: memoria basada en eventos · separación estricta frontal/fondo · no olvido y retención total · recuperación determinista anti-adivinación vectorial · el tag como Mod: montaje/desmontaje a nivel de paquete · integración offline entre ventanas (ritmo circadiano).

Estado de ingeniería:

Cero dependencias de terceros en tiempo de ejecución (solo biblioteca estándar de Python)
El servidor MCP expone 8 herramientas (write / query / query_anchors / resolve / read_section / link / rebuild / ingest)
Los cuatro elementos de recuperación (person / event_date / location / topic) son ya campos de primera clase, con ponderación suave en la lectura
La recuperación a nivel de anclas se ha actualizado al esquema de tres etapas F+C+A+READ (el motor de producción ya está cerrado)
La capa de abstención V1.0 está implementada (cuatro compuertas + rechazo duro corpus_missing_entity, allow_abstain activado por defecto)
El contrato QueryEnvelope está implementado (el límite de MCP exige q/keywords/mode; fan-out de subconsultas sub_queries, enumeración list_all_in_scope)
Habilidades como cliente plug-and-play + habilidad residente de activación proactiva (aimh-always)

Evaluaciones comparativas (bucle de datos reales ya operativo):

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

Los criterios completos (incluidas las líneas rojas: OMEGA 38.3% no es comparable, TrueMemory 93% como objetivo de alineación) se encuentran en 技术参考.md §9.

Brechas conocidas:

La integración y reinicio en vivo de documentos activos dentro de la ventana (integrar fragmentos en el cuerpo existente mientras se conversa) no puede implementarse por completo en la arquitectura Transformer actual; queda para arquitecturas no TF (SSM/Mamba de estado persistente, o AGI real)
El conector MCP debe activarse haciendo clic en «Confiar» en el cliente
Las llamadas directas a la API del motor omiten la restricción QueryEnvelope del límite de MCP (aislamiento esperado; los scripts de prueba que usan la API no se ven afectados)
Compensación arquitectónica (el límite de capacidad está en la capa de IA): CEMA concentra la comprensión (reducción / decidir mode / extraer keywords / dividir sub_queries / curar linked) en la capa de IA, y el motor solo ejecuta de forma determinista. El beneficio es un motor mínimo, depurable y que mejora gratis con la IA; el coste es que el límite de calidad de AIMH = el límite de inteligencia de la IA emparejada — si la IA es débil, degenera en «un bonito archivador que a veces se usa mal». Tres amortiguadores (validación estricta del sobre / curación amortizada en escritura / compuerta de abstención como red de seguridad) convierten «la IA puede ser torpe» en «controlable y corregible», pero no eliminan ese límite. Ver «Enfoques matemáticos y filosófico-lingüísticos para la desambiguación en recuperación», §11.5.

Licencia

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
246

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 2 days ago (2026-09-04 10:48 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记忆中枢（AI-MemoryHub）

Introducción al proyecto

Características principales

Estructura del proyecto

Flujo de ejecución

Instalación

Tres modos de uso

1. Línea de comandos (manual / scripts)

2. Servidor MCP (conectable a cualquier cliente de IA) ⭐ Recomendado

3. Como biblioteca (import de Python)

Escritura e ingesta

Línea temporal: paquete de registro diario (daylog)

Archivado por compresión de contexto (ritmo circadiano · el agente como capa de comprensión)

Migración de memorias externas

Búsqueda avanzada (scope / abstención / subconsultas / enumeración)

Estado actual

Licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

3. Como biblioteca (`import` de Python)