Does 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description does disclose important context: the source is a normally-closed core zone and this is its sole exit, and the output is narrative rather than itemized. It does not say whether calling it mutates or consumes the underlying memory, nor any permission or rate constraints, so the full burden isn't met.

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?

Three short sentences, each carrying distinct information — purpose, access exclusivity, usage trigger, and output form — with the purpose front-loaded and no padding.

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 two-optional-parameter tool with no output schema, the description covers purpose, gating, and output shape adequately. It omits whether the diary action affects or clears the stored core impressions, which would matter for a sensitive 'sole exit' operation.

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%, with both 'raw' and 'style' documented in-schema, so the baseline applies. The description's '输出是叙事，不是条目清单' reinforces the default narrative output but adds no per-parameter detail 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?

A concrete verb and resource are stated: writing core impressions as a diary handed to the user. The phrase '核心区平时不对用户开放，这是唯一的出口' also implicitly differentiates it from sibling retrieval tools like pm_recall, but no sibling is named explicitly.

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 trigger conditions — only when the user explicitly requests it, or at farewell/migration moments. The 'only' phrasing also rules out routine use, though no alternative tool is named for other cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden itself and does disclose the key trait: this persists to durable storage ('落盘') and is manual-only versus auto-observation. However it says nothing about permissions, reversibility, deduplication, or what happens on repeated calls, leaving real behavioral gaps.

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?

Two tight sentences, front-loaded with the core action followed by the usage condition. Zero waste.

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 simple 2-parameter, no-output-schema tool, the description covers the essential why and when. It is nearly complete; only the durability/return behavior on the persistence side is unaddressed, which is minor given the rich schema.

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% and the enum's 'auto-classify if omitted' behavior is described in the schema, so the burden is already met. The description adds no parameter-level meaning beyond noting that text should preserve the original wording, which is minimal value over 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?

Clear verb+resource: 'explicitly record one thing.' It distinguishes the manual path from automatic daily observation, letting an agent grasp the intent. It does not differentiate from siblings like pm_diary or pm_pin that also persist content, so it stops short of a 5.

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?

Explicitly states the when-not (daily conversation is auto-observed) and the when (only when you judge a sentence important enough to persist). This is real routing guidance, though it names no specific sibling alternative for comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden. It implies the preview mode ('预演') is non-mutating and describes conceptually what is returned (facets, weights, activated facets, cross-state), but never explicitly states that it is read-only, that the simulation persists nothing, or whether 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded with the primary view function followed by the optional simulation mode. No filler.

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 single optional-parameter tool with no output schema and no annotations, the description covers both modes and the effect of the parameter adequately. It could state the read-only nature of the preview more explicitly, but nothing essential is missing.

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% and the schema already marks the param as optional, but the description adds real value by explaining what supplying the text actually does: previews which facets it activates and whether a cross-state is entered.

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?

States a specific verb ('查看' / view) and resource ('人设面与权重' / persona facets and weights), plus a second mode (previewing activation of facets). It is clearly distinguishable from generic siblings like pm_status or pm_trace, though it does not explicitly name any sibling it differs from.

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 indicates a usage scenario for the optional parameter — supply a hypothetical sentence to preview activation and cross-state — but gives no guidance on when to use this tool versus alternatives like pm_status, and no exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the disclosure burden and does well: pinned entries are unaffected by half-life decay, are excluded from resident rotation, and are always present in injection. That is real behavioral context an agent could not infer. It omits idempotency and what happens if text matches nothing, but the core trait is covered.

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?

Two sentences, both dense with information: the first states the action and its toggle, the second states the behavioral effect and the use case. Nothing is repeated from the schema, and the highest-value content is front-loaded.

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 three-parameter tool with no output schema and no annotations, the description covers purpose, effect, and usage well. The only meaningful gap is the mutual-exclusivity or requiredness of id versus text when pinning, which the schema marks as all-optional and the description does not resolve.

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 description coverage is 100%, so id, text, and unpin are already documented in the schema, and the description adds no syntax or matching details beyond it. A baseline 3 is appropriate here. One thing left unaddressed is that no parameter is required, so the description could clarify that id or text must be supplied.

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 states a concrete verb+resource: pinning (or unpinning) a memory, and immediately spells out the effect of pinning. It clearly distinguishes the operation from sibling memory tools like pm_recall or pm_observe. It stops short of naming any sibling explicitly, but the distinct action makes mis-selection unlikely.

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 concrete when-to-use criteria: events only mentioned once but with major consequences, with examples such as marriage/funeral, promises, health, money, and legal matters. That implicitly excludes routine or repeated memories, though it never states a when-not rule or names an alternative tool for ordinary recall.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden. It discloses the layer boundary and what is intentionally not exposed, which is useful behavioral context. However, it says nothing about the shape of results, whether matches are ranked or include timestamps/snippets, or how the 'k' cap interacts with ranking — gaps that matter for a retrieval tool with no output schema.

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?

Two short sentences, front-loaded with the core retrieval action and layer scope, followed by the usage cue. No filler. Slightly terse for the behavioral information an unannotated tool should convey, but structurally sound.

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 low-complexity, 2-parameter retrieval tool this covers purpose, layer scope, and usage trigger, which is largely adequate. With no annotations and no output schema, though, the description is the only place an agent could learn what a result looks like (event text, relevance, timestamps) and it omits that.

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 description coverage is 100%: 'query' is documented as natural language and 'k' as max results with a default of 6. The description adds no parameter-level detail beyond this, so the baseline 3 is appropriate.

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 verb and resource: 'semantic search of old events at the event layer' (按语义检索旧事), with a concrete scope (things the user said, recorded key events). It also distinguishes its layer from the 'core impression layer', making it identifiable relative to the memory-siblings. It stops short of naming a specific sibling tool, so a 4 rather than 5.

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?

'用于需要具体细节时' gives a clear usage condition, and '核心印象层不通过这个工具暴露' implicitly routes impression-level queries to another tool. That is a genuine boundary for tool selection. It does not explicitly name the alternative sibling or give when-not-events scenarios, so not a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full behavioral burden. It usefully discloses that output is numeric-only and excludes core-impression content, which tells the agent what it will and won't receive. However, it does not state that the operation is read-only, side-effect-free, or whether any state is mutated or logged.

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 compact sentence that front-loads the resource and then enumerates the returned metrics, closing with the key output constraint. 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?

For a simple no-param, no-output-schema read tool this is close to adequate, and it does describe what the numbers represent. But system-specific jargon ('可塑性记忆', '三层', '杂讯') is never grounded, so an agent unfamiliar with the memory model cannot fully interpret the response.

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 nothing for the description to disambiguate; the baseline for a 0-param tool is 4. The description adds no misleading parameter hints, and the schema is trivially complete.

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 states the resource (memory health and capacity) and enumerates the specific metrics returned: per-layer counts, blocked noise, and dream count. The clause '只返回数字，不返回核心印象的内容' distinguishes it from content-returning siblings like pm_recall and pm_diary, though it never names a sibling explicitly and the term '三层' is left undefined.

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?

Usage is only implied: an agent can infer this is a diagnostic/health-check tool, but there is no explicit statement of when to call it versus pm_trace, pm_compact, or the other pm_* siblings. No prerequisites, exclusions, or alternatives are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries the full burden. It does disclose the shape of the result (a lineage chain of source quotes or prior impressions) and implies a read-only lookup, but says nothing about behavior when no match is found, whether results are truncated, or any permission/cost constraints.

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?

Two short sentences, front-loaded with what is traced and followed by when to use it. No filler or restatement of the tool name.

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?

With no output schema, the description usefully explains what the trace returns (source sentences or upstream impressions), which is the key unknown for an agent. Only failure/empty-result handling is left unstated.

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% and both properties are documented in the schema, including that `text` fuzzy-matches the nearest impression. The description adds no parameter-level detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource: trace the provenance of an impression — which source sentences compressed into it, or which older impressions it was recompressed from. That is clearly distinct from recall/observe/dream siblings, though it never names an alternative tool explicitly.

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?

Gives two concrete situations: self-checking 'why do I remember this' and verifying whether a dream fabricated content. That is real usage context, but there is no explicit when-not guidance nor a named sibling to use instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.