Consolidate similar repeated experiences into a single key point and mark duplicates as merged, preventing memory pool bloat. Offers a suggestion first; execute with apply=true when confirmed.
记忆巩固（睡眠回放）：把高度相似的重复经历蒸馏成一条要点，并把源条目标记为已合并，避免记忆池被重复项撑爆。默认只给建议（apply=false），确认后传 apply=true 执行。
| Name | Required | Description | Default |
|---|---|---|---|
| apply | No | 是否真的执行（默认 false，只出建议） | |
| agent_id | No | default |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the dry-run default, the need to pass apply=true to execute, and the mutating effect of marking source entries as merged. It does not discuss reversibility or output shape, but the key safety behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose and then states the apply-mode behavior. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core behavior and execution modes are covered, which is good for a simple tool. However, there is no output schema and agent_id is left unexplained, so an agent gets no guidance on scoping or what the returned suggestions look like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50% because agent_id is undocumented, and the description does not help with it. For apply, the description mostly restates what the schema already says (default false, only suggestions), adding little semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the operation: distilling highly similar repeated experiences into one key point and marking source entries as merged. This clearly distinguishes it from memory retrieval/save siblings like pasm_recall and pasm_save.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use when there are highly similar repeated experiences, and it explains the safe default mode (apply=false) versus execution (apply=true). It does not explicitly name sibling alternatives or exclusion conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.