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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the description does not need to reassert safety. It adds some value by specifying the reported content (success state, time, error messages), but it does not explain the scope of 'recent', whether it applies to a single matter or globally, or what the response looks like beyond these 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?

It is a single tight sentence with the resource front-loaded and no filler. Every element, status, time, and errors, carries 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?

This is a zero-parameter, read-only status check with no output schema, so the description must convey return content, and it does so by listing the three reported fields. The remaining gaps are minor, such as the time window of 'recent' and scope breadth.

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 has no parameters, which sets the baseline at 4; there is nothing for the description to disambiguate or compensate for.

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 (最近自动归档, the most recent automatic archiving) plus the exact attributes reported: success, timestamp, and errors. That distinguishes it from siblings like refresh_context or search_context, though it does not explicitly name an alternative.

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

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

The description conveys what it returns but gives no guidance on when an agent should call it versus other context tools, no prerequisites, and no exclusions. The usage context, such as debugging or verifying archival health, is left entirely 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?

Beyond the readOnlyHint/destructiveHint=false annotations, it discloses real behavior: lookup is by name/alias, it spans directories and AI contexts, it returns candidate options on ambiguity, and it does not demand a path from the user. These are non-obvious traits an agent could not infer from annotations or schema.

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

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

Two compact sentences with the trigger condition front-loaded and the resolution behavior second. No filler, nothing repeated from the schema or annotations.

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, single-parameter tool with no output schema, the description covers trigger, lookup key, scope, and ambiguity handling adequately. It stops short of describing what a successful match returns (matter body vs. reference), which would round it out.

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 0% and the single 'query' param has no description, so the description must compensate. It does partially by saying the key is a name or alias, but it leaves matching semantics (exact vs. fuzzy vs. natural-language phrase) unstated.

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?

Specific verb+resource: reads a 'matter' by name/alias, scoped as cross-directory and cross-AI-context. This clearly distinguishes it from list_matters (enumerate all) and create_matter, though it never names those siblings explicitly.

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

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

Gives a concrete trigger: 'when the user says continue/advance a matter, call this first.' That is a clear activation condition an agent can act on. However, it offers no explicit exclusions or 'use X instead' routing against siblings like list_matters or search_context.

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=false, destructiveHint=false, openWorldHint=false, so the mutation profile is known. The description adds nothing beyond that: no mention of what is created, whether duplicate names are rejected or matched to an existing matter, whether the call is idempotent, or what identity is 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 short sentences with the positive trigger front-loaded and the negative constraint second; nothing is padded. The brevity is genuine conciseness, though it comes at the cost of coverage elsewhere.

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 create/mutation tool with four undocumented parameters and no output schema, the description should at minimum explain the field set and duplicate-handling behavior. Given the sibling set includes relate_matters, link_context, and list_matters, an agent also needs to know this tool creates the container rather than attaching content — it must infer that.

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

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

The schema has 0% description coverage across four parameters (name, aliases, keywords, description), and the description mentions none of them — not even the required 'name'. It therefore contributes no meaning beyond the bare schema, leaving aliases/keywords semantics (e.g., are they search keys?) entirely undefined.

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 to create something when the user explicitly proposes a new matter, which combined with the tool name makes the verb+resource unambiguous. It implicitly separates itself from merging/linking siblings (relate_matters) by warning against combining matters, but never names a 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?

It gives a clear trigger condition — only when the user explicitly raises a new matter — plus an exclusion: don't guess on the user's behalf and merge two matters. What's missing is routing to the actual alternative for merging/linking (relate_matters, link_context).

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=false and destructiveHint=false, so the description's added value is the gating policy: relationships must be user-stated or evidence-backed, automatic linking may be refused, and links are many-to-many. It still doesn't say whether an existing link is replaced or duplicated when the same pair is relinked.

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

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

Two compact sentences: the first front-loads what is linked, the second the invocation policy. No filler, though the terse style means some semantics are squeezed out rather than omitted for brevity.

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 output schema, the description covers purpose and the safety/authorization policy well, but leaves required inputs such as `reason` and the confirmed/rejected `status` semantics unexplained, so an agent cannot fully populate the call from the description alone.

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

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

Schema description coverage is 0% across 5 parameters, so the description must carry the meaning. It conveys `kind` (directory/session/record/project) and `matter` implicitly, and hints at `status` via 'can reject automatic linking', but never explains the required `reason` parameter or what `target` accepts.

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 (link/associate) and enumerates the four resource kinds (directory, session, record, old project) that get attached to a matter, plus the many-to-many nature. It is distinguishable from relate_matters, which links matters to each other, though the description never names that 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?

Gives an explicit precondition: only invoke when the user has stated the relationship or evidence has been verified, and explicitly permits rejecting automatic linking. This is a clear when/when-not rule, but no alternative tool (search_context, relate_matters, remember) is named for the cases where linking is inappropriate.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description contributes nothing further: no mention of scope, ordering, whether results are names only or full matter records, or any pagination/limit behavior beyond the safety hints already given.

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 and the operation front-loaded. It is efficiently sized for a zero-parameter list tool, though its brevity leaves ambiguity rather than adding precision.

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

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

The description does state that names are returned ('名称'), which partially compensates for the missing output schema. But for a listing tool it omits result scope, ordering, and what 'shared' means, so it is only minimally complete.

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

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

The tool takes zero parameters, so per the baseline rule this scores 4. The description correctly implies no input is needed, and there are no parameters left 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?

The description gives a verb ('列出' / list) plus a resource ('共享事项名称' / shared matter names), so the basic operation is inferable. However, the qualifier '共享' (shared) is unexplained — it is unclear whether this lists all matters, only shared ones, or matters shared with the caller — and there is no explicit differentiation from siblings like create_matter or relate_matters.

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

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

There is no guidance on when to use this tool versus alternatives such as search_context or read_record, nor any stated preconditions. The agent must infer usage purely from the tool name.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real behavioral context on top: results are paginated and the tool returns the complete history rather than a truncated recent summary, which shapes how the agent should paginate and interpret output. It still omits what happens for an unknown matter and gives no sense of return shape or volume.

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

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

A single front-loaded sentence with no filler; the pagination behavior and the non-summary guarantee are both stated compactly. Slightly dense with three resource types in one clause but 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?

Given a read-only tool with three undocumented parameters and no output schema, the description covers purpose and result completeness but leaves parameter usage and return shape unexplained. Adequate to decide to call it, thin for 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 description coverage is 0%, so the description must compensate and does not. '分页' hints at limit/offset but never explains them, leaves the unusual maximum of 5 on limit undocumented, and says nothing about the required 'matter' identifier's expected format.

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 (分页查看, paginated read) and resource (a matter's historical notes, opinions, task statuses), and the trailing clause '不会只保留最近摘要' implicitly contrasts it with summary-oriented tools. It stops short of naming a sibling such as context_status or refresh_context, so the differentiation is inferable rather than explicit.

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: reach for this when you need the full history rather than a recent digest. No sibling is named and there is no when-not guidance (e.g., use search_context for keyword lookup, use read_record for structured records).

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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds a meaningful behavioral warning that historical content is untrusted material, which is useful context for handling the output, but it does not explain pagination defaults or return 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?

Two short sentences with no waste. The tool's core action is front-loaded, and the security caveat 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 read-only paginated tool with no output schema, the description covers the purpose and one important safety caveat. However, with three undocumented parameters it leaves an agent guessing about pagination semantics and limits, so it is only minimally complete.

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

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

Schema description coverage is 0%, so the description must carry the burden. It implies that 'record' is an evidence number and that pagination is involved, but it does not clarify length, offset, default page size, the maximum of 12000, or zero-based indexing.

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: paginated close reading of original records by evidence number. It is reasonably distinct from siblings like read_notes or search_context, though it does not explicitly name an alternative.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternatives are named. The pagination phrasing implies iterative reading, but an agent must infer when this tool is preferable to read_notes or search_context.

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=false and destructiveHint=false, so the safety profile is covered. The description adds the critical behavioral trait that this is asynchronous: it returns immediately and results must be fetched later via context_status. It does not say what exactly gets refreshed or whether repeated calls coalesce, but the async contract is the main missing piece and it is disclosed.

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

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

A single compact sentence with the trigger condition front-loaded, followed by the immediate-return behavior and the follow-up tool. Every clause carries information; there is no padding.

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 parameters, no output schema, and annotations covering safety, the definition supplies what an agent needs: when to trigger, that the call is fire-and-forget, and where to read the refreshed state. It is slightly thin on what 'local background refresh' actually updates, but that is a minor gap for a zero-argument trigger 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?

The tool takes zero parameters, so parameter semantics baseline is 4. The description correctly implies no arguments are needed and points to context_status for retrieving results, though it adds no further input detail because there is none to add.

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 action (request a local background refresh) and its trigger condition (when updates that just happened are needed). It also names the sibling tool context_status as the follow-up, so an agent can separate this from status-polling or search tools without opening a 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?

Explicitly says when to use it ('when you need just-occurred updates') and what to do next ('then query with context_status'). It does not state exclusions, e.g., that historical or already-indexed data should be read via search_context/read_record instead, so it stops short of a full routing rule.

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 disclose write-but-non-destructive, closed-world behavior. The description adds two things annotations cannot: it preserves source author and revision history, and it does not execute instructions contained in the file body. The guarantee about non-execution is a meaningful safety signal. It omits what happens on duplicate registration and what is 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?

A single dense sentence with the scope, the precondition, the preservation behavior, and the security note, all front-loaded. Nothing repeats the schema or the annotations, so 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?

No output schema and no annotations beyond a basic write profile, so the description needs to carry the return and edge-case behavior. It covers purpose, precondition, and safety, but does not state what is created/returned or what happens for a duplicate or unknown matter, leaving a gap for a three-required-parameter mutation 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 coverage is 0%, so the description must carry the parameter load. It implicitly covers all three: 'local Markdown project memory' maps to path, '来源作者' to author, and '属于事项' to matter. The mapping is conceptual rather than naming the fields or path format, so it stops short of fully compensating.

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 concrete verb/resource pair ('将...本地 Markdown 项目记忆接入' = connect a local Markdown project-memory source) and scopes it to files already verified as belonging to a matter. That is enough to distinguish it from sibling write tools like remember or create_matter, though it does not name those siblings directly.

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

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

The phrase '已核对属于事项' establishes a precondition (only registrations after the source has been verified as belonging to the matter), which implies when the tool applies. It offers no explicit exclusions and no comparison to alternatives such as remember or link_context, so the agent is left to infer the boundary.

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=false and destructiveHint=false, so the agent knows this is a non-destructive write. The description adds a genuine behavioral trait beyond that: the relation preserves each matter's independent context and does not merge their materials, which is consistent with destructiveHint=false. It remains silent on whether the link is directional, what happens if source/target do not exist, and what a successful call returns.

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

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

A single short sentence with no filler, and the core action is front-loaded before the qualifier about preserved context. It is efficient, though the extreme brevity comes at the cost of the missing detail noted in other dimensions.

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 three-required-parameter mutation with no output schema and no parameter documentation, the description is too thin: it does not explain the identifiers, the role of reason, or the effect of a successful call. It partially compensates by clarifying the non-merging semantics, but substantial gaps remain.

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

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

Schema description coverage is 0% and all three parameters (source, target, reason) are required, yet the description never mentions any of them. It does not say that source and target are matter identifiers or what the reason field is used for (audit trail, display, retrieval filter), leaving the agent to guess from bare property 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 states a specific verb+resource: saving an association between two matters ('保存两个事项的关联'), which is clearly a linking operation rather than a create/read/search operation. It does not, however, distinguish itself from the sibling 'link_context', which plausibly overlaps, so the sibling differentiation that would earn a 5 is absent.

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 '保留独立背景，不合并全部资料' hints at when this tool is preferable to merging, but it never names an alternative tool or gives an explicit when/when-not condition. An agent must infer the selection criteria entirely from the concept of 'not merging'.

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?

注解已表明这是一次非破坏性写入，因此基线较低。描述增加了真正有价值的行为信息：它会保留作者、证据和历史，并且同一作者、同一主题的任务会取代先前状态。但未说明对 memory、decision 和 opinion 的去重或冲突行为，而这些类型没有所述的替换规则。

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?

共有六个参数，其中 4 个必填，schema 描述覆盖率为 0%，且没有输出 schema。matter 和 body 参数，以及保留操作返回什么（记录 ID？），都未被解释，因此 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 描述覆盖率为 0%，因此描述必须承担全部解释工作。它间接解释了 kind（结论、任务、观点）、topic（同一主题）、evidence（被保留）和 status（任务状态替换），但完全未说明 matter 和 body，也未说明 evidence 是指向其他记录 ID 还是其他内容。

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?

使用具体动词（保存）和明确的资源类型（结论、任务、独立观点），与 kind 枚举相呼应。表述清晰，但未提及任何同级工具（如 create_matter、register_memory_source），因此 agent 仍需自行推断它应使用哪个工具。

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?

“保存新……”暗示了创建用法，任务替换规则指明了更新场景，但未说明何时改用 create_matter、continue_matter 或 register_memory_source，也未给出前置条件或排除情形。

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 and destructiveHint=false, so safety is covered structurally. The description adds a genuinely useful behavioral caveat: '候选结果不是已确认事实' warns that results are unconfirmed candidates and must not be treated as ground truth — meaningful context beyond the annotations. It omits return format/pagination, but that is a minor gap given the annotation coverage.

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

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

Two terse sentences with the core resource and the most important caveat front-loaded; nothing is wasted. It is efficient, though the extreme brevity contributes to underspecification of 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 3 parameters, no output schema, and 0% schema description coverage, the description is too sparse to fully equip the agent — query/limit semantics and result shape are unaddressed. The result-reliability caveat is valuable but not enough to cover the 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 0%, so the description must carry parameter meaning, but it only alludes to the `matter` filter ('可限定事项'). The `query` and `limit` parameters get no explanation of syntax, matching behavior, or default/range semantics anywhere.

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 (检索/search) and resource (历史对话/historical conversations), so the agent knows this is a search over past dialogue. It distinguishes itself reasonably from read_record/read_notes by being a search rather than a direct read, though it doesn't explicitly name alternatives.

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 '可限定事项' hints that results can be narrowed to a matter, and the caveat about candidate results implies a discovery use case. However, there is no explicit when-to-use vs when-not-to-use guidance and no named sibling alternative, leaving selection largely inferred.

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