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

No annotations are provided, so the description carries the full burden. It discloses the selection mechanism (personality baseline + learned preferences) and the candidates fallback behavior, but doesn't disclose side effects, whether this mutates state, whether it records the choice, or what the return value looks like.

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, front-loaded with the core purpose and selection criteria. The conditional usage note is placed efficiently. No wasted words.

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 tool with no annotations and no output schema, the description is thin. It doesn't explain what the returned action looks like, whether the selection has side effects (e.g., storing feedback), or how it relates to sibling tools like pasm_feedback and pasm_persona. An agent would need to infer these details.

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 50%: candidates has a description, agent_id does not. The description adds meaning for candidates by explaining the fallback behavior when omitted, but doesn't clarify agent_id's role or default behavior beyond the schema's 'default' field.

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 specific verb ('选一个动作' = select an action) and resource (PASM action pool), and explains the selection basis ('人格基线 + 反馈学到的偏好'). It distinguishes itself from siblings by focusing on action selection, though it doesn't explicitly name a sibling alternative.

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 implies when to use it (when PASM needs to choose an action) and gives a conditional usage note ('不传 candidates 就用智能体自己的动作池'). However, it doesn't explicitly state when NOT to use it or name alternative tools like pasm_chat or pasm_focus.

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 are provided, so the description bears the full burden of behavioral disclosure. It reveals that the tool reads memory, renders a template reply, and writes the conversation back into memory, which is a meaningful side-effect disclosure. It does not detail return format or memory-mutation consequences, but the main non-obvious behavior—non-LLM template rendering—is clearly disclosed.

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 compact sentence that front-loads the core behavior, then adds the key caveat and alternative routing. There is no filler or redundant 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?

The description covers the full pipeline, the intended use cases, and the recommended sibling for natural-language output, which is enough for safe invocation with the required text parameter. The main gaps are the undocumented agent_id parameter and no information about what the rendered reply looks like, but these do not prevent correct basic usage.

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 only 50%, with agent_id entirely undocumented in both the schema and the description. The description adds no parameter-level guidance beyond the flow-level context; it never mentions agent_id or how it affects the cognitive loop. Since the description does not compensate for the missing schema coverage of agent_id, parameter semantics are weak.

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 behavior with a concrete pipeline: 检索记忆 → 渲染回复 → 写进记忆. It further differentiates this tool from the sibling by explicitly stating the reply is template-rendered, not LLM-generated, and points to pasm_context for natural language. This makes the tool's role in the sibling set unambiguous.

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 explicitly states when to use this tool ('用于快速验证或纯离线场景') and when to use an alternative ('要自然语言效果请用 pasm_context 配合你自己的模型'). This is clear, actionable guidance that an agent can act on without inference.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It explicitly states the operation is read-only and does not write memory, and it explains the intended downstream behavior of treating recalled content as 'things you actually remember'. This is meaningful transparency for a context-retrieval tool.

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 compact and well-structured: it front-loads the read-only nature and return payload, then provides a clear usage directive. Every sentence earns its place and there is no redundant prose.

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 tool with no output schema and no annotations, the description adequately covers the return contents and how to use them in a prompt. It could mention edge cases or output formatting, but the provided information is sufficient for correct invocation.

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 the baseline is 3. The description adds no new parameter-level detail beyond referencing the current topic; parameter semantics are already fully handled by the input 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?

The description uses a specific verb ('取', get) with a clear resource ('PASM 认知上下文') and states it is read-only and does not write memory. It also lists the return payload, which distinguishes it from memory-writing sibling tools like pasm_save and pasm_feedback.

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 explicitly says this is the preferred tool for integrating PASM into an LLM prompt and to call it first. It gives clear context for when to use it, but it does not mention when not to use it or name alternative sibling tools for exclusion.

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 provided, the description carries the full burden of behavioral disclosure. It clearly states that feedback shapes future action selection, and warns about the consequence of omitting 'action' (preferences concentrate on a single action). This is valuable transparency about the tool's side effects, though it doesn't mention persistence, scope (per-agent), or other potential effects.

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 compact sentences deliver the purpose, the kinds, and the critical usage warning. No fluff, no repetition of schema details already present. The most important guidance (must include action) is front-loaded in the second sentence, making it highly readable 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 feedback-recording tool with no output schema and a simple parameter set, the description is complete. It explains what the tool does, what kinds exist, what the critical parameter is and why, and the effect on future behavior. An agent has everything needed to invoke it correctly without additional context.

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 schema already describes 'action' as 'strongly recommended', and 'kind' has an enum. The description adds value beyond the schema by explaining why 'action' is critical (prevents preference concentration) and by listing the five kinds in prose. Given schema coverage is only 33%, the description compensates meaningfully for the undocumented 'agent_id' and reinforces the purpose of 'kind'.

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 states a clear verb (feedback) and resource (PASM behavior), and explains the effect (shapes subsequent action selection). It also enumerates the kinds (praise/scold/poke/hug/ignore), making the tool's purpose unmistakable. While it doesn't name a specific sibling, the unique role of collecting user feedback is unambiguous within the pasm_* suite.

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 explicitly instructs to always include the 'action' parameter to avoid preference concentration – this is usage guidance for parameters. It doesn't explicitly state when to use this tool versus alternatives, but the purpose (feedback) is so distinct from siblings like pasm_act or pasm_chat that the intended context is obvious. The lack of a when-not clause is a minor gap.

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 burden. It discloses the key side effect ('drives emotional state evolution'), but does not clarify persistence, reversibility, or whether the report is recorded beyond the state change, so the behavioral disclosure is only partial.

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?

One concise sentence with the core action, target state, and valence range. There is 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 state-update tool with three flat parameters and no output schema, the description plus input schema gives enough to invoke correctly. It could mention what the caller gets back, but this is not essential for a mutation.

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 67%; event and valence are documented in the schema. The description reinforces the valence range (-1 to +1) but adds little new parameter-level meaning, and agent_id remains undocumented in both schema and description.

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 uses a specific verb ('报告' / report) and a specific resource ('an event with emotional valence'), and explicitly states the intended effect (driving emotional-state evolution). This distinguishes it from siblings like pasm_save or pasm_feedback, which do not target valence-driven state evolution.

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 clear context: use when reporting an emotionally valenced event to update PASM's emotional state. It does not explicitly list exclusions or name alternatives, so it misses the top bar.

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 transparency burden and does a solid job: it discloses both read and write modes, that pushing a topic affects future retrieval weighting, and the 'avoid off-topic' purpose. It does not detail exact stack side effects such as overwrite versus accumulation, but the core behavioral traits are explicit.

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: purpose first, then the long-conversation usage context/effect, then the read-mode behavior. No filler or repetition.

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 description plus a well-annotated schema provide enough to invoke safely: when to call, read vs write mode, and what the call affects. Without annotations or an output schema, a little more detail about accumulated/updated focus state would make it fully complete, but the current definition is sufficient for typical calls.

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 80% and parameter descriptions already document n, topic, weight, and entities. The description adds complementary semantics by linking topic/weight/entities to the retrieval-weighting mechanism, which helps an agent understand why these parameters matter. agent_id remains undocumented in both schema and description, preventing a 5.

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 states a specific action: '查看或更新"现在在聊什么"' on a '焦点栈', and explains its role as topic weighting for retrieval to avoid off-topic drift. This is clear and distinct from generic siblings, though it never explicitly names a sibling to contrast against.

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?

Clearly gives usage context: in long conversations, push the current topic before subsequent retrieval so related content gets weighted. It also defines the read-only call path ('不传 topic 就是查看'). It does not name alternatives or explicit exclusions, 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.

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

无注释，描述需承担全部责任。它披露了salience对淘汰概率的影响（'salience 越高越不容易被淘汰'），这是有价值的行为信息。但未说明写入是否覆盖、权限要求或返回内容，行为披露不全面。

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?

两句话简洁明了，第一句定义核心功能，第二句补充内容类型和salience指导，无冗余，结构紧凑。

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?

对于写入工具，描述提供了内容建议和salience行为，schema覆盖主要参数。虽无输出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覆盖率为83%，大多数参数已有描述。描述额外补充了salience的行为含义（影响淘汰）以及内容类型建议，对参数语义有增值，但未完全覆盖所有参数。

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?

描述明确说明该工具用于将事件写入PASM长期记忆，动词和对象清晰，并列举了应记录的内容类型（用户信息、承诺、偏好、共同经历），与兄弟工具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?

描述指出'值得记住的用户信息、承诺、偏好、共同经历都应该写进来'，提供了清晰的使用时机。但未明确说明何时不使用或与其他工具（如pasm_save）的替代关系，缺少排除性指导。

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 provided, the description carries the full burden. It discloses the key behavioral trait: this is a read-write tool with merge-update semantics (not replace). It also documents special interpretation of numeric persona fields (temper/energy/play as 0-1 scales) and the action pool as an array. However, it doesn't disclose whether updates are persistent, require authentication, or what the return value looks like after a view or update. A 3 is reasonable – the merge behavior is the most critical trait and is clearly stated, but other behavioral context is missing.

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 compact (about 40 Chinese characters) and every sentence carries information: mode selection, merge behavior, and key semantics. It is front-loaded with the purpose and immediately actionable. No wasted words.

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 tool with 2 optional parameters and no output schema, this description covers the core usage completely. The persona update semantics are fully explained including merge behavior and field domains. The main gap is agent_id semantics and the return value for both modes, but since the tool is likely a simple get/merge-set with a default agent, the description is sufficiently complete for an agent to invoke it correctly. A 4 is appropriate.

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 50%: the 'persona' parameter has a brief description, and 'agent_id' has only a default with no explanation. The description adds substantial semantics for the persona field by enumerating common keys (name/role/tone/temper/energy/play/actions) and their value types and scales. This compensates well for the low coverage. However, agent_id is still not explained in the description – an agent may wonder whether this is a user ID, a conversation ID, or what the default means – so it doesn't get a 5.

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 begins with a clear verb+resource combination: '查看或更新人格' (view or update persona). It explicitly distinguishes two modes: viewing when no persona is passed, and merging updates when one is provided. This is a specific, unambiguous purpose that clearly differentiates from sibling tools like pasm_status (which likely shows overall status) and pasm_context (context management), so an agent can tell them apart.

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 explicitly states when to use the viewing mode ('不传 persona 就是查看') versus the update mode ('传入为合并更新'). It also clarifies the merge semantics: unmentioned keys retain their original values. This is explicit when/how-to guidance, even though it doesn't name alternatives, it fully specifies the usage conditions for this tool's two modes.

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 are provided, so the description bears the full burden of behavioral disclosure. It reveals the return fields but says nothing about result ordering, behavior when no matches exist, how the k limit applies, or agent_id scoping — significant gaps for a retrieval tool with zero annotation coverage.

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 efficient sentence that front-loads the action and names the return fields. No wasted words, though it leans terse and could incorporate usage guidance without losing conciseness.

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?

Medium complexity tool with 3 params, no output schema, and no annotations. The description names return fields, which helps, but omits ordering, empty-result behavior, and how it differs from pasm_semantic — leaving an agent somewhat under-informed about call outcomes.

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 67% and all three parameters (query, k, agent_id) have descriptions in the schema itself. The description adds the return-format meaning but does not clarify parameter semantics beyond what the schema already states; the moderate coverage means it neither needs to fully compensate nor is it redundant.

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 specific action (检索/retrieve from PASM long-term memory) and names the output fields (title/summary/tags/importance). It clearly conveys what the tool does, though it doesn't explicitly differentiate itself from the closely related sibling pasm_semantic.

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?

No guidance on when to use recall vs. the alternative pasm_semantic (likely a semantic/search variant). No mention of prerequisites or conditions for use, leaving the agent to infer its role from the name alone.

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 of disclosing behavior, and it does state the core side effect: immediate disk persistence and the default scope of saving all loaded agents. It does not mention permissions, confirmation, or potential overwrite behavior, but the main operation is transparent enough for a simple save tool.

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, front-loaded sentence communicates the action, the scope modifier, and the parameter behavior with zero filler. Every element earns its place.

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 tool with no output schema, the description is almost fully complete: it names the operation, the object, and the parameter's default behavior. It could mention what the caller receives on success, 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 describes agent_id as optional, but the description adds meaningful semantic value by specifying the default outcome: omitting agent_id saves all loaded agents. This goes beyond the bare 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?

The description uses a specific verb ('落盘'/persist to disk) with a clear resource ('PASM 状态'), and immediately clarifies the optional agent_id scope. It stands apart from sibling tools like pasm_recall or pasm_status by being the explicit persistence operation.

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 explains the behavioral rule for omitting agent_id, but it does not explicitly state when to use this tool versus alternatives such as pasm_consolidate. Usage context is implied rather than directly spelled out.

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?

While there are no annotations, the description does disclose key behavioral traits: it uses vector search plus Chinese synonym expansion, and it weights by 'memory retention' with natural forgetting. However, it doesn't mention whether results are read-only or any side effects, but given the nature of retrieval, these are less critical.

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 compact and front-loaded with purpose and usage context. It avoids unnecessary details and fits in a few lines. Minor redundancy with '认知层' but overall efficient.

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?

Given the complexity is moderate and the schema covers most parameters, the description provides enough for an agent to understand when and how to use it. It lacks details on return format, but no output schema exists, so this is acceptable. The description covers the essential usage scenario.

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 80%, so the schema already documents most parameters. The description adds context about weighting by retention and forgetting, which relates to the use_forgetting parameter, adding slight extra meaning beyond the schema's brief descriptions.

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 clearly states the tool performs semantic retrieval with synonym expansion and explains why results are returned. It distinguishes itself from pasm_recall by mentioning it's a fallback when the latter fails, and it highlights the cognitive layer aspect.

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 when to use this tool: as the second step when pasm_recall fails. It contrasts this with pasm_recall and implies alternatives, giving clear context for selection.

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 are provided, so the description carries the full burden. It suggests a non-destructive read via '查看' and reveals the returned fields, but it does not explicitly state side-effect-free behavior, behavior on missing agent_id, or any permissions/rate limits. It adds value by listing the snapshot contents but stops short of documenting edge-case behavior.

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 action ('查看 PASM 状态快照') and then enumerates the key fields. It is compact and every clause conveys meaningful content, with 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 one-parameter, no-output-schema tool, the description lists the main return contents and clearly states the tool's purpose. However, it omits any mention of the optional agent_id parameter, how values are formatted, or potential error conditions, which could lead to incorrect invocation when targeting a specific agent.

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 0% and the description never mentions the agent_id parameter. The tool name and parameter name are self-explanatory, but the description adds no meaning about how agent_id affects the snapshot, so the agent receives no guidance beyond the bare 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?

The description names a specific verb ('查看' – view) and resource ('PASM 状态快照'), and lists the exact fields included, distinguishing it from sibling tools that perform actions (pasm_save, pasm_act) rather than querying state. No sibling is about status, so this is unambiguously the status reader.

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 no guidance on when to use this tool compared to alternatives. It merely states what it does, leaving an agent to infer use cases. There are no explicit 'use when' conditions or exclusions, so an agent might not know whether to call this or pasm_context for a status check.

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