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 two valuable traits: this is metadata-only editing that does not rewrite conversation content, and the summary enters the retrieval index. It says nothing about permissions, failure modes, or whether tag removal 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, front-loaded with the actionable operations, then a clarifying scope statement. Nothing is wasted or buried.

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 5-parameter mutation tool with no annotations and no output schema, the description covers the essential behavior and the critical non-destructive guarantee. Remaining gaps (return values, error handling on unresolved sessions) are partially mitigated by the schema's project 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 coverage is 60%, with project, summary, and session_id documented in the schema (including prefix support and the unresolved_project condition). The description adds the fact that add_tags/remove_tags exist and that the summary is indexed, but the two tag array parameters remain undocumented beyond their names.

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 concrete operations on a specific resource: adding/removing tags and setting a human summary on a session. This is far more specific than a bare verb, though it does not explicitly differentiate itself from siblings such as save_note.

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 by the stated capabilities (want to tag or summarize → use this), but there is no explicit when-to-use/when-not or reference to an alternative tool. The agent must infer that this is the right tool versus save_note for annotation-like work.

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 but does deliver real behavioral facts: sha256 integrity, default redaction (脱敏), and scope-respecting defaults. It omits what happens on file overwrite, whether the export is a write to disk with permissions implications, and what the caller gets back — meaningful gaps for a file-producing 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 sentence that front-loads the two output artifacts and then the behavioral qualifiers. Little waste, though the parenthetical detail is dense and would read better separated.

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 5-parameter, no-annotation, no-output-schema export tool, the description covers format, integrity, redaction and scope default reasonably well. But it leaves `decisions_only` unexplained and, absent an output schema, does not say what path or confirmation the caller receives.

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 60% and the description only reinforces what the schema already says about scope defaults and the hop/markdown choice. `decisions_only` is undocumented in both schema and description, which is the clearest semantic gap; baseline 3 for mid 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 names the concrete artifacts produced (.hop handoff package vs HANDOFF.md) and their key properties (sha256 integrity, default redaction), so an agent knows exactly what the tool does. It does not explicitly contrast itself with the inverse sibling import_handoff, 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 phrase '默认尊重当前 scope' implies usage context — use it as-is for the current scope, pass `all` for the whole library — but the tool never states when to choose it over import_handoff or when a handoff is warranted. Usage is implied rather than prescribed.

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?

There are no annotations, so the description carries the full burden. It correctly signals read-only enumerative semantics and adds genuinely useful result context (each decision has provenance and can be jumped back to). It omits scope/auth behavior, pagination, ordering, and what happens when the project is unresolved — which matters since the project parameter exists precisely for that failure mode.

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, front-loaded with scope ('本项目') before the qualifier about provenance. Zero waste, but it is arguably under-specified rather than concise — the terseness comes at the cost of the missing parameter and usage 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 3-parameter tool with no annotations and no output schema, the description is too thin. An agent still does not know what topic/source filter on, whether results are paginated or ordered, or how this differs from session-level lookup tools. Only the provenance/backlink hint partially fills the gap left by the absent output schema.

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

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

Schema description coverage is 33%: only the project parameter is documented, and quite well. The description's phrase '本项目' loosely implies project scoping but says nothing about the topic and source parameters, and does not explain how they interact or whether they narrow the 'all' list. With low coverage the description should have compensated, and it does not.

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 specific resource: all confirmed technical decisions for '本项目' (the current project), and adds that each carries provenance and a backlink. That is more than a restatement of the name. It does not, however, contrast itself with siblings like search_sessions or get_session_detail, which an agent might otherwise reach for when looking for decisions.

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 or when-not-to-use guidance, and no alternatives are named. The word '全部' (all) hints that this is an unfiltered enumeration, but the presence of topic and source parameters suggests filtering is possible, and the description never resolves that ambiguity.

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 discloses the cross-agent scope, but it says nothing about ordering, pagination, permission requirements, whether missing paths return empty results, or what the response looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

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

The description is a single compact sentence with no wasted wording, and the core purpose is front-loaded. It is terse, but the terseness is a specification issue rather than a conciseness issue.

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 return behavior and practical usage. It identifies the conceptual result (sessions that discussed the file), but omits ordering, pagination, project-resolution behavior, and response shape.

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

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

Schema coverage is 50%: the 'project' parameter has a useful schema description, while 'file_path' has none. The description implies that 'file_path' is the file being queried, but adds no format or path-resolution details beyond that. This is adequate but not compensating further for the missing schema description.

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

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

The description clearly states a specific query: which sessions discussed a given file path. The parenthetical '跨 agent' adds useful scope by indicating cross-agent history, distinguishing it from a generic session search. It does not explicitly compare against siblings such as search_sessions, 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?

The description gives no explicit when-to-use, when-not-to-use, or alternative-tool guidance. An agent can infer that it is useful when investigating file discussion history, but there is no routing guidance among the many session-related 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?

With no annotations provided, the description carries the full behavioral burden. It usefully discloses that results are bidirectional and include kind and direction, but it omits read-only safety, permissions, pagination, ordering, and whether project scoping affects results.

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 is efficient, though its terseness leaves little structure or signposting for an agent.

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

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

For a simple read query, it conveys the core scope and returned attributes. However, with no annotations and no output schema, more detail on safe read behavior, result limits, project scoping, and sibling alternatives would be needed for full completeness.

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

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

Schema coverage is 50%: the project parameter is well described in the schema, but the required session_id has no schema description. The description only says 'a certain session' and adds no ID format, requiredness, or project/session relationship detail.

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 resource and scope: all associations of a session, bidirectional, with kind and direction. It is clear what the tool retrieves, but it does not explicitly differentiate itself from siblings such as link_sessions or suggest_related_sessions.

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 does not state when to use this tool versus alternatives like link_sessions, suggest_related_sessions, or get_session_detail. There are no prerequisites, exclusions, or routing guidance beyond the implied purpose.

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?

没有注解，所以描述承担了披露行为特征的全部责任，并且确实披露了关键操作形态：约 20KB 的默认截断上限、单条截断长度，以及 session_id 支持前缀匹配。缺失的是返回内容形态和权限要求，但对读取工具来说，关键约束已经交代清楚。

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?

7 个参数、无输出 schema、无注解；描述覆盖了主要行为约束与扩量路径。仍缺少返回结构说明，对首次调用者存在少量不确定，但整体足够调用。

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

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

Schema 描述覆盖率已达 86%，分数线是 3；描述还补充了 max_chars 的默认值、用 start_msg/end_msg 扩量这一条件，以及 session_id 支持前缀匹配，这些在 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?

具体动作加资源：取某会话的消息，并附带过滤范围（按角色过滤、限制范围与长度）。相比 get_linked_sessions、search_sessions 这类兄弟工具，它没有明确区分，但核心目的没有歧义。

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?

清楚说明默认安全行为最多 20 条 × 1000 字 ≈ 20KB，并指出需要更多数据时显式传 start_msg/end_msg 或 max_chars 来扩大范围。这给出了明确的分页和扩量上下文，但从未说明什么时候改用 search_sessions 或 list_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 supplied, so the description must carry the behavioral burden. '统计' strongly implies a read-only, side-effect-free operation, but the description never states it is read-only or that it changes nothing. The param's connection-level memory behavior (传一次后本连接记住) lives only in the schema, not the description.

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 clauses: what is returned, then when to call it. The metric list is front-loaded and no sentence is filler.

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

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

For a zero-required-param read tool with no output schema, the enumeration of returned metrics partly substitutes for missing return documentation. The only shortfall is the absent explicit read-only statement, minor given the tool's nature.

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 single project parameter is fully documented in the schema, including the unresolved_project trigger condition. The description adds nothing about the parameter, 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 resource (本项目记忆库统计) and enumerates exactly what is measured: 会话数/状态/来源/体积/当前 scope. That distinguishes it clearly from session-level siblings like list_sessions or get_session_detail, though the verb is implied by the noun phrase 统计 rather than stated as an action.

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: 开始处理项目任务前可调用，了解记忆库规模与覆盖范围. This tells the agent when the tool is worth calling. It names no alternative or exclusion, but no sibling overlaps enough to require one.

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 entire behavioural burden. It does disclose one non-obvious trait, that 'unresolved' is a heuristic judgement rather than ground truth, but it says nothing about read-only nature, default scoping (current session vs. all sessions), ordering, or what an empty result means.

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 short sentence with no filler, so it is concise, but it is under-specified rather than efficient — the heuristic caveat is worth keeping, yet the sentence spends its only clause on it and never establishes the action or scope.

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, half-documented parameters, and a session-scoping question left unanswered, the definition is not sufficient for an agent to call this tool confidently. The heuristic caveat is a good start but leaves most of the operational picture missing.

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

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

Schema coverage is only 50%, and the description adds no parameter information at all. `limit` is undocumented in both schema and description (no default, no max, no semantics), and while `project` has a schema description, the description does not reinforce or explain how scoping changes the results.

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 (issues raised in a session that remain unresolved) and adds a useful qualifier that resolution is heuristic, but it is a noun phrase with no verb and no differentiation from siblings such as get_decisions or search_sessions. An agent can roughly infer what it returns, yet it cannot tell confidently what it does versus the neighboring retrieval 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?

There is no statement of when to use this tool, when not to, or which sibling to prefer for resolved items, decisions, or broader session search. The only usage hint in the whole definition lives in the schema for `project` (pass it when the server signals unresolved_project), not in the description itself.

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

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

With no annotations provided, the description carries the full burden and discloses meaningful behavior: full sha256 verification, normalization to the current project, default quarantine behavior, and that quarantine imports only metadata and summaries while the body awaits release. It does not cover permissions, overwrite behavior, idempotency, or error cases, so it is strong 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 tightly written sentences with no filler. The core operation, verification step, and default quarantine behavior are front-loaded, and every clause adds useful 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 an import tool with no annotations and no output schema, the description covers the key behavioral facts an agent needs: verification, normalization, default isolation, and the metadata-only nature of quarantine imports. It stops short of explaining result structure or how the release step is performed, but the essential context is present.

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 the quarantine default and the project unresolved_project case. The description does not add parameter-level detail beyond what the schema provides, so the baseline score of 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?

Names a specific verb and resource: importing a .hop handoff package, with sha256 verification and normalization to the current project. It clearly contrasts with export_handoff by operation. It does not explicitly differentiate itself from release_quarantine or other sibling tools, 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?

The description states that AI-initiated imports default to quarantine mode and that the body awaits release. This gives useful context about the default path, but it does not explicitly say when to use this tool versus release_quarantine or when to pass quarantine=false beyond the schema note. Usage is implied rather than fully guided.

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

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

No annotations exist, so the description carries the full burden for a mutation tool. It never states whether links are reversible, whether duplicates are rejected, what permissions are needed, or what a successful link produces; only the kind semantics are explained. That leaves the agent guessing about the side effects of a write operation.

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 front-loads the core action and then enumerates the kinds without waste. It is efficient, though the parenthetical kind glosses are slightly compressed and could be marginally clearer.

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 4-param, no-annotation, no-output-schema mutation tool, the description omits the meaning of linked_ids, validation behavior, and the project-unresolved caveat (which lives only in the schema). It names the consumer tool but does not do enough to let an agent 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 coverage is 50%, and the required linked_ids has no documentation anywhere. The description does add real value by glossing the three kind values (延续/相关/挂载) that the bare enum only lists, which compensates partially but not fully for the missing linked_ids meaning.

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

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

It states a clear verb and resource ('把两个会话建立关联' = establish a link between two sessions) and points to the consumer get_linked_sessions, so an agent knows exactly what it does. It stops short of distinguishing itself from link-adjacent siblings like suggest_related_sessions, which keeps it from 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 names the downstream use ('供 get_linked_sessions 与跨会话追溯'), which implies when the tool is appropriate, and it disambiguates the three kind values. But there is no explicit when-not or comparison against alternatives like suggest_related_sessions or annotate_session.

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 add one genuine behavioral trait – that the current scope is applied to the result set – but omits pagination, default limit, ordering, and what a session record contains, which are relevant for a 9-parameter listing 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 sentence with the scope constraint front-loaded and no wasted words. It is appropriately sized, though the extreme brevity trades away useful detail rather than just trimming noise.

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-required, 9-parameter list tool with no output schema, the description is minimal: it covers purpose and scope behavior but leaves result shape, pagination, and default limit unaddressed. Adequate as a minimum-viable definition but with clear gaps.

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 89%, so the inline parameter docs already explain tag, file, since, until, state, topic, and source. The description adds no parameter-level detail beyond the schema; '(scope 生效)' loosely relates to the project param but does not elaborate. Baseline 3 when 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?

States a clear verb ('列出'/list) and resource ('本项目会话'/this project's sessions) with a filtering scope. However, it does not distinguish itself from the sibling search_sessions, so an agent cannot tell the two apart 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?

'按过滤条件列出' implies a filtered-listing use case, and the '(scope 生效)' note hints at interaction with set_scope, giving implied usage context. But there is no explicit when-to-use vs when-not, and no mention of the search_sessions alternative for broader queries.

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 two things that are not in the schema. First, it is a mutation that writes content into the store (入库). Second, it requires prior user confirmation. However, it says nothing about whether release is reversible, what happens to the quarantine entry afterward, or what happens if no session matches the prefix.

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 definition is a single compact sentence with the action front-loaded and the key constraint attached in parentheses. It wastes no words, though it is on the thin side for a mutation tool.

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 write tool with no annotations and no output schema, the description is too sparse. It omits the ambiguous-match behavior, which the prefix parameter makes likely; the failure modes; and the effect on the quarantine state. The schema hints that resolved project context may be required, but the description does not explain this.

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

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

Schema coverage is only 50%, and the description does not mention either parameter. The 'project' parameter is documented in the schema. But 'session_id_prefix' has no description anywhere, so the agent must guess whether the tool accepts a prefix, a match rule for multiple matches, and whether it is exact. The description does not compensate for this 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 names a specific action on a specific resource: it releases the body text of quarantined imported sessions into the library (放行入库). This is distinguishable from its siblings (import_handoff, export_handoff, list_sessions), which neither quarantine nor release content. However, it does not explicitly connect the tool to the 'quarantine' concept it shares with the import flow, beyond the words 隔离导入.

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 '(用户确认后使用)' gives a concrete usage hint: call only after the user has confirmed. It does not say when not to use it, what the state before release must be, or how it relates to import_handoff. Therefore, usage is only implied.

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 the behavioral burden, and it does disclose real side effects: the note is immediately confirmed and extracted, and decision sentences are routed into the decision library. However, it says nothing about permissions, whether writes are reversible, or what the response looks like, leaving meaningful behavioral gaps 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?

The definition is a single compact sentence front-loaded with the core action, with details in a parenthetical. Little waste, though the parenthetical packs several distinct facts (source, origin, confirmation, extraction) that would read better as separate clauses.

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

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

For a mutation tool with no annotations, no output schema, and only 25% schema coverage, the description should cover return behavior and the undocumented parameters. It explains extraction side effects but leaves the response format and most parameters unexplained, so an agent cannot fully predict outcomes.

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

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

Schema description coverage is only 25%; the title, content, and tags parameters have no descriptive meaning in either the schema or the description. The description's remark that decision sentences go to the decision library is a faint hint about what content should contain, but it does not compensate for the undocumented parameters.

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 (写入结论/备忘 into 项目记忆) and pins down source=note, origin=manual, making the action unambiguous. It does not explicitly distinguish itself from note-adjacent siblings like annotate_session or get_decisions, but the writing purpose is clear enough for an agent to select it.

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 by '把结论/备忘写入项目记忆' – the agent can infer this is for recording conclusions/memos, but there is no explicit when-to-use vs when-not, nor any pointer to an alternative tool. The note that decision sentences 'directly enter the decision library' hints at a relationship with get_decisions but does not frame it 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?

No annotations are provided, so the description must explain what the tool does when called. The verb "搜索" implies a safe read, and the project-scope statement clarifies what it covers. However, the description never states whether results are ranked or capped, whether it is paginated, or how results are returned, and it doesn't mention any cost or latency traits.

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 is stated first, followed by the clearly labeled 何时用 and 何时不调 blocks; there is no filler. The trigger lists are somewhat long, but each item is a distinct, usable signal, so 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 nine-parameter search tool with no output schema, the description explains invocation but not what comes back, so the agent can't anticipate result shape, snippet content, or ranking. Parameter documentation is left almost entirely to the schema; because coverage is high, that is acceptable, but the missing return-value guidance leaves a real 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 description coverage is 89%, so the schema already documents nearly all nine parameters, including the tricky project fallback behavior; this establishes a baseline of 3. The description adds no parameter-level detail (query syntax, filter combination semantics) beyond what the schema says, but it doesn't need to.

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 ("搜索本项目的历史会话记忆") and scopes it to the current project up front. It doesn't explicitly contrast itself with the sibling tools list_sessions or get_decisions, so an agent reading only the description must infer whether a scope-based list or a decision lookup would be better.

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

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

The description gives an explicit list of trigger conditions (the user says "之前/上次/为什么当时/我们讨论过吗", project onboarding, confirming a prior decision, and troubleshooting) and an explicit list of when not to call it (pure new questions, or content from the current conversation). This is exactly the when/when-not structure that makes tool selection unambiguous.

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 mode "full" disables clipping and that privacy ignores are never bypassed, which is real behavioral context. It does not disclose the persistence model of the new scope (per-connection? until reset?) or whether it is a mutating call, which matters for a state-changing 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 sentence, front-loaded with the triggering situation before the two actions it performs. Nothing is padded, though the terseness borders on cryptic for a tool with an unexplained enum member.

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 3-parameter, nested-object, unannotated, output-schema-less tool, the description covers purpose and the key privacy invariant but leaves the mode enum and filter semantics under-described. An agent could call it but would likely guess at 'predicate' mode.

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 33%, so the description must compensate. It explains only the 'full' enum value; the 'predicate' mode is left undefined, and the six filter sub-fields are summarized merely as '新过滤条件' without semantics such as date format for since/until or what files/sources accept. Partial compensation for a low-coverage 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 identifies the tool as a relaxation/escape-hatch for retrieval scope, with two concrete effects: mode "full" removes clipping, or new filter conditions are set. That is a specific verb+resource, though it never plainly says 'this sets the scope used by subsequent searches', leaving the agent to infer the resource from the name and title.

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

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

'收得太紧时的放宽通道' gives a clear triggering condition: use it when results are being over-trimmed. It also names a hard exclusion ('隐私 ignore 永不受影响'), but it does not point to any sibling (e.g. search_sessions) as the alternative when the scope is already fine.

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 discloses that recommendations are algorithmic rather than explicit links and are navigation hints only, not authoritative content. This is useful trust and accuracy context, but it does not cover what a result contains, such as scores or reasons for relevance, or whether project scoping is required.

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 front-loaded with what the tool does and then lists when to use it, with zero filler. The Chinese phrase "何时用" device is compact and scannable, though the sentence is dense and packs three use cases plus a caveat into one line.

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 recommendation tool with no output schema and no annotations, the description covers purpose, triggers, and result trust level. It could say more about what a recommendation entry contains, but nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 100%, so limit, project, and session_id are already documented in the schema, including the prefix support for session_id and the unresolved_project trigger for project. The description only implies that session_id is the anchor and adds no syntax or format detail beyond the schema. Therefore, the baseline of 3 is appropriate.

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

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

The description names a specific verb and resource: recommending related historical sessions for a given session. The key differentiator, "算法发现，非显式关联", explicitly distinguishes it from link_sessions and get_linked_sessions if those tools return user-created explicit links, so an agent can tell the two apart 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?

It names three concrete use cases: browsing a session to find related discussions, finding attachable history before starting a new session, and finding leads through a session when keywords cannot be recalled. The implicit contrast is against keyword search. The caveat that content is authoritative via get_session_detail also tells the agent what not to use this tool for.

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