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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed world), so the bar is lower; the description still adds that evaluation is 确定性, which reinforces the idempotent contract in task terms. It stops short of stating error behavior or the length limit, so it is good but not exhaustive.

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, capability stated first, invocation condition second, zero filler. Every clause 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 simple, fully annotated, closed-world utility the description is sufficient to invoke correctly. The only shortfall is that with no output schema, the return shape (number vs formatted string) is never indicated.

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 expression parameter already carries a worked example, so baseline is 3. The operator list in the description is complementary syntax information, but the ambiguity that matters most — whether ^ is exponentiation and % is modulo vs percent — is left unresolved 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?

Names a specific verb (确定性求值) and resource (算术表达式), then enumerates the operator set (+ - * / % ^ 与括号), which cleanly distinguishes it from the date-oriented siblings answer_date_diff/answer_date_shift. An agent needs no schema inspection to know exactly what this does.

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 an explicit trigger condition (when recalled values need 加减乘除, with concrete examples 金额合计、单价×数量) plus a negative instruction (不要心算) that steers the agent away from an inferior alternative behavior. This is exactly the when-to-use guidance the dimension asks for.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the range of accepted date syntaxes, which is useful but is really input-format information. No handling of ambiguous or malformed dates is disclosed; with annotations carrying the behavioral burden, a 3 is appropriate.

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 tight clauses: what is computed, what input formats are tolerated, and when to trigger it. Nothing is padded and the core purpose 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?

There is no output schema, and the description compensates by stating the return shape (day count plus Y/M/D decomposition). For a two-parameter read-only utility with full annotation coverage, this is essentially complete; only edge cases such as reversed or unparseable dates are 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 both required parameters carry their own descriptions (起始日期 / 结束日期), so the baseline is 3. The description goes beyond that by enumerating the accepted date formats (ISO, YYYY/MM/DD, Chinese 2024年3月5日), which materially helps an agent format the inputs correctly.

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 — computing the difference between two dates — and even specifies the output shape (total days plus a year/month/day breakdown), which distinguishes it from the sibling answer_date_shift (which moves a single date) and answer_calculator. An agent can route to it without opening the schema.

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 an explicit trigger condition: call it when the question involves '间隔多少天/多久'. That is clear when-to-use guidance, but it never names answer_date_shift as the alternative or excludes the cases that belong to it, so the routing guidance is one-sided.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile needs no restating. The description adds genuinely new behavioral information: negative day offsets are allowed and the result includes both the date and the weekday. It does not mention accepted input date formats or boundary behavior, which keeps it from a 5.

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: the operation and its return value come first, then the usage trigger. No filler, no repetition of the title, and nothing that could be trimmed without losing information.

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-required-parameter, closed-world, idempotent read tool with full schema coverage, the description covers operation, accepted sign of the offset, and the return shape (no output schema exists, so stating the return value matters). The only material gap is the expected date input format, which an agent must guess at given the loose 4–40 character constraint.

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% — the schema itself documents 基准日期 and 平移天数，可为负数, and even the injected _memoryRequestKey. The description's note that days may be negative merely repeats the schema, adding no new semantics, 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 (把日期平移指定天数) and even names the return value (结果日期与星期), so an agent immediately knows this is date arithmetic, not date parsing or lookup. It stops short of explicitly distinguishing itself from the sibling answer_date_diff, relying on the reader to infer 'shift' vs 'difference'.

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 second sentence gives concrete triggering question shapes ("X 天后是几号", "提前 N 天"), which is real usage guidance rather than vague intent. It does not, however, name answer_date_diff or answer_calculator as the alternative for non-shift date questions, so the boundary between siblings is left implicit.

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?

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds meaningful nuance: the delete is a recoverable soft delete and audit records are retained. This changes how an agent should interpret the destructive hint. It does not cover auth, error, or rate-limit behavior, so not a 5.

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: purpose front-loaded, behavioral nuance second. 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?

Covers purpose and the key soft-delete/audit behavior, but with no output schema and only 33% parameter coverage, it leaves parameter usage and return behavior unexplained. Adequate for a simple mutation tool but incomplete.

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 33% (only _memoryRequestKey is documented). The description implies the id via '一条记忆' but gives no format, syntax, or explanation for the id or reason parameters, so it fails to compensate for the low schema coverage.

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 (删除/delete) and resource (一条记忆/one memory) with a clear single-item scope tied to an explicit user request. It is inherently distinguishable from memory_remember/memory_update/memory_recall, but no sibling is named, so it does not meet the 5 bar of explicit differentiation.

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?

Establishes a clear invocation condition: use only when the user explicitly requests deletion ('根据用户明确要求'). No when-not guidance or named alternatives are provided, 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is covered. The description adds the useful behavioral fact that the return value is context-ready compact text meant for injection, but says nothing about budget handling or truncation despite a contextTokenBudget parameter.

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 action and followed by the invocation timing; zero wasted words. It is arguably too terse for a 9-parameter tool, but as written it is efficient and well-ordered.

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 9 parameters at 22% schema coverage and no output schema, the description should explain the retrieval knobs and the shape of the returned text. It instead covers only the high-level purpose, leaving most of the calling surface undocumented.

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 22% across 9 parameters, so the description is expected to compensate — and it does not. Only the oblique phrase about 'compact text for model context' hints at contextTokenBudget; nothing explains query, tags, kinds, minScore, namespace, recentTurns, or the injection key.

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 gives a specific verb+resource ('检索相关长期记忆' / retrieve relevant long-term memory) and even characterizes the output ('返回可直接加入模型上下文的紧凑文本'). That output framing helps separate it from memory_recall/memory_list, though no sibling is named explicitly, 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?

It states a clear trigger — call before answering the user, suited to every conversational turn — which is genuine usage guidance. However, it names no alternatives (memory_recall, memory_list) and gives no when-not/exclusion conditions, so the agent must infer the boundary against siblings.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only usage framing and no behavioral detail beyond it – nothing about pagination behavior, default result size, or what a filtered empty result means. With annotations carrying the safety burden, a 3 is appropriate.

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 filtering scope front-loaded and no filler. It is efficient, though it is arguably too terse given the parameter surface it needs to support.

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 8 parameters, no output schema, and 13% schema coverage, the description should explain the filtering and pagination model. Instead it offers only a high-level purpose, so an agent lacks enough to invoke it correctly against ambiguous siblings like 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?

Schema description coverage is only 13% (essentially just the internal _memoryRequestKey), so the description must compensate and does not. The vague phrase '按条件' gestures at filtering but never explains tag, kind, query, status, namespace, or the limit/offset pagination semantics, leaving 6+ meaningful parameters undocumented.

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 clear verb+resource: '按条件查看记忆' (view memories by condition), which reads as a filtered list operation. However, it does not differentiate from siblings like memory_recall or memory_get_context, which also retrieve memories, so an agent cannot tell which retrieval tool to pick from the description alone.

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?

Provides some usage context ('适合管理、核对或让用户确认系统记住了什么' – managing, verifying, or user confirmation), which implies when it is useful. But it never names alternatives (memory_recall, memory_get_context, memory_stats) or states when NOT to use it, so routing among the memory retrieval siblings is left 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?

Annotations already confirm readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds useful beyond-annotation context: it returns only a small set of relevant memories and explains why each hit was returned.

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 with no wasted text, and the usage trigger is front-loaded before the return behavior. Every sentence 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 10-parameter retrieval tool with low schema description coverage and no output schema, the description covers purpose and usage but leaves optional filters unexplained. An agent cannot determine how to use the filtering parameters from the description.

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 20%, and the description does not explain any parameter beyond implying the required query. It provides no meaning for tags, kinds, limit, minScore, namespace, timestamp, includeArchived, recentTurns, or the internal request key.

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 says it returns a small amount of long-term memory relevant to the current query, which is a specific retrieval purpose. It does not explicitly differentiate itself from sibling tools such as memory_get_context or memory_list, 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?

It clearly states when to call: before answering questions about user preferences, past events, project status, or existing decisions. It provides no exclusions or named alternatives, so it is clear context without full when-not 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?

Annotations already declare the operation is a write, idempotent, and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: duplicate content is automatically merged, and sensitive information requires user consent — neither of which is expressed in the structured fields.

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 tight sentences: what to save, what not to save, and the merge behavior. No filler, and the positive guidance is front-loaded before the exclusions.

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 17-parameter mutation tool the description delivers a solid intent and safety story, and annotations plus a documented schema handle the rest. However, most non-required parameters receive no narrative explanation, so an agent gets little help on scoping or temporal fields.

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?

With 17 parameters and only ~53% schema coverage, the description carries some burden but offers no explicit parameter guidance. It does helpfully map its list of content types onto the kind enum values (preference, project, event, instruction), but says nothing about scope, namespace, supersedesId, idempotencyKey, or the time fields.

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 (save a long-term memory) and enumerates the content types that qualify (stable facts, preferences, project decisions, events, instructions). It clearly reads as the write side of the memory_* family, but it never names siblings like memory_update or memory_recall to disambiguate.

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?

Provides explicit negative guidance — do not save chit-chat, temporary state, passwords, tokens, or sensitive info without consent — which is strong when-to-use context. It lacks an explicit alternative path (e.g. when to use memory_update instead of writing a new memory), keeping it from 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds value by naming the returned dimensions (count, types, namespace distribution), which is useful given no output schema, but says nothing about refresh cost, scoping, or freshness of the statistics.

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 waste, front-loading the action and stating exactly what is reported. Nothing could be removed without losing information.

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 read-only, zero-required-parameter stats tool whose annotations already cover the safety profile, the definition is essentially complete: it names the metrics returned and the internal parameter is documented in the schema. The absence of an output schema is partly compensated by the enumeration of returned dimensions.

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% for the single parameter (_memoryRequestKey), which is an internal proxy-injected key already documented in the schema. The description adds no parameter-level detail, so the baseline of 3 applies when the schema carries the full load.

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 (长期记忆/long-term memory) and even enumerates what is surfaced: count, types, and namespace distribution. This clearly separates it from retrieval siblings like memory_list or memory_recall, though it never names an alternative 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 purpose implies the usage context (inspecting aggregate state of the memory store rather than reading or mutating entries), so an agent can infer when to reach for it, but there is no explicit when-to-use guidance, no exclusions, and no mention of any sibling as an alternative.

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?

Annotations already declare mutation (readOnlyHint=false), idempotency, and non-destructiveness, so the bar is lower. The description adds genuinely useful behavior beyond that: partial-update semantics (omit unchanged fields) and a content norm (write the corrected standalone fact, not a process note like 'user corrected'). It does not cover auth or side effects on related memories.

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 dense sentences that are front-loaded with the purpose, then the operational rule. Every clause earns its place with no filler, though the second sentence packs several distinct constraints that could be slightly clearer if split.

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 16-parameter mutation tool with no output schema and near-zero schema documentation, the description covers the key behavioral contract (partial update, content correction) but leaves too many parameters unexplained. Adequate but with clear gaps given the tool's 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 coverage is only 6% across 16 parameters, so the description must carry the burden. It meaningfully clarifies the `content` parameter and the general partial-update contract, but leaves id, kind, tags, status, validFrom/validTo, confidence, importance, namespace and source undocumented in both description and 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?

States a specific verb+resource (修改…记忆) and narrows scope to already-existing memories that are inaccurate, outdated, or incomplete, which implicitly separates it from memory_remember (create) and memory_forget (delete). It does not name any sibling explicitly, so differentiation is inferred rather than stated.

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 clear when-to-use context: correcting existing, inaccurate, stale, or incomplete memories, plus the partial-update rule (only submit fields that change). It lacks explicit exclusions or named alternatives (e.g., when to prefer memory_remember), so it stops 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.