Skip to main content
Glama
deenesjakoruzh
Traceless-zero

AI-MemoryHub MCP Server

by Traceless-zero
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

AI记忆中枢（AI-MemoryHub）

ゼロ依存・モデル非依存の AI Agent 長期記憶システム：Markdown 本文を権威ソースとし、薄い SQLite インデックスを併用。ベクトル RAG の代わりに決定的検索を用い、「理解」は外側の AI に任せ、エンジンは検索と拒答のみを行う。CEMA（Cognitive Event-driven Memory Architecture、認知-イベント駆動メモリ・アーキテクチャ）の概念に基づいて構築。

個人プロジェクト、vibe coding による独立開発：アーキテクチャと要件設計は本人が実施、コードは AI 支援で実装。

プロジェクト紹介

AI记忆中枢（AI-MemoryHub）は「長期記憶」を2つの層に分ける：

  • バックエンド本文（権威ソース）：各記憶は Markdown ファイルで、YAML front-matter を持ち、すべての意味内容を格納する。検索には一切参加せず、必要に応じて ID で取得する（すなわち「忘れられたコールドストレージ」）。

  • フロントエンド・インデックス（薄い SQLite テーブル）：id / title / summary / aliases / tags / linked / anchors / created / updated + features（サブエンティティ変種の正規化）+ 四要素 person / event_date / location / topic を格納し、すべての .md の front-matter から全量再構築可能。検索はここでのみ発生し、一意の ID にヒットしてから本文を取得する。

この設計は CEMA（フロントエンド薄インデックス + バックエンド本文、フロントとバックは厳密に 1:1、インデックスは本文から全量再構築可能）と呼ばれる——ステートレス検索、安価なストレージで忘却しない。さらに従来のメモリシステムの運用負荷（ベクトル基盤なし、夜間 LLM パイプラインなし、Agent 直接書き込み）を取り除く。

設計はサードパーティ依存ゼロ（Python 標準ライブラリのみ）で、任意の AI 大モデル API に接続可能。理解層は AI クライアント / Agent / 有料 LLM のいずれかが担う。

命名規約：本ドキュメントにおける「AI记忆中枢（AI-MemoryHub）」は本プロジェクトの正式名称；「HMA」はその基盤アーキテクチャ Hybrid Memory Architecture（ハイブリッド・メモリ・アーキテクチャ）を指す。コード内の hma パッケージ名、MCP server 名、HMA_LLM 環境変数などの識別子は変更しない。

コア機能

  • イベント化メモリ：イベントが唯一のキャリアであり、短期/長期、エピソード/セマンティックで分類しない

  • フロント/バック厳密分離：薄い SQLite インデックス + Markdown 本文、インデックスは front-matter から全量再構築可能

  • 忘却しない・全保持：重要度スコアなし、忘却曲線なし、判断は検索時に委ねる

  • ベクトル推測を排した決定的リコール：ゼロベクトル/ゼロ埋め込み；F-stage サブエンティティ変種正規化 + C+A 章レベル曖昧性解消 + READ 本文取得 + ループクエリ

  • Tag 即 Mod（タグ＝モッド）のパッケージ単位着脱：memory 配下のフォルダをコピー/削除 = ひとつの認知モジュールの着脱

  • モデル非依存：汎用 LLM アダプタにより、今日は Claude、明日は GPT、明後日はローカル Ollama でもコード変更不要

  • クエリ契約の強制：MCP 境界で毎回の検索に QueryEnvelope 検証を実施（keywords/mode 欠落は直接拒否）

アーキテクチャ哲学、検索分類、解決アプローチは memory/项目/AIMH-design-journal/ 配下の設計ドキュメントを参照；MCP ツール一覧、エンジン API、検索メカニズム、アダプタ、設計不変条件、ベンチマーク基準 はすべて 技術参考.md に集約されている。本ドキュメントは「何か / どう動かすか」のみを説明する。

Related MCP server: mcp-ltm

プロジェクト構造

memory/ は AI记忆中枢（AI-MemoryHub）の単一の権威ストレージ。各メモリパッケージ = 1 つの .md イベントファイル（## 見出しツリー + YAML front-matter）+ パッケージ内 index.db（薄いインデックスキャッシュ。.md の front-matter から全量再構築可能で、削除してもデータは失われない）。

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

実行フロー

インストール

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

pyproject.toml はランタイム依存ゼロ（標準ライブラリのみ）を宣言。ベクトルライブラリや外部サービスは一切不要。

3つの使い方

1. コマンドライン（手動 / スクリプト）

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（任意の AI クライアントに接続）⭐ 推奨

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

stdio 上の JSON-RPC 2.0 で、8 つのツールを公開（3段階検索ファネル L1→L2→L3 + 書き込み/関連付け/再構築/取り込みに対応）：

ツール

役割

memory_write

イベントパッケージを受動的に構造化して書き込む（id が存在すれば上書き）

memory_query

L1 パッケージ単位の決定的検索、Top-K 候補を返す（ID ヒット）

memory_query_anchors

L2 章レベルアンカー検索、## 見出しで特定のラウンド/セクションを正確に特定（locator を返す）

memory_resolve

リコール曖昧性解消の統一エントリ：複数エンティティ時は明確化、それ以外は Top-K を返す；マルチホップ + 拒答ゲート対応

memory_read_section

L3 本文取得：(id, heading) で該当 ## セクションのみ読み取り、冗長ゼロ

memory_link

2つのイベントパッケージを双方向に関連付ける

memory_rebuild

.md からインデックスを全量再構築（.md が権威ソース、データは失われない）

memory_ingest

能動的取り込み：ユーザーがテキストを貼り付け、AI が完全パイプラインを実行（下記参照）

Claude Desktop / Codex / Cline / WorkBuddy など任意の MCP クライアントに、設定を1つ追加するだけ：

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

WorkBuddy プラグアンドプレイ導入：リポジトリにワンクリック導入スクリプトが同梱されており、ランチャーを WorkBuddy 設定ディレクトリにコピーし、~/.workbuddy/mcp.json をマージして書き出す（aimh コネクタのみ変更、他は保持、python バージョンを自動検出、パスをハードコードしない）。さらに ~/.hma_home ポインタを登録する：

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

導入後、WorkBuddy のコネクタ管理ページで「信頼」をクリックして aimh コネクタを有効化すると、新しいウィンドウに mcp__aimh__* ツールが表示される。

⚠️ server.py を変更した場合は、コネクタで無効→有効 / 再 Trust を行う必要がある。常駐プロセスが新しいコードを読み込むため。

3. ライブラリとして（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)

書き込みと取り込み

能動的取り込み（memory_ingest）——ユーザーがテキストを貼り付けると、AI が完全パイプラインを実行：既存パッケージの要約を読み取って関連性を発見 → CEMA の凝集性 + ボリュームゲートに従ってイベントパッケージに分割 → 各パッケージのメタデータを生成 → .md 権威ソースに書き込み + インデックスを upsert → 既存/新規パッケージと双方向に関連付け。LLM API が未設定の場合は単一パッケージのヒューリスティックに退化するが、ツールは常に利用可能。

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

ゼロコスト経路（Agent が理解層）：key 未設定時は、現在のセッションの Agent が理解層を担当し（aimh-ingest スキルをロード）、決定的エンジンでデータベースに書き込む——有料 LLM 経路と同型で置換可能。テキストタイプが不明な場合は、まず aimh-intake メタルーティングスキルをロードして分類判断を行い、その後 oc-dossier / aimh-ingest / aimh-project / memory-import の対応スキルをチェーンロードして書き込む。自分では memory/ ファイルを一切書かない。

有料/ローカル経路：HMA_LLM を設定（対応する key/エンドポイントも設定）すると、自動的に llm_adapter の実 LLM 経路に切り替わり、コード変更は不要。LLM 呼び出しが失敗した場合は自動的にヒューリスティックにフォールバックする。

タイムライン：単日記録パッケージ（daylog）

メインのメモリベースはテーマ単位で編成され、タイムラインではない；daylog が直交するタイムラインを補完し、テーマ原則を壊さない：

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

時間はフィルタキーであり重みではない（位置特定 = id に埋め込まれた日付の決定的比較で、新しさによる重み付けはしない）。曖昧な時間表現（「おととい/先週の水曜日」）は Agent が ISO 日付に解析してからコマンドを呼び出す。

コンテキスト圧縮アーカイブ（昼夜リズム・Agent が理解層）

コンテキストウィンドウが満杯になりそうなとき、議論済みでまだデータベースに落としていないが、後で必要になるかもしれない溢れコンテンツを、Agent が落とし先を判断 + 凝縮要約を生成し、決定的に 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 "<一句话>"]

鉄則：圧縮 = 加算的なコールド要約であり、権威ある原文は一字も変えない。新情報が権威イベントと本当に衝突する場合のみ上書きし、監査可能な trail を追記する。

外部メモリの移行

scripts/core/ 配下の migrate_wb_memory / migrate_claude_memory / migrate_gemini_memory / migrate_codex_memory が、各 AI クライアントのネイティブ長期メモリを AIMH に移行し、検索可能な CEMA フロントエンドインデックスを装備する：

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

移行スクリプトの完全な一覧と哲学は 技術参考.md §八 を参照。

高度な検索（scope / 拒答 / 多問 / 列挙）

書き込み時と読み取り時のいくつかの強化メカニズムの詳細は 技術参考.md §七 を参照：

  • フォーカス scope：ディレクトリパスを渡すとそのサブツリーのみをリコールし、サブツリー間の干渉を遮断（29 パッケージ → 11 パッケージ）。範囲を絞るだけで、拒答の代わりはしない。

  • 拒答層 allow_abstain：カバレッジ不足/ドメイン外クエリは明示的に拒答を返し、捏造を回避（V1.0 で実装済み、デフォルトでオン）。

  • 多問 sub_queries：AI が一度にサブクエリリストを渡し、エンジンが決定的にファンアウトしてマージ。個別の往復はしない。

  • 列挙 enumerate：scope サブツリー内の全パッケージを列挙（Top-K ソートではない）。

  • マルチホップ multihop：書き込み時にキュレーションされた linked エッジに沿って BFS でクラスタを拡張し、関係/構造の盲点を補う（opt-in）。

すべての検索系 MCP 呼び出しは QueryEnvelope 契約に拘束される（q/keywords/mode 必須、欠落時は ENVELOPE_VIOLATION で拒否）。

現在のステータス

プロジェクトステータス（2026-08-20）：LLM リソース（無料モデルのクォータ）枯渇のため、本プロジェクトは正式にクローズし、開発段階は終了。コード、ドキュメント、ベンチマークデータは現在の状態のまま維持。保留中の事項（LoCoMo フルベンチマークなど）は、利用可能なリソースがあればいつでも再開可能。

位置付け：ゼロ依存のリファレンス実装 + 個人の哲学実験場——イベント化メモリ、フロント/バック分離、忘却しない、ベクトル推測排除などの設計をゼロ依存で工学的に検証し、リコール検索の四要素、F+C+A+READ 三段式アンカーパイプライン、LoCoMo / MemoryStress ベンチマーク評価を統合。

実現済みの哲学：イベント化メモリ・フロント/バック厳密分離・忘却せず全保持・ベクトル推測を排した決定的リコール・Tag 即 Mod（タグ＝モッド）パッケージ単位着脱・クロスウィンドウオフライン統合（昼夜リズム）。

エンジニアリングステータス：

  • サードパーティランタイム依存ゼロ（Python 標準ライブラリのみ）

  • MCP server が 8 ツールを公開（write / query / query_anchors / resolve / read_section / link / rebuild / ingest）

  • リコール検索の四要素（person / event_date / location / topic）が第一級フィールドになり、読み取り時にソフト重み付け

  • アンカーレベル検索は F+C+A+READ 三段式にアップグレード（本番エンジンでクローズドループ）

  • 拒答層 V1.0 実装済み（4つのゲート + corpus_missing_entity ハード拒否、allow_abstain デフォルトオン）

  • QueryEnvelope 契約実装済み（MCP 境界で q/keywords/mode を強制、多問ファンアウト sub_queries、列挙 list_all_in_scope）

  • スキルをプラグアンドプレイクライアントとして提供 + 常駐の能動的トリガースキル（aimh-always）

ベンチマーク評価（実データのクローズドループを検証済み）：

  • LoCoMo 1540問：hit@30 ≈ 99.6% / recall@30 ≈ 99.5% / hit@5 89.7–92%

  • MemoryStress 300問：baseline 77% / B_gold 89.7%

完全な基準（レッドライン：OMEGA 38.3% は併記不可、TrueMemory 93% をアライメント目標とする）は 技術参考.md §九 を参照。

既知のギャップ：

  • ウィンドウ内リアルタイム活文書統合リセット（会話しながら断片を既存本文に統合）は、現在の Transformer アーキテクチャでは完全版を実装できない。非 TF アーキテクチャ（永続状態 SSM/Mamba 系、または真の AGI）に委ねる

  • MCP コネクタはクライアント側で「信頼」をクリックして有効化する必要がある

  • エンジン API の直接呼び出しは MCP 境界の QueryEnvelope 制約をバイパスする（想定された分離であり、テストスクリプトが API 経由でも影響なし）

  • アーキテクチャトレードオフ（能力上限は AI 層にある）：CEMA は理解力（帰約/モード判定/keywords 抽出/sub_queries 分割/linked キュレーション）を AI 層に集中させ、エンジンは決定的実行のみを行う。利点はエンジンが極小でデバッグ可能、AI のアップグレードに伴って自動的に向上すること。代償は AIMH の品質上限 = ペアとなる AI の知能上限——AI が弱いと「たまに間違って使う綺麗なファイルキャビネット」に退化する。3つのバッファ（エンベロープハード検証/書き込み時キュレーションの償却/拒答ゲートのセーフティネット）が「AI が愚かかもしれない」を「制御可能で修正可能」に変えるが、その上限は消えない。詳細は『リコール曖昧性解消の数学と言語哲学的考察』§11.5 を参照。

License

MIT

Available Tools

7 tools
memory_ingestA

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

ParametersJSON Schema
NameRequiredDescriptionDefault
textYes待收录的原始文本
modelNo可选，覆盖默认模型名
scopeNo作用域标签（如 user_global / workspace_x），会加进每个新包的 tags
providerNo可选，覆盖默认 LLM 厂商：openai / anthropic
auto_linkNo是否自动建立关联，默认 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_queryA

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

ParametersJSON Schema
NameRequiredDescriptionDefault
qYes检索关键词
top_kNo返回条数，默认 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
NameRequiredDescriptionDefault
qYes检索关键词（剧情/事件/特征词）
top_kNo返回条数，默认 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
NameRequiredDescriptionDefault
idYes事件包 ID
headingYes小标题片段（##/### 标题的包含匹配，可用 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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault
idYes事件包唯一 ID（文件名）
bodyNoMarkdown 正文
tagsNo标签；trivial 表示琐碎内容（检索降权）
titleNo标题
linkedNo关联的其他事件包 ID
aliasesNo别名/同义词，用于检索命中
createdNo创建日期 YYYY-MM-DD（可选）
summaryNo一句话摘要
updatedNo更新日期 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.

  1. 7 tool updatesv0.1.0
    • 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

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • Mneme Memory MCP

    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.
    6
    2
    MIT

  • mcp-ltm

    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.
    1
    MIT

  • ai-dememory

    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.
    74
    Apache 2.0

  • Agentic Memory

    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.
    24
    Apache 2.0

Latest Blog Posts

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