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

With no annotations, the description carries the safety/behavior burden: it discloses the return structure and the 23:30 generation timing, which is genuinely useful behavioral context. It does not say whether the tool reads or generates, what happens for a not-yet-generated day, or any access constraints, so gaps remain.

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, front-loaded with the purpose and contents before the timing caveat; there is no filler. Slightly dense but every clause 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?

An output schema exists, so the description needn't document return values, and it correctly focuses on content scope and the 23:30 timing. Still, it omits the `day` parameter's semantics and the behavior when a summary is unavailable, leaving meaningful holes for a one-param retrieval 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 explain the single `day` parameter — its accepted format, valid values, and how the default 'yesterday' behaves. The description never mentions the parameter at all, so an agent must guess the date format from the schema's bare string type.

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 (a single day's summary) and enumerates its concrete contents (one-line overview, morning/afternoon/evening activities, todos, commitments, risks), which makes the tool's output distinguishable from siblings like `insights` or `todos`. The retrieval verb is only implied, and no sibling is named as an alternative, 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?

It provides one useful temporal constraint — today's summary is auto-generated only after 23:30 — which tells the agent when the tool is meaningful. However, it never states when to prefer this over siblings such as `insights` or `search`, nor what to expect if the summary does not yet exist, leaving usage largely inferred.

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, yet it only lists content categories. It does not state that this is a read-only lookup, what happens with an unknown or inaccessible project_id, permission requirements, or result size/pagination — leaving the agent uninformed about behavior beyond the payload shape.

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

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

It is a single front-loaded sentence with no filler; the enumerated content list earns its place by telling the agent what the payload covers. The only weakness is a slightly sprawling list of six items that blurs the primary purpose.

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?

An output schema exists, so return values needn't be spelled out, and the description does convey the breadth of the payload. But for a tool requiring an undocumented identifier with zero annotations, the absence of any input or usage information leaves a meaningful 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 0% and the single required parameter project_id is documented nowhere. The description never mentions that a project identifier is required or what form it takes, so it fails to compensate for the schema 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 characterizes the resource as a project's dossier and enumerates its contents (status, phase, risks, open questions, commitments, timeline), which makes the subject clear. However, it never states the action (retrieve a single project by ID) and offers no differentiation from siblings like get_record or list_projects, so an agent must infer that this is the per-project fetch tool.

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 get_record, list_projects, insights, or day_summary. The description implies 'use this to see a project's full picture' but never states a selecting condition or any exclusion.

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 conveys that this is a read operation that returns the record's full field set, and it lists the content types that may come back (including optional sentence-level transcripts), but it says nothing about the authorization needed to access a record, what happens when the ID is not found, or how the transcript payload is shaped.

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 two compact clauses that front-load the core action and then add ID semantics. There is no filler, though the taxonomy takes up most of the space while a more important parameter goes unmentioned.

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?

An output schema exists, so the description need not unpack return values, and the ID-prefix explanation covers the main input. The missing piece is include_transcript and the relationship to get_transcript or get_project, which an agent would need in order to choose correctly among the siblings.

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 coverage is 0%, so the description has to compensate. It does add meaningful semantics for record_id through the E/N/P prefix taxonomy, which the schema does not. However, it says nothing about include_transcript, the second parameter, even though that parameter defaults to true and overlaps with the get_transcript sibling.

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

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

The description states a specific verb and resource: fetch all fields of one record by ID, and it adds a prefix taxonomy (E/N/P) that tells the agent what kind of object each ID designates. It does not, however, separate this tool from get_transcript or get_project, even though their names suggest overlap.

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 mention of alternatives, despite sibling tools named get_transcript, list_records, and get_project. The prefix explanation implies the usage scope, but it leaves the agent to infer whether this is the right tool when the goal is a transcript or a project.

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

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

With no annotations, the description carries the full burden. It does disclose useful traits: raw (unprocessed) speech data, per-sentence time and speaker metadata, and a hard cap of 1500 sentences. It does not say what happens past 1500 (truncation vs. pagination) or how to page, which is the main behavioral gap for a bulk-retrieval 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?

Dense and front-loaded: what the tool returns comes first, then parameter semantics, then the result cap. Every clause carries information, though the '同 list_records' cross-reference is less self-contained than an inline format note would be.

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-parameter read tool with an output schema present (so return structure needn't be restated) and no annotations, the description covers purpose, all parameters, and the result cap. The remaining gaps — start/end format and overflow behavior — are real but narrow.

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 compensate, and it largely does: all four parameters are explained, with source enumerating all/mic/system/memo and what each means, and speaker given worked examples ('我', '对方'). The weakness is start/end, which are only defined by cross-reference to list_records rather than a format example.

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

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

States a concrete resource and scope: sentence-by-sentence verbatim transcript with time and speaker, explicitly 'regardless of whether it was organized into events'. That last clause implicitly separates it from the record-oriented siblings (list_records/get_record), though it never names an alternative explicitly.

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

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

Usage is only implied — the contrast with '整理成事件' suggests when raw transcript is wanted over records, but no sentence says 'use this when ... instead of get_record/list_records'. The per-filter meanings of source and speaker give operational context but not selection 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?

With no annotations, the description carries the full burden. It usefully discloses the data source (things the user said) and the output shape (each item ships with evidence and a suggestion), but says nothing about read-only semantics, freshness, or how the limit 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?

One sentence, front-loaded with the concept and then the derivation and item structure. No wasted text; the only small cost is the terse Chinese label '觉察' which is less self-explanatory than the rest.

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?

Complexity is low and an output schema exists, so return-value explanation is not required. Still, for a tool an agent must choose against memories/day_summary, the missing usage routing and undocumented limit leave it 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% and the single parameter 'limit' (default 10) is never mentioned in the description. While the parameter is fairly self-evident from its name and default, the description does nothing to compensate for the total coverage gap or clarify what is being limited.

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: weekly-derived communication and work habits extracted from the user's own speech, each with evidence and suggestions. That is far more concrete than the bare name 'insights'. It does not, however, distinguish this from siblings like memories or day_summary, which also surface derived personal 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?

There is no explicit statement of when to call this versus alternatives such as memories or day_summary, and no prerequisites or exclusions. The 'weekly' cadence hints at scope but an agent must infer the trigger condition (user asking about their own habits).

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 disclosure burden. It adds useful behavioral context by stating that projects are auto-aggregated across days and returned in most-recent-update order, but it does not explicitly say this is a read-only listing, whether it returns all projects, or what scope limitations exist.

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 no filler. It front-loads the nature of the projects and then states the sort order, 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?

For a simple zero-parameter list tool with an output schema, the description covers the key semantics: what a project is, how projects are formed, and how results are ordered. It is slightly incomplete on usage context and read-only/scope behavior, but the output schema reduces the need to describe return values.

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

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

There are zero parameters and schema description coverage is 100%, so there are no parameter semantics to explain. The baseline for a zero-parameter tool is 4.

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 name supplies the verb 'list' and the description defines the resource as cross-day auto-aggregated projects, including that related conversations are linked into one thread. It does not explicitly contrast with siblings such as get_project or list_records, so it is clear but not fully differentiated.

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 explains what projects are and that they are sorted by most recent update, but gives no explicit instruction on when to use this tool versus list_records, get_project, or other siblings. Usage is only inferable 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?

With no annotations, the description carries the full burden, and it does disclose what is returned (two record types) and the empty-end semantics. It omits ordering, result-size limits, pagination, and whether results span all projects — meaningful gaps for an unannotated 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?

Front-loaded: the what-it-lists sentence comes first, then terse per-parameter notes with no filler. The telegraphic 'start/end：… kind：…' style is efficient, though slightly dense for readers unfamiliar with the domain vocabulary.

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?

An output schema exists, so return shape is covered, and all four parameters are explained. What remains missing for an unannotated, four-parameter listing tool is behavioral context: ordering, pagination or caps, and confirmation that it is a pure read.

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 has to compensate and largely does: it gives accepted date/time formats ('2026-10-25', '2026-10-25 14:00', 'today', 'yesterday'), the meaning of an empty end, the kind enum (all/events/notes), and a graded scale for min_importance. The only miss is the start='today' default behavior and any timezone caveat.

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 opening sentence names a specific verb and two concrete resources ('全时记' auto-segmented events and '随口记' quick notes/ideas/questions/todos), scoped to a time range. An agent can tell what comes back. It stops short of naming a sibling it is *not* (search, day_summary, get_record), so the differentiation is incomplete.

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 filter semantics: narrowing by kind and raising min_importance to drop trivia suggests this is the browse/scan-the-timeline tool. But the description never says when to prefer it over search, day_summary, or get_record, and gives no exclusions or prerequisites.

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

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

There are no annotations to lean on, but the description does disclose meaningful behavior: results are facts (people, preferences, agreements, numbers) that carry sources ('带出处'), and the default empty-query behavior is stated. It does not state that the tool is read-only or clarify what happens to the results (ordering, truncation).

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, front-loaded clauses with zero waste; the resource definition comes first and the mode-specific behavior second.

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 tool has an output schema, so return shape need not be described, and the description still tells the agent what kinds of objects come back and that they carry sources. The only real gap is the unexplained `limit` and the lack of sibling routing guidance.

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. It fully explains `query` semantics ('empty returns most recent'), but `limit` is not mentioned in the description at all (only its default 50 in the schema). Half-documented parameters warrant a middling score.

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 definition names a specific resource – long-term facts extracted from events, with provenance – which is distinct from sibling tools like `search` (raw search) and `insights` (aggregated patterns). The retrieval verb is only implicit (it doesn't say 'return/list'), but 'query 留空返回最近的' makes it clear this is a retrieval tool.

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 explains one mode explicitly: empty query → return most recent. However, it never routes the agent to or away from alternatives such as `search`, `insights` or `list_records`, so selecting this tool over a sibling is left to inference.

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

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

No annotations are supplied, so the description carries the disclosure burden. It implies a read-only status query by describing what is reported (recording state, microphone, call apps, processing progress), but never explicitly states it has no side effects or how current the status snapshot is. For a zero-parameter status tool the risk is low, so this is adequate but not rich.

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 that front-loads the core question (is it recording) before the secondary facets. No filler, though it reads as a sentence fragment without an explicit action verb.

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 zero parameters and an output schema that carries the return-value detail, the description only needs to frame what the status covers, which it does. Nothing essential for invoking the tool 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; schema coverage is 100% and empty.

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 (the recorder) and enumerates what status facets are reported: whether it is recording, which microphone, which call apps, and how far processing has progressed. This clearly distinguishes it from siblings like list_records or get_record. The only weakness is that the verb is implicit rather than stated.

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

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

There is no explicit when-to-use guidance and no mention of alternatives. An agent can infer from the name and content that this is a status check, but nothing tells it when this is preferable to, say, list_records for checking recording output.

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

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

With no annotations, the description carries the full burden, and it does disclose two genuinely useful behavioral traits: Chinese queries require at least 3 characters, and matching is against 原话 (literal substring, not semantic). It also reveals the return shape (sentences plus owning event IDs). However it says nothing about whether start/end bound the search, how limit truncates results, or ranking/ordering of hits.

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 clauses, front-loaded with the search scope, then the constraint and the return format. Every phrase adds information and nothing is padded.

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?

An output schema exists, so return values need not be spelled out, and the description redundantly does so. But with no annotations and 0% schema description coverage, the missing semantics for start/end/limit leave an agent unable to narrow results by date or control result volume — a real functional gap for a search tool defaulting to 30 hits.

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 compensate, and it only covers 'query' (keyword, ≥3 Chinese chars, literal match). The three optional parameters — start, end, and limit (default 30) — are never mentioned, so an agent cannot tell from either the schema or the description whether start/end are date bounds and how they interact with the query. This is a substantial gap over a 4-parameter tool.

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 enumerates the exact corpora searched (全部原文、事件摘要、随口记), plus what comes back (命中句子带事件 ID 和事件). The generic name 'search' is rescued by this detail, and it is clearly the only keyword-search tool among list_/get_ siblings. It does not explicitly name a sibling it is not, 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?

Usage is only implied: an agent can infer 'use this to find content by keyword' versus the list_/get_ siblings that enumerate or fetch by ID. There is no explicit when-to-use/when-not statement and no mention of alternatives such as browsing via list_records or day_summary. Adequate but leaves routing to inference.

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

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

With no annotations, the description carries the burden, and it does disclose that results are aggregated from two separate note sources and include commitment metadata. It says nothing about ordering, deduplication, limits, or whether the operation is read-only, leaving meaningful behavioral gaps.

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

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

One compact sentence with the resource and the recency scope front-loaded and no filler. It is efficient, if slightly under-specified rather than padded.

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?

An output schema exists, so return values need not be described. For a simple aggregation read this is borderline adequate, but the undocumented `days` semantics and the absence of any safety or ordering context leave it short of 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 coverage is 0% for the single `days` parameter, so the description must compensate. "最近几天" loosely signals that a recency window exists, but it never ties that to the `days` parameter, its default of 7, or what the boundary means.

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 concrete resource (todos and commitments) and two specific sources (全时记 and 随口记), plus the attributes captured (who, what, when). It is clearly distinguishable from generic record tools, though it does not explicitly name a sibling to contrast with.

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 implies a recency window ("最近几天"), but offers no guidance on when to pick this over day_summary, list_records, or memories, nor any exclusions or prerequisites. An agent must infer the routing decision entirely.

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