Compresses a full core memory layer into fewer consolidated judgments after explicit user consent, moving older entries out of residency while keeping them traceable.
半衰期压缩：核心区太满、快要挤掉重要的东西时，把大部分印象交给梦做二次压缩，合并成更少的几条判断。必须先跟用户讲清楚（会丢掉一些细节）并得到同意，confirm=true 才执行。旧条目不删除，只是退出常驻，仍可追溯。
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | 用户是否已经明确同意压缩 |
Changes observed during successful MCP inspections.
v0.4.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that detail is lost, that user consent is required, that execution is gated on confirm=true, and critically that old entries are not deleted but merely lose residency and remain traceable. It omits any indication of what the call returns or what happens on confirm=false.
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?
A single dense paragraph that is front-loaded with the trigger, then the consent requirement, then the retention behavior. Efficient overall, though the 'hand impressions to dream' metaphor adds slight interpretive load for an agent.
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?
For a one-parameter, annotation-free, no-output-schema tool, the description covers trigger, mandatory human-in-the-loop precondition, data-loss consequences, and non-destructive retention. An agent has everything needed to decide and call correctly.
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 100% for the single confirm boolean, so the schema already defines it. The description adds real meaning beyond that: confirm=true is only legitimate after explicitly warning the user about detail loss and receiving agreement, which is stronger than the schema's 'whether the user has explicitly agreed'.
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?
It names a concrete operation (half-life compaction of the memory core into fewer merged judgments) and the condition that triggers it (core is full and about to evict important items). It does not explicitly contrast itself with the sibling pm_dream, which it mentions as the downstream compression agent, leaving mild ambiguity about which tool performs what.
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?
It gives a clear trigger condition (core too full) and a mandatory precondition (explain the detail loss to the user and obtain consent before calling). No explicit when-not-to-use case or named sibling alternative is given, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.