Triggers an offline consolidation pass: merges events by topic into judgments, detects contradictions, and prunes trivia decayed below threshold, returning operation counts.
立刻做一次梦（离线巩固）：按主题把事件合并成判断、检出矛盾、淘汰衰减到阈值的杂事。返回本次的操作计数。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 behavioral burden. It usefully discloses the internal transformations (merge events, detect contradictions, prune decayed items) and mentions returning operation counts, but it does not address reversibility, destructive impact of the pruning step, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single tight sentence with a colon-delimited list of operations, and the action is front-loaded. It is appropriately sized for a no-parameter tool, with no wasted clauses.
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 consolidation tool with no annotations and no output schema, the description covers the main operations and the return value at a high level. However, it leaves out safety context around the pruning behavior and provides no guidance on when this complex operation should be triggered, leaving a meaningful gap.
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?
The tool takes zero parameters, so there is no parameter semantics to document; the baseline is 4. The description's note about returning operation counts is supplementary but not required for parameter understanding.
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?
The description names a specific operation ('立刻做一次梦') and then concretely defines what that means: merging events into judgments by topic, detecting contradictions, and eliminating decayed trivia. This is far more specific than a restatement of the tool name, though it does not explicitly contrast itself with siblings such as pm_compact.
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 says to do a dream '立刻' and labels it '离线巩固', but it never states when an agent should invoke this versus alternatives like pm_compact or pm_observe. There are no conditions, exclusions, or prerequisites given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.