Evidence-chain personal memory for AI agents — verbatim-first, auditable, anti-fabrication. Ships as a skill + local stdio MCP server.
This MCP server implements 13 tools for personal memory management with structured schemas visible in code. However, significant gaps in parameter descriptions, inconsistent naming conventions, and limited error handling reduce overall quality. Tool names follow inconsistent patterns (some verb_noun like 'personal_add_record', others noun-heavy like 'personal_preflight_turn'). Many parameters lack descriptions entirely or have only Chinese documentation. Schemas are present but parameter descriptions in inputSchema objects are sparse, most lack the actionable constraint information (format, range, validation rules) needed for LLM reasoning. Error handling is minimal; tools appear to validate but provide no guidance for LLM recovery. The server demonstrates domain sophistication (capture IDs, finalization closures, audit trails) but tool definitions are not optimized for agent consumption.
记录一次依赖个人记忆的回答的效果:用了哪些记忆、用户反应说明 helpful/missed/corrected。不需要用户正式打分。
登记有上下文的待回访问题;到期后由个人理解 Skill 主动检查。
登记候选因果解释;默认 candidate,不得冒充事实。
创建派生记录。若来源是当前用户补充,必须先有 verbatim capture,并把 verbatim_refs 写入记录。活动足迹类微型记录传 tier=light(salience 0-1),完整档记录不传或传 full;记录层 tier 仅表示记录形态,不再表示调用档位。
绑定已判定为个人材料的 turn receipt,原样保存完整用户消息。没有 preflight 或 preflight 判为非个人时拒绝写入;捕获后仍必须派生并 finalize。
读取 v2 全局勘察。常规交互读取必须先完成当前轮次 turn preflight capture 并提供 capture_id;足迹/攻略类消息被 capture 闸门拦下时,可用 maintenance=true 做只读降级读取(有 trace 审计,不写档案),随后按足迹纪律用 tier=full 重声明补 capture。
13 tools lack output schema documentation. Tools return results but LLMs cannot infer response structure, forcing generic text parsing and context waste.
Parameter descriptions are sparse or missing. 'personal_add_record' has 16 parameters, only 2-3 with meaningful descriptions ('domain', 'phase', 'aliases', 'date_basis' are bare strings; 'kind' enum values not listed in description).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
读取 capture→records 闭环状态,检查 pending、孤立捕获和链接漂移。
关闭当前原话捕获的派生闭环。derived 必须已有至少一条双向链接记录;无需派生时必须写具体原因(零新增收场须写明定向查重命中的既有记录)。回答前必须调用。
当前用户消息的强制内容预检。它持久化 turn receipt;个人经历、感受、关系、偏好、决定即使请求形式是润色/总结/看图,也会要求 capture。两档调用(2.4.0 起):内容含个人材料或活动足迹类轮次(如'正在玩某游戏')走完整档(tier=full/auto),足迹轮次受足迹纪律(写入前定向查重、恰好一条微型记录、零新增可 no-derivation 收场);纯技术/吃喝/购物等明显无关或零增值轮次不调用本工具(跳过档)。tier=light 已废弃,传入按 full 处理。
关闭一条回访(answered 回访完成 / declined 用户不再跟进 / resolved 回路以其他方式关闭,含方案被取代或过时);note 必填且须具体。可选 capture_id 把本轮用户回答的原话 capture 绑到回访上(须已存在于 ledger)。
按 v2 事件、实体和情境卡读取 probe/deep。必须先完成当前轮次 turn preflight capture,并提供 capture_id;否则拒绝读取。
回答或声称档案已更新前的硬闸门:turn receipt + capture 闭环 + 结构 + v2 完整性。个人 turn 必须传 turn_id,缺 capture 或 finalize 会失败。
校验 v2 结构,并明确区分失败、警告和干净。默认强制要求所有 capture 已完成派生闭环。只读。
Inconsistent naming conventions. Tools mix verb-first (add_record, add_followup) with noun-first (preflight_turn, catalog) patterns. 'personal_retrieve' vs 'personal_catalog' are synonymous, both read memory, but naming does not distinguish their use.
Mutual exclusivity and parameter dependencies are undocumented. 'personal_catalog' vs 'personal_retrieve' both accept capture_id and query, when to use which is not explained. 'personal_add_record' parameters 'source_refs' and 'verbatim_refs' have unclear relationship.
No error handling guidance. Tools describe prerequisites (e.g. 'preflight required') but do not tell LLMs what to do if capture_id is missing or invalid. No recovery actions, no actionable error messages documented.
Chinese documentation is not LLM-optimized for English agents. Parameter descriptions and tool text are predominantly in Chinese (e.g. 'tier=full/auto', '足迹轮次', '恰好一条微型记录'). English-speaking LLMs will struggle to parse intent and constraints.
Parameter format/validation rules are missing. 'date_basis', 'date_precision', 'due_rule' are free-form strings with no enum, pattern, or example. 'captured_at' and 'due_at' lack ISO 8601 or format specification.
'personal_add_record' parameter 'kind' enum values are hardcoded in Python (VALID_KINDS = {'fact', 'state', ...}) but not listed in inputSchema description. LLM must infer from the enum, but if it hallucinates a value, no guidance is provided.
Descriptions exceed optimal length for LLM processing. 'personal_preflight_turn' description is ~300 chars and uses complex nested logic ('两档调用', 'tier=light 已废弃'). Under rubric baseline (194 chars average), this forces token waste and may cause LLMs to misread the intent.