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

No annotations are provided, so the description carries the full behavioral burden for what is a write/mutation tool. It says nothing about persistence scope, whether an existing mapping is overwritten, what happens on duplicate canonical/alias pairs, or required permissions — only the intended benefit.

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: verb first, purpose second, example last. Nothing is redundant, though the example could be dropped without loss of meaning 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 an annotation-free mutation tool with no output schema, the definition should describe at minimum whether the mapping persists across memory_recall and whether conflicts overwrite. Both are missing, leaving the agent unable to predict side effects of the call.

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%: canonical (标准词) and alias (同义词) are already documented in the schema. The description's 香菜 ↔ 芫荽 example reinforces the direction of the mapping but adds no constraints (length, normalization, direction rule) beyond the schema — baseline 3.

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 concrete verb (添加/add) plus resource (同义词映射/synonym mapping) and illustrates it with a cilantro↔coriander example, so the effect is unambiguous. No sibling in the list handles aliases, so no differentiation is strictly needed, but the description never explicitly says that.

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 clause 让召回不漏 ('so recall doesn't miss') hints at the motivating use case (improving memory_recall coverage), which is genuine implied guidance. It does not state when to prefer this over memory_remember/memory_update, nor any exclusion such as when an alias already exists.

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 and does disclose the single most important behavioral trait: the default is a soft delete whose record remains queryable, and only hard=true destroys it. It stops short of saying whether soft-deleted memories surface in memory_list/memory_recall or whether the operation is reversible.

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, zero filler, and the default behavior is front-loaded before the opt-in destructive flag. Nothing could be removed without losing meaning.

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?

A two-parameter tool with full schema coverage and no output schema needs little more than a clear statement of destructive semantics, which this provides. The remaining gap is what a soft-deleted memory means operationally for the read-side sibling tools.

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 both parameters are already documented in the schema. The description reinforces the `hard` semantics and its default, but adds no format, range, or id-resolution detail beyond what the schema states, so 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 ('删除一条记忆') and immediately scopes it into two modes (soft vs. hard). It does not name or contrast any sibling such as memory_update or memory_resolve, so an agent must infer the boundary itself.

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 the decision rule for the two modes ('默认软删除' vs. 'hard=true 才彻底删除'), which is genuinely useful guidance. However, it gives no when-not-to-use condition, no prerequisites (e.g. whether the id must be active), and no pointer to an alternative sibling tool.

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. '查看' (view) implies a read-only, side-effect-free operation and the description usefully discloses the shape of the result (six-factor breakdown), but it says nothing about permissions, what happens if the id is unknown, or whether the computation is expensive.

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 with the core purpose stated first and the parenthetical output hint second; no filler. It is short enough that the only slight cost is that the parenthetical is the sole clue about what is returned.

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 read-only introspection tool with no output schema, the description covers both input intent (which memory) and output shape (six-factor importance breakdown), which is the key missing piece. Error behavior for an invalid id is the only notable 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?

Schema coverage is 100% and the single 'id' parameter is already documented as '记忆 id' in the schema. The description adds no format, range, or sourcing details beyond that, so the baseline of 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?

The description states a specific verb and resource: '查看某条记忆为什么是这个重要度' (view why a given memory has this importance level), and adds that the result is a six-factor breakdown. This clearly distinguishes the tool from siblings such as memory_stats (aggregate) and memory_recall (content retrieval), though it does not name those siblings directly.

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 intent (explain an importance score) implies when to use the tool, but there is no explicit guidance on when to prefer it over memory_stats or memory_recall, and no prerequisites or exclusions are stated. Usage is inferable rather than 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?

No annotations are provided, so the description carries the full burden. It says a file is written but not whether an existing file at 'path' is overwritten, what permissions are needed, whether the export is atomic, or how long it takes on large stores—critical side-effect details for a write-to-disk 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 with no filler. It is efficient, though the terseness is part of why other dimensions fall short.

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 annotations, no output schema, and no explanation of return value, overwrite semantics, or scope of the exported data, the definition does not give an agent enough to call this safely and predictably.

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 both 'path' and 'profile' are already documented in the schema. The description adds no extra meaning (e.g., whether 'profile' scoping changes the output structure or is recorded in the file), so the baseline of 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+resource+output format: exporting memories into a JSON backup file. An agent can distinguish it from memory_recall/memory_list (read queries) by the 'backup file' outcome, but the description never names a sibling or explicitly contrasts itself with them.

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 word '备份' implies a backup scenario, but there is no explicit when-to-use, when-not-to-use, or alternative routing (e.g., use memory_recall for querying, memory_export only for durable copies). Usage must be inferred from the name.

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 behavioral burden, and it only discloses that dormant entries are included. It says nothing about read-only semantics, ordering, whether a default limit truncates results, or what the response looks like. For a no-annotation tool this leaves significant 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?

A single compact sentence with the resource and scope front-loaded and no filler. It is efficient, though its brevity is part of why other dimensions are thin.

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 three optional parameters, no annotations, and no output schema, the description should say more about what comes back and how truncation/ordering behaves. As written, an agent knows it lists entries including dormant ones but little else needed to call it confidently.

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 limit, status, and profile are already fully documented in the schema, which sets the baseline at 3. The description's mention of "含休眠中的" loosely relates to the status filter but adds no syntax, defaults, or interaction 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?

The description states a concrete verb and resource ("列出记忆条目") and adds scope (includes dormant entries), so the basic action is clear. However, it never distinguishes itself from close siblings such as memory_recall, memory_stats, or memory_export, all of which could plausibly also 'view' memory. An agent must infer from the name alone which one to pick.

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?

"用于查看记忆库全貌" implies a browsing/overview use case, which is a reasonable hint about when to use it. But there is no explicit when-not guidance and no named alternative (e.g., use memory_recall for targeted lookup, memory_stats for counts), leaving the choice to 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read-only view operation and names the reported dimensions, but does not disclose permissions, data scope, rate limits, privacy behavior, or whether it triggers any side 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?

It is a single front-loaded sentence that immediately states the tool's purpose, followed by a compact list of reported aspects. There is 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 explains the kinds of outputs an agent will get, which is useful because there is no output schema. However, with no annotations and only implied usage guidance, it does not fully cover behavioral context such as safety, permissions, or when this tool should be preferred over related memory tools.

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 both parameters (days and profile) are already documented with defaults. The description does not add syntax, constraints, or meaning beyond the schema, making the baseline score of 3 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 states a specific verb and resource: "查看近期情绪轨迹" (view recent emotional trajectory), and lists the concrete aspects it reports. It is clearly distinct from general memory recall/list tools, though it does not explicitly name or contrast with sibling tools.

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 no guidance on when to use this tool versus alternatives such as memory_recall, memory_list, or memory_stats. Usage is only implicitly suggested by the name and description, with 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?

No annotations are provided, so the description carries the full burden. It does disclose the key behavioral consequence — pinned memories never sink and are always considered during recall — and the word 取消 makes clear that pinning is reversible. It still omits side effects such as what happens if the id does not exist, whether the operation is idempotent, or what the call returns.

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 with zero filler: the action comes first and the behavioral rationale follows. Every clause adds information, and the parenthetical is a compact usage hint.

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 two-parameter mutation with no output schema and no annotations, the description covers the effect but leaves gaps around failure modes and return behavior. Nothing incorrect is present, but more edge-condition coverage would be needed to call it complete.

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%, and the schema already explains both `id` and `pinned`, including the default of true. The description adds no parameter-level detail beyond that, which is the expected baseline of 3 when the schema does the heavy lifting.

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 pair (pin/unpin) and the resource (a memory), so the agent immediately knows the operation. It does not explicitly distinguish itself from nearby siblings such as memory_update or memory_alias, which keeps it below 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?

The parenthetical '手动抢救' (manual rescue) implies the situation in which this is appropriate — a memory that would otherwise sink. However, there is no explicit when-not condition, no mention of alternatives such as memory_update, and no statement about prerequisites (for example, the id must belong to an existing memory).

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 does disclose a genuine behavioral trait — result set is deliberately truncated to a few highly relevant items rather than full history — but says nothing about ranking method, permissions, or response shape for a read tool with a 3-param surface.

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 compact sentence that front-loads the action and parenthesizes the scope constraint. No filler, no restatement of the 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 3 simple parameters, full schema coverage, and no output schema, the description supplies the one thing the schema cannot: that results are a small relevant subset, not history. Missing details like relevance ranking or whether results are deduplicated are minor at this complexity.

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 each parameter is already documented (query, top_k default 5, profile default 'default'). The description only adds the framing that query is the current topic, which is marginal value beyond the schema — 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 ('召回相关记忆') plus a scoping constraint ('只返回少量高度相关的，不返回全部历史') that implicitly distinguishes it from sibling list-style tools such as memory_list. It stops short of naming an alternative sibling explicitly, so it lands at 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?

The phrase '按当前话题' implies the trigger condition (there is an active topic/query), but the description never states when to prefer this over memory_list, memory_wake, or memory_explain. Usage is inferable rather than instructed.

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 must carry behavioral burden; it does add real value by disclosing that storage is split into primary/secondary tiers and that duplicate content reinforces rather than duplicates. However, it omits permissions, whether writes are reversible, and what the agent gets back after storing.

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 that states the purpose first and the non-obvious dedup/reinforcement behavior second. 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?

For a six-parameter write tool with full schema coverage and no output schema, the description covers the essential semantics including the surprising merge-on-duplicate behavior. Only the lack of any statement about side effects on near-duplicate or conflicting memories keeps it from a 5.

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%, so the schema already documents all six parameters including the kind enum and importance range. The description adds only the duplicate-reinforcement behavior tied to content, which does not meaningfully extend per-parameter meaning, making the baseline 3 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?

States a specific verb+resource (写入记忆库 / write into memory store) and scopes it to information worth remembering long-term, which distinguishes it from read-oriented siblings like memory_recall and memory_list. It does not explicitly differentiate from the closer sibling memory_update, so it falls 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?

Implies when to use it ('值得长期记住的信息'), giving a usable criterion, but never names alternatives such as memory_update for existing entries or memory_pin for emphasis. The duplicate-handling note hints at usage but no explicit when-not guidance is present.

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 does disclose the key behavioral trait — this is a manual override that bypasses the natural resolution path — which is genuinely useful. However it omits reversibility, whether the mark is permanent, permission/auth needs, and any confirmation of what state change occurs; for a mutation tool these gaps keep it at adequate rather than strong.

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, zero filler, with the action stated first and the caution immediately following. Nothing is buried or redundant.

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 mutation tool with no annotations and no output schema, the description covers purpose and the caution/routing signal, which is the essential part. It still leaves the agent guessing about the effect of the call (irreversibility, what the memory looks like afterward, error cases for invalid ids), so it is adequate but not complete.

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?

There is one parameter (id) with 100% schema description coverage ('记忆 id'), so the schema already handles the semantics. The description implies the id names the memory being resolved but adds no format, validation, or failure-mode guidance beyond that; 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-plus-resource: it force-marks a given memory ('心结', via id) as resolved. The '人工强制' qualifier implicitly contrasts with the natural-decay path used elsewhere, though no sibling tool is named explicitly. An agent can tell what it does, but must infer which sibling normally handles resolution.

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 says '慎用' (use with caution) and states the normal case — resolution should emerge naturally from time/expression/state evidence — which functions as a clear when-not-to-use condition. It stops short of naming the alternative tool or defining what 'evidence-based' resolution looks like operationally.

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 usefully discloses that the memory is not deleted and that it simply will not be recalled under normal conditions. It does not state whether the sleep is reversible, how to reverse it, or whether any permissions or side effects apply.

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 with zero waste. The core behavior and the non-deletion constraint are 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 simple one-parameter mutation tool, the description covers the essential behavior and clarifies that data is not destroyed. It is slightly incomplete because it omits reversibility details and explicit routing to memory_wake, but the core semantics are sufficient given the simple 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?

The single required parameter 'id' is fully documented in the schema (100% coverage), so the schema already does the heavy lifting. The description adds no additional semantics about the identifier beyond what the schema provides, making the baseline score of 3 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 states a specific verb and resource: manually putting a memory into sleep. It also distinguishes the action from deletion ('不删除'), which helps separate it from memory_delete. However, it does not explicitly name memory_wake as the counterpart, so sibling differentiation is strong but not complete.

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 implied: use this when you want a memory to stop being recalled normally without deleting it. There is no explicit when-to-use guidance, no mention of when to prefer memory_delete or memory_wake, and no stated 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?

No annotations are provided, so the description carries the full burden. 'View statistics' implies a read-only, non-destructive operation and the enumerated metrics give a rough sense of the return payload, but the description says nothing about cost, permissions, or how dormant/pinned are counted. Adequate but thin for an unannotated 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 short sentence that front-loads the action and then lists the reported fields. No filler, no repetition 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?

For a simple, single-optional-parameter read tool with no output schema, the description conveys enough to invoke it correctly and even previews the returned counters. Only the profile-scoping semantics remain unaddressed.

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 single optional 'profile' parameter is already documented there with its default. The description adds no additional meaning about what profile scoping does to the statistics, so the baseline of 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 (查看/view) and resource (记忆库统计/memory-library statistics) and enumerates the metrics returned (total, active, dormant, pinned). This clearly separates it from siblings like memory_list or memory_recall, though it never names those siblings 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?

Usage is only implied: an agent can infer this is a metrics/overview call rather than a content-retrieval call. There is no explicit statement of when to reach for it versus memory_list or memory_recall, 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 full burden and does disclose one important side effect: the memory is automatically re-scored after the edit, so ranking changes. It omits what happens to fields not supplied (e.g. kind retained or reset), whether the edit is reversible, and 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?

A single short sentence that front-loads the action and appends the side effect; no filler. It is efficient but too terse to be exemplary.

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 three-parameter mutation with no output schema and no annotations, the description is minimally adequate. It does not explain the re-scoring consequence in terms an agent can act on, nor does it cover the optional field's effect.

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%, so id, kind, and content are already documented in the schema. The description adds no detail on the optional kind parameter or on how content replacement interacts with re-scoring, so the baseline of 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 (一条记忆的内容), so the operation is unambiguous. It does not contrast itself with siblings such as memory_remember or memory_delete, though the name makes the mutation role discoverable.

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?

There is no guidance on when to update versus delete-and-recreate via memory_remember, nor any prerequisite such as needing a valid id from memory_list or memory_recall. Usage is only implied by the verb.

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 of behavioral disclosure. It does not say what state change occurs (dormant to active), whether the operation is reversible (the counterpart memory_sleep exists), what happens if the id refers to a memory that is not dormant, or whether it requires confirmation, which are all material for a mutation 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 short sentence with no padding, and the key action is front-loaded. It is efficient, albeit partly because it omits the information it should contain.

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 state-mutating tool with no annotations and no output schema, the description is too thin: it says neither what the call returns, nor how failure when the memory is not dormant is signalled, nor how it relates to memory_sleep and memory_recall.

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?

There is one parameter and its schema coverage is 100%, so the schema fully documents `id`. The description adds no further meaning beyond that, which is the expected baseline when the schema does the work.

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 and resource: manually reviving a dormant memory ('想起来' / recall). It is more than a restatement of the name, but it does not distinguish this operation from the sibling memory_recall tool, which presumably covers the ordinary recall path, so the boundary between the two is left to inference.

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 word '手动' (manually) implies a contrast with an automatic mechanism, but the description never states when an agent should call memory_wake rather than memory_recall or memory_pin, nor does it give preconditions such as the memory having to be dormant first.

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