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

With no annotations provided, the description carries the full burden of disclosure. It does usefully enumerate the returned metrics (total count, time range, source distribution, pending/failed counts, site totals), which tells the agent what data to expect. However, it does not state whether the operation is read-only vs. side-effectful, nor does it clarify the meaning of 待抓取/失败 (pending/failed) which implies crawling activity that may relate to update_corpus.

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 the core concept (语料库覆盖情况) front-loaded, followed by a concrete metric enumeration. It is efficient with no filler. Slightly dense without grouping or punctuation breaks between the five listed items, but appropriately sized for a parameterless stats 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 zero-parameter tool with no output schema, the description provides sufficient coverage: it enumerates exactly what statistics the agent will receive. The main weaknesses are the vague '对比' and the unexplained pending/failed statuses, which would benefit from a note that this reflects background crawler state, but overall the agent can decide to call 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?

The tool has zero parameters and an empty input schema, so the baseline of 4 applies. There is no parameter meaning the description needs to add, and the lack of argument documentation is not a gap here.

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

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

The description states a clear purpose: reporting corpus coverage (总篇数/time range/来源分布/待抓取-失败数/站点总数). It names the resource (corpus) and a specific set of metrics, distinguishing it from retrieval tools like list_articles, search, and get_article, which return article-level data rather than aggregate statistics. It loses a point because the trailing '对比' (comparison) is vague about what baseline the site totals are compared against.

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

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

No guidance is given on when to use this tool versus alternatives. It does not explicitly frame itself as the corpus-level overview choice, nor does it mention that list_articles or search are for specific article retrieval. The metric list implies an analytics use case, but the agent must infer this rather than being told.

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 bears the full disclosure burden. It does add one valuable behavioral detail — the truncation rule when max_chars>0 — which is genuinely beyond what the schema states. However, it never explicitly declares the read-only nature of the operation or describes the response shape, so the disclosure is partial.

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

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

A single sentence with zero filler, front-loading the core purpose first and the parameter behavior second. Every clause earns its place and the content is immediately scannable.

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 low-complexity two-parameter read tool this is largely sufficient: purpose and truncation behavior are stated. The gaps are that no output schema exists, so the agent cannot know which metadata fields return, and the description does not define the max_chars=0 meaning. These are minor for the typical call pattern but not fully covered.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It adds real meaning for max_chars by explaining the truncation condition, which the schema's bare 'default: 0' does not convey. However, it leaves the zero/default case ambiguous (does max_chars=0 mean full text?) and does not clarify what fields constitute 'metadata', leaving article_id semantics implicit.

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 ('取' - get/fetch), a specific resource (an article by id), and a specific scope ('完整元数据与全文' - complete metadata and full text). This clearly distinguishes it from siblings like list_articles (which retrieves collections, not single articles) and search (which queries rather than fetches by ID).

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 context on when to use this tool versus its siblings. It does not mention that retrieval by ID is the right choice when a specific article pointer already exists, nor does it contrast with search or list_articles. An agent must infer the appropriate usage from the name alone.

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 the core behavior — matching paragraphs plus a window of context and paragraph numbering — and the verbatim-quoting requirement. However, it does not disclose what happens on no match, whether the operation is purely read-only, or any rate/effort limits, which would be more material given zero 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 sentences, zero filler. The core purpose is front-loaded, and the quoting requirement is appended as a tight second sentence that earns its place. No redundant restating of the tool name or schema.

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 moderate-complexity tool (3 params, 2 required) with no output schema and no annotations, the description covers the essential call semantics: what is returned, how it is structured (paragraphs + window, with numbers), and when to use it for quoting. The only gaps are edge-case behaviors like no-match handling, which are non-critical for a straightforward close-reading operation.

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 explains the semantic of 'window' (the before/after context range) and 'query' (the matching basis for paragraphs); article_id is implied by '该文章'. This partially compensates for the missing schema docs, but it does not spell out window bounds, the query format, or the interaction between window and the returned segment count.

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 ('returns paragraphs that hit the query in a single article') with a clear resource (article_id) and an explicit window-context behavior with paragraph numbers. The phrase '单篇精读' (single-article close reading) and the mention of get_article's returned text distinguish it from the full-article sibling, though it never names a sibling outright.

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

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

The second sentence gives actionable guidance: when verbatim quoting is required, copy the text from here or from get_article. This implies a usage context (close reading/quoting vs. search or list_articles) but provides no explicit when-to-use vs. when-not-to-use guidance relative to the search or get_article siblings that overlap with it.

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 must carry the burden of behavioral disclosure. It does disclose that the tool does not perform full-text matching, which is useful, but it fails to mention whether results include article content or just metadata, how pagination works, or any performance implications. For a tool with 7 parameters and no output schema, this is a significant gap.

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 that front-loads the primary purpose and key filters. There is no redundancy or filler; every word contributes to the meaning. This is exemplary conciseness, even if the brevity sacrifices detail 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?

Given the tool's complexity (7 parameters, no schema descriptions, no output schema) and the need to understand what results are returned, the description is far from complete. It does not explain the output format, pagination semantics, or any expectations for date input. An agent would have to make many assumptions to invoke this tool 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 for understanding the 7 parameters. It mentions time, source, and title substring, which maps to date_from/date_to, source, and title_contains, but omits limit, offset, and newest_first, and does not explain date formats or default behaviors. This is insufficient to guide correct parameter usage without further inference.

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

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

The description clearly states the tool lists articles from a corpus, filtered by time, source, and title substring. It explicitly notes it does not do full-text matching, which differentiates it from the sibling 'search' tool. This is specific enough for an agent to understand the core function.

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 '浏览用' (for browsing) and the exclusion of full-text matching provide clear when-to-use guidance. It implies that for full-text search, the 'search' tool should be used instead, which effectively distinguishes it from the sibling. However, it does not explicitly name alternatives or edge cases, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden and delivers richly: it discloses time-bucket zero-filling (disappearance itself a signal), the per100 saturation at 100 for high-frequency words, and the noise caveat for small buckets (n<20). These are exactly the behavioral traits an agent needs to interpret results correctly and are beyond anything in the 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?

The core purpose and metrics are front-loaded, with caveats stacked afterward. Every sentence earns its place — saturation, noise, and zero-fill are all load-bearing. It is dense and slightly long, with several warnings packed together, but efficiency is strong overall.

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 no output schema and no annotations, the description covers the essential semantics well: metrics, saturation, noise, zero-fill, and a usage example. The main gap is that the return/output format is never described, and the granularity parameter's accepted values are unstated. Still, an agent can likely call this correctly for its core use.

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. It illustrates the 'phrases' parameter with concrete contrast examples (高质量发展 vs 高速增长) and clarifies time-bucket semantics, partially compensating. However, the 'granularity' parameter (default year) is never mentioned in the description, so one of two params remains undocumented beyond the 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 states a specific verb+resource: it computes per-phrase trend metrics (coverage articles/per100 and intensity per10k_chars) across time buckets. This is clearly distinct from siblings like search or get_article, which retrieve content rather than aggregate temporal signal. The CMP methodology framing further sharpens what the tool produces.

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 concrete recommended use case — '适合对比同义/竞争提法' (suitable for comparing synonymous/competing phrases) with an explicit example. However, it never names alternative tools or states exclusions, so an agent must infer when this beats a sibling like topic_timeline. Guidance exists but is implied rather than explicit.

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 discloses the scanning logic, limits, flags (baseline_thin), and the meaning of baseline_count, but does not state whether the tool is read-only or has side effects. The absence of any read-only/safety disclosure is a notable gap for a query-like 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 description is a single dense paragraph that front-loads the purpose and then details the logic. It is appropriately sized, though jargon-heavy, and every sentence adds functional value.

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 covers the tool's purpose, parameters, and output flags, but it does not specify the output format beyond the baseline_thin flag, nor how top affects results. For a specialized tool without an output schema, this is a moderate 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 coverage is 0%, so the description must compensate. It explains days and baseline_days (including upper limits) and references baseline_count, but does not explain the top parameter or its role. It adds partial meaning but misses one of three 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 clearly states the tool identifies new formulations that have warmed up or appeared recently relative to a baseline period, and it mentions the use case (prediction signal scanning). It is specific enough to distinguish from generic search, though it lacks an explicit verb like 'retrieve' or 'scan'.

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 a clear context ('used for signal scanning before prediction') but does not explicitly state when to use this tool instead of siblings like phrase_trend or search. No exclusions or alternative routing guidance is given.

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 — and it delivers: it discloses multi-word query semantics (space-separated, mode=and requires all / or requires any, including the synonym-set use case), date format constraints (YYYY-MM-DD), substring matching behavior for source, the three ordering values, and the output fields (id, title, date, source, snippets). This is substantial behavioral disclosure for a search 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 dense paragraph that front-loads the core purpose before adding parameter semantics. Every sentence adds value — no filler or repetition. It could be lightly reorganized, but it is efficient and skimmable 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?

With 7 parameters, no output schema, and no annotations, the description is notably complete: it specifies the return shape (id, title, date, source, snippets) and explains most parameter formats and options. The sole omission is the limit parameter's default/behavior, a minor gap relative to how well the rest of the contract is disclosed.

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 it covers 6 of 7 parameters: query (space-separated multi-word), mode (and/or meaning), date_from/date_to (format), source (substring semantics), and order (allowed values). Only the limit parameter receives no semantic explanation. This goes well beyond the schema's bare defaults to add real 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?

The description states a clear purpose — full-text search over the corpus (全文检索语料库) — with a specific verb and resource. It details the search mechanics (multi-word queries, and/or modes) which separates it from siblings like list_articles (listing) and get_article (single retrieval). It lacks an explicit named sibling differentiation, 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?

Usage context is implied through mechanics: query syntax, date filters, source substring, and ordering options suggest when one would invoke it. However, the description never names alternatives or states when not to use it versus the eight siblings (e.g., list_articles for unfiltered listing, topic_timeline for temporal analysis). No explicit exclusion or routing guidance is given.

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 full burden of behavioral disclosure. It indicates the operation is a read/retrieve ('返回'), implying non-destructive, but it never explicitly states it does not modify data or that it is safe. It also doesn't mention authorization or side effects. Given the absence of annotations, the description is adequate but not thorough.

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 sentences long and packs a lot of information efficiently. It front-loads the core purpose and then adds usage advice. No unnecessary words or repetition, though the phrase '主题证据时间线' partly repeats the tool name. Overall, it is concise and well-structured.

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 3 parameters, no output schema, and no annotations. The description explains the general purpose but omits critical details like what the 'query' should contain (a topic presumably), the exact return format (beyond '若干篇含片段'), and how results are ordered. Without an output schema, the agent has no idea what the response structure will be, making it insufficient for reliable invocation.

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

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

The schema description coverage is 0%, so the description must compensate for all parameters. It mentions 'year/quarter/month' which implicitly refers to the 'granularity' parameter, but it does not explain 'query' or 'per_bucket'. The word '若干篇' hints at 'per_bucket' but without naming it. The description leaves most parameter meanings undocumented, making it hard for an agent to know exactly what inputs to provide.

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

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

The description clearly states the tool returns a topic timeline bucketed by year/quarter/month with relevant articles and snippets, for tracking evolution of a topic. It specifies the verb (returns), the resource (topic timeline), and the intended use case. It also hints at differentiating from siblings like 'search' by being the first step for research.

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 explicitly recommends using this tool first when researching a specific scenario or question ('先用这个建立证据骨架'), providing clear context for when to use it. However, it does not mention when to avoid it or name alternative tools (e.g., 'phrase_trend' for trend analysis). The guidance is present but lacks exclusion criteria.

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 adds useful behavioral context: full mode is slow, and it discloses return value ('返回本次新增与当前库存统计'). However, it does not address side effects (articles written to DB), rate limits, or reversibility, which matter for a tool that mutates a corpus. It covers some traits but not enough for zero-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?

Three compact sentences with zero filler; the primary purpose is front-loaded before the mode caveat. Slightly terse but efficient—every clause earns its place given there are only two parameters to cover.

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

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

For a two-parameter tool with no annotations and no output schema, the description covers purpose, mode distinction, time-cost, and a return summary. The notable gap is max_articles, which has no explanation anywhere, and the return-value description is vague ('本次新增与当前库存统计' leaves the stats format unspecified). Adequate but not 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 compensate. It explains the full parameter clearly (re-walks the entire list, slow, initial-setup-only), which is valuable. But max_articles (an integer with default 300, presumably a safety cap on batch size) is never mentioned, leaving a second parameter effectively undocumented at zero schema coverage.

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

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

The description opens with a precise verb+resource+scope: '增量抓取:发现并抓取数据库尚未收录的最新文章' (incremental fetch: discover and fetch the latest articles not yet cataloged). It clearly distinguishes the fetching/mutation role from the read-oriented siblings (search, get_article, list_articles, corpus_stats), so an agent can tell them apart immediately.

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 clear mode-selection guidance: it marks full=True as only-for-initial-setup/proofreading and explicitly warns it is time-consuming ('仅初建/校对用,耗时长'), which tells the agent when to avoid it. It does not explicitly name sibling alternatives or state when-not-to-use, but the context for the two modes is substantive and actionable.

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