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

With no annotations, the description carries the full behavioral burden. It usefully discloses the output composition and deterministic ordering (resident first, recent after) and the token/cache motivation, but says nothing about permissions, side effects, behavior when no memory exists, or rate limits.

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 purpose and the call recommendation are front-loaded, and the trailing parenthetical about output ordering and cache efficiency is compact. It is dense but every clause contributes; no filler sentences.

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 no-annotation read tool with three optional parameters and no output schema, the description covers what the tool returns (composition plus ordering) and when to call it. It is largely sufficient, with only minor gaps around edge-case behavior and result field 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 description coverage is 100%, so the schema already documents limit, branch (including auto-detection and branch-weighting behavior), and project thoroughly. The description adds no parameter-level detail beyond that, 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?

The description names a specific verb and resource: retrieving a resident context package composed of resident memory plus recent key memories in one call. This distinguishes it functionally from the list/search siblings by emphasizing the bundled, cross-Agent shared payload. It does not, however, explicitly name any sibling it replaces or differs from.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a clear trigger condition: '建议每次对话开始时调用' (recommended at the start of each conversation), which tells the agent when to reach for it. It stops short of naming alternatives (e.g., memory_list or memory_search) or stating when not to use it, so there is no exclusion 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?

No annotations are provided, so the description must carry the full burden. It discloses that the deletion is a soft delete, which is a valuable behavioral trait. However, it does not explain what soft delete entails (e.g., recoverability, data retention, or side effects), leaving important context unstated.

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, front-loaded sentence with no wasted words. It efficiently conveys the core purpose and the soft-delete behavior. A slight lack of structure (e.g., no separation of usage notes) keeps it from a 5.

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 tool with no annotations and no output schema, the description is minimally adequate. It states the soft-delete nature but omits important details such as what happens after deletion, whether it can be undone, or any required permissions. More context would be needed for a higher score.

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 input schema has 100% description coverage for the single 'id' parameter, so the schema already fully documents its meaning. The description adds no additional semantic detail about the parameter, which is acceptable given the high 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?

The description clearly states the action ('删除' – delete) and resource ('一条记忆' – a memory). It also clarifies the operation is a soft delete. However, it does not explicitly differentiate from sibling tools like memory_pin or memory_save, which would be needed for 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 description offers no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The usage is only implied by the verb, which is not sufficient for a higher score.

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 must carry the full behavioral burden. It reveals the output format (markdown) but says nothing about whether the card is persisted, whether an existing card for the project is overwritten, what permissions are needed, or how the result is returned — critical unknowns for a mutation-flavored 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 compact clause with the action verb front-loaded and zero filler. It is appropriately sized for a one-parameter tool, though the brevity borders on under-specification rather than pure efficiency.

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 1-param tool with no output schema and no annotations, the description is minimal but sufficient to identify the action. It omits whether the card is saved to memory or returned inline and whether re-invocation overwrites prior cards, leaving real gaps 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% for the single 'project' parameter, so the schema already documents it. The description adds nothing about the parameter (e.g., whether it must match an existing project name), so the baseline 3 is correct.

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: generates a project handoff card in markdown. The card concept distinguishes it from the memory_* siblings, though the description never explicitly names what it does not do. An agent can infer its role from the phrase 'handoff card', but sibling routing is left implicit.

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 a clear trigger condition: '切换到另一个 Agent 时' (when switching to another Agent) and the purpose of injecting context. However, it does not mention alternatives such as session_save or memory_context, which are plausible competing choices for carrying context across sessions.

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 conveys only that results are 'recent', saying nothing about ordering, pagination, default result count behavior, permissions, or what fields are returned for a multi-parameter list 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 phrase with no wasted words, and the purpose is front-loaded. It is concise only because it is minimal, bordering on under-specification for a tool with three parameters.

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, three parameters at 33% coverage, and a one-line description, the definition is not complete enough for an agent to call this tool confidently. Nothing about result shape, filtering behavior, or defaults is covered.

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 'limit' is documented as defaulting to 20), and the description adds no parameter meaning at all. The 'type' and 'project' parameters are unexplained in both the schema and the description, so the description fails to compensate for the coverage gap.

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 clear verb and resource with a scope qualifier ('list recent memories'), so the agent knows it enumerates stored memories rather than mutating them. However, it offers no differentiation from closely related siblings such as memory_search, memory_context, or memory_recall, leaving the agent to infer which listing tool 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?

There is no explicit when-to-use guidance, no mention of when to prefer memory_search or memory_context, and no stated prerequisites. The word 'recent' weakly implies browsing without a query, but this is inference rather than stated 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?

No annotations are provided, so the description carries the full burden. It does disclose the key behavioral consequence — pinned items are always returned by memory_context — which is real value beyond the schema. It omits idempotency, behavior when the id does not exist, and any cap on the number of pinned 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?

A single sentence with the action front-loaded; the parenthetical defining 常驻 is the one clause of genuine added value and nothing is wasted.

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-parameter toggle with full schema coverage and no output schema, the description covers the essential effect. Minor gaps remain around failure cases (invalid id) and interaction with search results, but they are not central to calling it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters are documented in the schema (id, pinned with 1/0 semantics and default 1). The description adds no format or edge-case detail about those parameters, 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?

The description states a specific verb pair (set as pinned / unpin) on a specific resource (a memory), and explains what 'pinned' means. It references the sibling memory_context that consumes the state, though it doesn't distinguish itself from memory_save or memory_delete beyond 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?

Usage is implied: use it when a memory should always accompany memory_context results. There is no explicit when-not guidance, no mention of alternatives (e.g., whether memory_save can set pinned directly), and no note on limits 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?

无 annotations 时描述需承担全部行为披露责任，而它明确说明了返回“写回回执”的内容（写了哪条/归到哪/出自哪/怎么撤）以及“没有任何东西会静默进入长期记忆”的写入语义，并附带让 Agent 把回执转述给用户的行为要求。未提及权限、限额等，但核心行为（可撤销、非静默写入）已披露。

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?

两句、前置了作用域与回执要点，信息密度高。回执四个要点用斜杠紧凑并列，无冗余铺垫，但整体略显压缩、可读性一般。

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?

对一个 10 参数、无 output schema 的写入工具，描述通过说明返回回执的内容弥补了缺少输出 schema 的空白，且点明可撤销性。但缺少与兄弟工具的分工说明，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 描述覆盖率 100%，10 个参数（含 branch 的自动读 git 分支、skip_check 默认 true 的排除逻辑、session_id 溯源等）已在 schema 中充分说明。描述未对参数做任何补充，按规则在高覆盖率下取基线 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?

明确的动词+资源：“保存一条记忆到本地共享记忆库”，并给出了区别于 session_save 等兄弟工具的关键作用域特征——“跨 Agent 可见”。但并未点名任何兄弟工具，无法帮助 Agent 在 memory_save 与 session_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?

没有给出何时使用本工具、何时应改用兄弟工具的显式说明。仅在末尾暗示写入是持久化/长期记忆，需要 Agent 自行推断它与 session_save、memory_handoff、memory_pin 的分工。

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 behavioral burden. It usefully discloses the retrieval mechanism (Chinese bigram plus English hybrid search), which is meaningful behavioral context. However, it does not state result format, ordering, limits, or explicitly confirm read-only 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 compact phrase with no wasted wording and is front-loaded. It is appropriately concise, though extremely terse for a tool with several filters.

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 and no output schema, the description should do more to explain what results are returned and how search behaves. It names the retrieval approach but omits return shape, ordering, and how the filter parameters affect results. This leaves material gaps 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 schema already documents all four parameters, including query, type, project, and limit. The description adds retrieval-method context but no parameter-specific meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource: 检索 (retrieve/search) the local memory store. It also states that retrieval is semantic and bilingual, which makes the purpose clearer than a bare name. It does not explicitly differentiate itself from siblings such as memory_list or session_recall.

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 explicit guidance on when to use this tool versus alternatives like memory_list, memory_context, or session_recall. The word 语义 implies a semantic-search use case, but no conditions, exclusions, or sibling routing are provided.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose the shape of the returned aggregates (total and three breakdowns) which is genuinely useful. However it says nothing about read-only nature, permissions, cost, or scope limits, leaving the safety profile unspecified.

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 phrase with the key information front-loaded (statistics) followed by the breakdowns. Nothing is wasted, though it is terse enough to border on under-specification about usage.

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 zero-parameter stats tool with no annotations and no output schema, the description supplies the essential missing piece: what the counts are broken down by. Read-only intent and any scoping constraints remain implicit, but the core need is met.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing to document and the schema is trivially complete. The baseline for a parameterless tool applies, with no compensating detail needed.

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 the resource (记忆库/memory bank) and the operation (统计信息/statistics), then enumerates the breakdown axes (total/by type/by project/by source Agent). This is specific enough to separate it from memory_list or memory_search, though it does not explicitly name a sibling it is not.

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 when-to-use or when-not-to-use guidance and no reference to alternative tools. An agent must infer that this is the aggregate-count tool rather than memory_list, which is a reasonable but unstated 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 must carry the behavioral load. It usefully discloses that the panel does not appear automatically, but says nothing about what invoking the tool returns (e.g. a URL or a UI side effect) or any permission requirements, leaving a gap for a no-annotation 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?

Front-loaded with the purpose, then the gating rule. Slightly repetitive — '只在用户明确想看面板时才调用' is restated as '平时不要主动调、也不要每轮对话都调' — but the redundancy is deliberate emphasis and remains 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?

For a zero-parameter, no-output-schema UI tool, the description covers purpose and invocation gating adequately. The only missing piece is what actually happens on invocation (navigation target, returned value), which a caller might reasonably want to know.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, which is the baseline-4 case; there are no parameter semantics to add meaning to, and the description correctly implies the call needs no arguments.

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 (打开 Loci 网页面板) and enumerates the panel's contents (记忆 / 会话原文 / 交接卡 / 库). This distinguishes it from the data-oriented siblings (memory_list, memory_search), though it does not name any sibling 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?

Explicit when-to-use ('只在用户明确想看面板时才调用', with example utterances) and explicit when-not ('平时不要主动调、也不要每轮对话都调'). This is unusually thorough routing guidance with concrete trigger phrases.

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 usefully discloses that results are raw verbatim fragments from the session layer rather than summarized memory, but says nothing about read-only safety, permissions, result ordering, or pagination 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?

A single front-loaded sentence that leads with verb and resource, then qualifies scope and purpose. No filler, though the clause structure is slightly dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description does explain the return content (verbatim fragments), which covers the main gap. It still leaves unclear how it relates to the numerous retrieval siblings and what an empty or partial result looks 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 description coverage is 100%, so limit, query, and project are already documented in the schema (including the default of 5). The description adds no parameter-level detail beyond what the schema provides, which is the baseline 3 case.

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 (历史对话原文), and adds the return form (原话片段) and the session-layer scope. It does not name the sibling it contrasts with, so an agent must infer how it differs from memory_search or memory_context.

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 use case (复现旧对话上下文 in a new Agent) implies when to reach for it, but there is no explicit when-not guidance and no alternative named among the many retrieval siblings (memory_search, memory_context, memory_list).

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 zero annotations the description carries the full burden. It does disclose the essential behavior — the transcript is persisted into a local library and later retrievable by other agents — but says nothing about overwrite/duplicate semantics, required permissions, title auto-generation side effects, or failure modes for a write 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?

Two short sentences, zero padding, with the action and scope front-loaded. Efficient, though the second sentence mostly restates persistence already implied by 归档.

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?

No output schema and no annotations, so the description must cover return/behavior on its own. It conveys persistence and retrievability but omits return values, conflict handling, and the save-vs-memory routing decision, leaving gaps for a 5-parameter write tool.

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 schema already documents all five parameters including the transcript format hint (JSONL/JSON array). The description adds no parameter-level detail beyond what the schema provides, 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 distinguishes scope from the memory_* siblings by naming the session layer. It even hints at the read counterpart ('其他 Agent 之后可检索复现'), though it does not name session_recall 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?

No explicit when-to-use, no exclusions, and no comparison to memory_save, which is the obvious confusing sibling since both persist content. The '会话层' phrasing implies a session-vs-memory distinction but leaves the agent to infer it.

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