TrendHub

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false. The description adds context by listing the aggregated signal types and implying a one-shot composite operation. However, it does not disclose output structure, data freshness, or any operational behavior beyond the annotation-covered safety profile.

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 sentence with no filler. It efficiently lists the many signals included in the package, making the scope clear. Slightly better structural separation (e.g., listing output items as bullets) could improve readability, but it is appropriately concise.

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 tool with no output schema, the description partially compensates by enumerating what the result contains (cross-platform resonance, trend curves, related terms, future signals, etc.). However, it lacks details on the output format or how these components are structured, which could leave an agent uncertain about how to parse the response.

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

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

Schema description coverage is 100%, so parameters (keyword, geo, timeframe) are fully documented in the schema. The description does not add any parameter-specific meaning beyond what the schema already provides, meeting the baseline for full coverage.

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

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

The description clearly identifies the tool as a comprehensive topic intelligence package that aggregates multiple data dimensions (cross-platform resonance, search trends, related words, future signals, etc.). This distinguishes it from sibling tools that focus on single aspects, though it does not explicitly name any sibling or contrast itself with them.

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 provided about when to use this tool versus alternatives. The statement '供大模型做定性/阶段判断/机会风险分析' gives a general use case, but it does not mention any sibling tools, exclusions, or selection 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?

Annotations already establish read-only and non-destructive behavior. The description adds meaningful behavior beyond annotations: it compares local earliest hit to user-provided reference_time, and explicitly states that TrendHub will not fabricate baseline times, so the agent understands the provenance requirement and the benchmark logic.

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 compact, front-loaded with the tool's purpose in the first phrase, and every sentence adds information. It gives the core algorithm, the ground-truth constraint, and the output intention without 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?

For a read-only benchmark tool with rich annotations and 100% schema coverage, the description explains the core comparison and threshold behavior well. It lacks an explicit output format description, but stating that it calculates whether discovery happened 24h/72h early gives the agent enough intent to inspect return data; with no output schema this is a minor 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 100%, so a baseline of 3 applies, but the description adds crucial semantics for reference_time: it must be a genuine external ground truth, not derived from TrendHub data. It also clarifies that platforms is optional and defaults to core platforms, while the schema already handles format details.

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 specifies a concrete action ('benchmark', 'compare', 'calculate') and a well-defined resource: TrendHub local historical earliest hit versus user-provided external reference_time. It clearly differentiates from siblings like keyword_trend_curve or discover_trending_topics by framing this as a lead-time benchmark with externally provided ground truth, plus the explicit 24h/72h thresholds.

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 context for when this tool is appropriate: the user has an external ground-truth reference_time and wants to evaluate 24h/72h discovery lead-time. It imposes a strong prerequisite (reference_time must come from official announcements, mainstream outbreak points, or team-agreed ground truth), but it does not explicitly name alternatives or state when not to use this tool.

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 the safety profile is known. The description adds that the analysis is of 'current' (当前) cross-platform rankings and mentions the resonance score, which is a behavioral detail beyond the annotations. However, it does not disclose any potential limitations or side effects beyond what annotations cover, so it does not add substantial behavioral context.

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 with no redundancy. The core purpose and output are front-loaded, and every word contributes to understanding. It is efficient 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?

For a read-only tool with a simple parameter set, the description explains what it returns (per-platform hits, best ranking, resonance score) and its purpose. It is complete enough for an agent to call it correctly, though it does not specify which platforms are available (likely covered by list_platforms) or any edge cases.

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

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

Schema coverage is 100% with both keyword and platforms described. The description does not add extra meaning beyond the schema, such as format or constraints, so it stays at the baseline for high 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 clearly states the tool's function: analyzing a keyword/topic across platforms to determine cross-platform resonance. It specifies the resource (keyword/topic) and the action (analyze how many platforms it ranks on simultaneously), and it distinguishes from siblings like keyword_trend_curve (single-platform trend) and get_trending (generic trending) by focusing on cross-platform resonance and its output (per-platform hits, best ranking, resonance score).

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 use case: to judge if a topic has nationwide heat, which implies when to use it (when cross-platform visibility matters). However, it does not explicitly mention alternatives or when not to use it, though the purpose and the sibling list make the distinction reasonably inferable.

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 openWorldHint=true, indicating safe read-only external access. The description adds that results are raw clusters requiring LLM review and summarization, which is useful behavioral context. However, it does not disclose limitations like potential noise, data source specifics, or rate limits. Given annotations cover safety, this is acceptable 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?

The description is a single sentence that front-loads the key differentiator (no keywords needed) and states the core function. It is efficient and avoids redundancy, though it could be slightly more structured with a clearer separation of method and output expectation.

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 tool with two optional parameters and no output schema, the description explains the method (title similarity clustering) and notes the output requires LLM review, which gives the agent an idea of what to expect. However, it does not describe the format or granularity of the returned topics, nor does it mention any integration with siblings like cross_platform_overlap. This is 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 100%, so both parameters (platforms and min_platforms) are already documented in the schema. The description does not add extra meaning beyond implying multi-platform aggregation. Since the schema handles parameter documentation, a baseline of 3 is appropriate; the description adds no further value 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 clearly states the tool's purpose: automatically cluster and discover topics resonating across multiple platforms without requiring keywords, using title similarity. It also notes the output requires LLM review. It distinguishes from keyword-based tools like keyword_trend_curve by emphasizing '无需关键词', but does not explicitly differentiate from cross_platform_overlap which likely overlaps in 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 description implies the tool is used when no specific keywords are available, suggesting it is for broad discovery rather than targeted queries. However, it does not explicitly name alternative tools or provide conditions for when to choose this over cross_platform_overlap or get_trending. The guidance 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds value beyond annotations by specifying the tool returns raw article material only and performs no trend judgment itself, plus the aggregation-of-latest-articles behavior. This boundary is genuinely useful context that annotations alone would not convey.

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 with zero filler: the aggregation purpose and filtering capability are front-loaded, and the behavioral boundary about caller-side trend judgment closes the description. 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?

The tool is a low-complexity read-only aggregator with three optional parameters and a supporting sibling (list_categories) referenced in the schema, which keeps the burden modest. However, there is no output schema and the description does not hint at the return shape or the limit parameter's semantics, so an agent still has uncertainty about what the response looks like. 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 67%: keyword and category are documented in the schema, but limit is not. The description mentions filtering by category/keyword, largely repeating schema info, while adding the source-domain context (tech/AI/business/marketing) that clarifies what categories may contain. It does not compensate for the undocumented limit parameter or add format-level detail 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 and resource: aggregate latest articles from high-quality tech/AI/business/marketing sources as future trend signal material, with category/keyword filtering. It also draws a boundary by noting trend judgment is left to the calling model, which implicitly separates it from analysis-oriented siblings like trend_intelligence and discover_trending_topics. However, no sibling is named explicitly, so differentiation is left somewhat to inference.

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 implies the tool is for raw signal gathering when the caller wants to perform its own trend judgment, which gives some usage context. It does not name alternatives or state when not to use this tool versus any of the 18 siblings such as get_trending or discover_trending_topics. An agent choosing among the large sibling set receives no explicit routing 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?

Annotations already signal readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: it aggregates multiple evidence types, matches templates, outputs both filling guidance and a productionPrompt, and explicitly does not produce the finished script/copy/plan.

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 with no filler. The core purpose is front-loaded ('专家创作简报'), the aggregation scope is listed compactly, and the boundary condition about who completes the final draft is placed at the end without repetition.

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

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

With no output schema, the description adequately explains what is returned: fill-in guidance and a productionPrompt. It also covers scope and boundary. It is slightly less complete on parameter interactions (e.g., platform vs template_id) and the exact format of the output, but for an agent deciding to call this tool, the essential information is present.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters. The description indirectly maps to topic ('围绕主题'), platform ('同平台'), and template_id ('匹配模板'), but adds no semantic detail beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description clearly states a specific verb+resource: it creates an expert brief by aggregating hot-topic evidence, search terms, sentiment signals, and viral samples, then produces fill-in guidance and a productionPrompt. It also distinguishes itself from content-generation tools by explicitly noting the final draft is done by the calling LLM.

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 context for when to use the tool: when you need a research-backed creative brief around a topic, with template matching and productionPrompt output. It implicitly excludes final-draft generation by saying that is the caller's responsibility, but it does not explicitly name alternatives or state when-not-to-use conditions.

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, and the description agrees (a read operation), so no contradiction. The description adds value by specifying what the returned structure contains, but with only one param and no side effects, there is little additional behavioral complexity to disclose.

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 zero filler, and the core purpose (fetching full template structure) is front-loaded ahead of the content breakdown. Highly efficient.

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-param tool with full schema coverage, the key facts are present: what it does and what it returns. However, it omits how to discover valid template IDs (via list_templates) and doesn't address behavior for unknown IDs, which are the main gaps an agent would face.

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

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

Schema coverage is 100% and the single parameter id is fully described with examples in the schema. The description adds no parameter-level detail beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb (获取/retrieve) and resource (模板/template) and enumerates the returned structure (sections/purpose/writing guidelines/fill-in slots/checklist), which is specific. It clearly indicates a single-template fetch, distinguishable from sibling list_templates, though it doesn't explicitly name the sibling.

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 on when to use this vs alternatives. It doesn't mention that list_templates should be used to enumerate available templates first, nor any conditions or exclusions. The usage context is left entirely 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description discloses a meaningful side-effect: each query accumulates local snapshots and bounded history for trend-change and benchmark analysis. This adds behavioral context that the annotations do not fully convey, showing state accumulation without contradicting the non-destructive flag.

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 three sentences with no filler: main purpose, query options with default behavior, and side-effect disclosure. Information is front-loaded, and every sentence 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 tool with zero required parameters, no output schema, and all parameter descriptions in the schema, the description covers the essential invocation details: parameter combinations, default case, and side effects. It does not explain return format, but with no output schema and simple optional params, the guidance is sufficient for correct agent invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value by clarifying the interaction between platform and category, including the comma-separated platform format and the fallback behavior when neither parameter is provided—details not explicit in the schema. This extra semantic guidance justifies a 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 description clearly states the tool retrieves current hot topic rankings (获取当下热点榜单), identifies the query dimensions (platform/category), and describes the default cross-platform behavior. It does not explicitly differentiate from sibling tools like discover_trending_topics, but the verb and resource are specific enough for basic distinction.

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 how to use the tool—by platform, by category, or with neither for cross-platform core rankings—but gives no explicit guidance on when to prefer this tool over alternatives such as discover_trending_topics or take_snapshot. The usage context is implied rather than directly contrasted with siblings.

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

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

Annotations already declare read-only, open-world, and non-destructive hints, so the description doesn't need to repeat these. It adds useful context about relative vs absolute values, but provides no additional behavioral details like rate limits or return format.

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 description that front-loads the core function, includes key details (data source, scale, and limit), and contains no redundant words. Excellent structure.

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 exists, but the description hints at the return type (time series, 0-100) and supports multiple keywords. It is sufficient for a simple read-only tool, though an example or more explicit return structure would improve completeness.

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

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

Schema coverage is 100%, so parameters are well-documented. The description adds a constraint not in the schema: the 1-5 keyword limit, which enriches understanding of the 'keywords' parameter.

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 function: retrieving relative popularity time series for keywords on Google Trends, with a 0-100 scale and support for 1-5 keyword comparison. This is specific enough to distinguish from some siblings, though it doesn't 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?

No guidance on when to use this tool versus alternatives. It simply describes the function without mentioning any conditions or exclusions, nor does it reference sibling tools.

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 the safety profile is established. The description adds scope about the kinds of categories, but it does not disclose behavioral traits such as return structure, pagination, completeness, or whether categories are hierarchical.

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 concise Chinese sentence with no filler, and the verb is front-loaded. It is efficient, though the repeated '分类' and the combined '平台分类与内容/模板分类' phrasing create slight ambiguity.

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 parameterless read-only list, the description is mostly adequate, but without an output schema it does not clarify the exact return format or whether the categories are returned as a flat list, tree, or mapping. Some ambiguity remains about what '平台分类' specifically refers to, and no usage context relative to sibling tools is provided.

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, so the description carries no parameter-semantics burden. With no inputs to explain, the baseline of 4 is appropriate.

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

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

The description uses a specific verb '列出' and names the resource: '平台分类与内容/模板分类' (platform categories and content/template categories). This differentiates it from sibling tools like list_platforms and list_templates by focusing on category taxonomy, though the compound phrasing leaves some ambiguity about the exact grouping.

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 about when to use this tool versus alternatives. The description merely states what the tool does and does not mention or exclude siblings such as list_platforms or list_templates, leaving the agent to infer the appropriate selection.

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 the tool read-only and non-destructive. The description adds context by specifying that it returns all supported platforms and names the returned fields (call name, Chinese name, category, data source), which is meaningful because no output schema is provided.

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 conveys the resource, scope, and output fields. Every part earns its place and the purpose is front-loaded.

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 read-only discovery tool, the description is sufficient: it names the resource, the 'all/queryable' scope, and the returned dimensions. Annotations already cover safety, and no critical calling information 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 accepts no parameters, so schema coverage is trivially 100%. The description does not need to explain parameter behavior; baseline 4 applies because there is nothing else to document.

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 action ('list all queryable hotspot platforms') and resource, then enumerates the fields returned. This clearly differentiates it from sibling tools like list_categories and list_templates, which target different resources.

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

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

No explicit when-to-use or alternatives are given, so guidance is implied: use it when the agent needs the full set of queryable platforms or platform reference data. There is no misleading information, but there are no exclusions or sibling comparisons.

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 the safe read-only nature is established. The description adds the 'built-in' scope and the template domains covered, but does not disclose return format, ordering, or how type/platform filtering behaves. No contradiction with annotations.

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 well-structured sentence with the verb and resource front-loaded. The parenthetical enumeration is long but informative and earns its place by showing exactly what template types are available.

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

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

For a simple, read-only listing tool with zero required parameters and full schema coverage, the description is largely complete. The only minor gap is that it does not clarify the relationship to get_template or describe the output, but the annotations and schema cover the safety and parameter aspects.

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

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

Schema coverage is 100%, so the parameters are fully documented in the schema. The description does not add parameter-level meaning, though its list of template categories partially hints at what type/platform values map to. Baseline 3 is appropriate.

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

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

The description uses a specific verb ('列出' / list) and clearly identifies the resource: built-in expert content templates, with a concrete enumeration of template types. This distinguishes it from siblings like get_template (retrieve one template) and list_categories/list_platforms (list metadata, not templates).

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 clearly frames this as a listing operation, so an agent can infer it is for discovering available templates. However, it does not explicitly say when to use this over get_template, nor does it mention filtering guidance or any exclusions.

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 the safety profile is covered. The description adds useful behavioral detail about the output split (top vs. rising), but it does not mention rate limits or data freshness. With annotations present, this is adequate but not richer.

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 core action and outcome, then adds usage context. Every phrase earns its place, with no redundancy or fluff.

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

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

With no output schema and no parameter descriptions, the description carries more weight. It explains the output categories (top/rising) and the primary parameter (keyword), but leaves the optional geo parameter and the exact result format unspecified. For a low-complexity tool with annotations, this is 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 explicitly clarifies the required 'keyword' parameter (the term for which related queries are fetched), but it says nothing about the optional 'geo' parameter. This is partial compensation 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 uses a specific verb ('获取'/'get') and a clear resource ('相关搜索词' for a keyword in Google Trends), and further specifies the two output categories (top and rising). This immediately conveys the tool's function and naturally distinguishes it from siblings like keyword_trend_curve or get_trending.

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

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

The description states a clear application context: '用于选题与 SEO/搜索流量' (for topic selection and SEO/search traffic). It does not explicitly name alternatives or provide exclusions, but it tells the agent when this tool is appropriate.

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?

The description discloses key behavioral traits: default is read-only local observation, refresh=true triggers a real network refresh, and it covers specific reliability dimensions. The annotations already indicate openWorldHint=true and destructiveHint=false, and the description adds context about what 'refresh' does and what metrics are computed. It doesn't contradict annotations. It could add more about side effects of refresh (e.g., rate limits, cost), but the core behavior is transparent.

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 sentence that front-loads the core purpose (quantifying data source stability) and then lists the specific metrics. The second sentence clearly explains the two modes. Every part earns its place, and the structure is efficient for an agent to parse.

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 (multiple statuses, rates, latency percentiles, schema drift signals) and the absence of an output schema, the description provides a solid overview of what the tool returns. It also clarifies the refresh behavior. It could be more complete by describing the output format or how to interpret the metrics, but for a monitoring tool with clear parameters, it's largely sufficient.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (refresh and platforms). The description adds context by explaining the default behavior (read-only local) and that refresh=true triggers a real refresh, which aligns with the refresh parameter. It also mentions '指定平台' (specified platforms) which maps to the platforms parameter. However, it doesn't add much beyond the schema's descriptions, so baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: quantifying data source stability with specific metrics (UP/DEGRADED/DOWN/AUTH_REQUIRED/RATE_LIMITED, ok/usable rates, latency percentiles, consecutive failures, schema drift signals, history depth). It also distinguishes the default read-only local observation mode from the refresh=true mode. This is a specific verb+resource combination that differentiates it from sibling tools like trend analysis or content generation tools.

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

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

The description explicitly states when to use the default mode (read-only local observation) and when to use refresh=true (to perform a real refresh of specified platforms). It also mentions the platforms parameter for specifying which platforms to check. However, it doesn't explicitly name alternatives or exclusions among siblings, though the tool's unique focus on source reliability makes the usage context clear.

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 indicate readOnlyHint=false, openWorldHint=true, and destructiveHint=false. The description adds that it takes a snapshot, implying a write operation and external interaction, but does not elaborate on side effects, data persistence, or network calls. It does not contradict annotations, so no flag, but adds limited extra disclosure beyond what annotations provide.

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 sentence, front-loaded with the primary action and purpose. It is concise and free of fluff. The additional note about scheduled use is useful and placed at the end, maintaining efficiency.

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

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

For a simple tool with one optional parameter and no output schema, the description covers the core purpose and scheduling context. However, it omits details about what the snapshot actually captures, what is returned (if anything), and any side effects or prerequisites. Annotations provide some safety profile but not return behavior. This is 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 coverage is 100% with a description for the 'platforms' parameter (optional, comma-separated). The tool description does not add any additional meaning beyond that. Since schema fully documents the parameter, the baseline of 3 applies.

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

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

The description clearly states the action: take a historical snapshot of platforms. It is specific about the resource (platforms) and the action (snapshot). However, it does not explicitly differentiate itself from sibling tools, though the snapshot concept is distinct from analysis or trending tools.

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

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

The description mentions two usage modes: immediate manual invocation and scheduled system calls for continuous monitoring. This gives some context but does not provide explicit alternatives or when-not-to-use conditions. It does not compare to other tools like discover_trending_topics or get_trending.

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 the safety profile is covered. The description adds behavioral context beyond this: it reveals the tool compares historical snapshots, outputs three categories of change, and depends on prior snapshot accumulation. No contradiction exists.

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 core function and immediately follows with the prerequisite. Every word adds value; there is no redundancy or filler.

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

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

For a read-only analysis tool with one optional parameter and rich annotations, this description is complete: it states what the tool does, what inputs are needed (implicitly the platform param), and the precondition. No output schema is present, but the output categories are clearly enumerated, so the agent can anticipate the return shape.

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

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

Only one parameter exists (platforms) and the schema description covers it fully ('可选，限定平台，逗号分隔；默认核心平台'). The tool description adds no additional meaning about this parameter, so the baseline of 3 for 100% schema coverage is appropriate.

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

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

The description explicitly states the tool compares historical snapshots and outputs newly listed, ranked-up (≥3 positions), and dropped-off topics per platform. The verb '对比' (compare) plus specific output categories clearly distinguishes it from siblings like get_trending (current list) and take_snapshot (capture a snapshot).

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

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

Provides an explicit precondition: at least two snapshots are required, and it names the alternative paths to obtain them ('get_trending 会自动积累，或用 take_snapshot'). This directly tells an agent when to use this tool and which sibling tools to call first if the condition isn't met.

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?

The annotations are sparse (readOnlyHint=false, openWorldHint=true, destructiveHint=false), so the description adds meaningful behavioral context: it refreshes the current core platform by default and explicitly returns insufficient_history when historical data is lacking. This goes beyond the annotations, although it does not fully explain side effects of the refresh operation.

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

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

The description is a single dense sentence that packs in the computed metrics, default behavior, and error condition without excessive verbosity. It could be slightly better structured with clearer separation of inputs, outputs, and behavior, but it is efficient and each clause contributes useful information.

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

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

With no output schema and only sparse annotations, the description should carry more weight. It explains what metrics are computed and the insufficient_history response, but it does not describe the return structure, how to specify alternative platforms in practice, or how to interpret the computed metrics. This is adequate for a basic call but leaves gaps for an agent needing precise invocation and response expectations.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds high-level context about lifecycle and refresh defaults but does not materially expand on the meaning of keyword, refresh, or platforms beyond what the schema already states.

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 identifies a trend intelligence engine that computes lifecycle phases, ranking speed, persistence, cross-platform diffusion, source reliability, and confidence. This is specific enough to convey the tool's core purpose, but it does not explicitly differentiate it from closely related siblings like keyword_trend_curve or discover_trending_topics.

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

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

The description gives no explicit guidance on when to choose this tool over its many siblings. It mentions default refresh behavior and an insufficient_history return, but these are operational details rather than usage criteria, so an agent gets little help with tool selection.

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 cover the read-only and non-destructive behavior. The description adds that results include days-from-today and preheat level, which is useful, but it does not disclose limits, ordering, response shape, or other behavioral caveats.

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 communicates scope, output highlights, and intended use without redundant or vague wording.

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 tool with two optional parameters and no output schema, the description and schema are nearly sufficient. It explains what the query returns, though the exact result structure and default behavior beyond the schema's 'default=90' note are slightly underspecified.

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

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

Schema description coverage is 100%, so both category and days_ahead are already documented. The description does not add additional parameter-level meaning beyond implying 'N days', so the baseline of 3 applies.

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

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

The description states a specific verb and object ('查询未来 N 天的趋势节点') and enumerates concrete categories (科技展会/财报季/政策/电商大促/节假日). This clearly distinguishes it from siblings like get_trending or future_signals by focusing on dated event nodes with preheating levels.

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 implies a use case ('用于提前布局内容') but does not explicitly state when to prefer this over future_signals, get_trending, or discover_trending_topics, nor does it give exclusions or alternatives.

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 annotations, the description discloses that derived topic words are not the official hot-search ranking, that output depends on session mode, and that the official list requires XHS_COOKIE. This adds meaningful behavioral context beyond the readOnlyHint/openWorldHint/destructiveHint annotations.

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 sentence that front-loads the tool's purpose and enumerates outputs and configuration behavior. Every clause carries useful information, though the structure could be improved with bullet points for readability.

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 tool with no output schema and no required parameters, the description does a good job specifying what is returned, what is optional, and how authentication affects results. Minor gaps remain around behavior on invalid cookies or when with_hotlist is true without a cookie, but the overall context is sufficient for an agent 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?

Schema description coverage is 100%, so the baseline is 3. The description adds the XHS_COOKIE context relevant to with_hotlist, but it does not explain the numeric parameters meaningfully beyond what the schema already documents.

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 aggregates Xiaohongshu hot topics and lists the exact output components: official homepage hot-recommend notes, derived topic words, session mode, and optionally the official hot-search list. It is specific and informative, though it does not explicitly differentiate itself from sibling trend tools like get_trending or discover_trending_topics.

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 useful condition-based guidance: guests can use it with zero configuration, and setting XHS_COOKIE adds the official hot-search list. However, it does not say when to choose this tool over the sibling trend-related tools or specify any exclusions, leaving selection largely to inference.

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