TrendHub

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 the behavioral scope: it aggregates current and near-term signals, and implicitly excludes multi-year/brand/executive depth by pointing to professional_intelligence. It does not describe output format, rate limits, or failure cases, but annotations reduce the burden.

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 with no filler; it front-loads the package label and then lists the included signal types. The list is somewhat dense and jargon-heavy, but every part contributes to understanding the tool's scope.

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

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

For a tool with only 3 simple parameters, full schema coverage, no nested objects, and no output schema, the description gives enough context for an agent to select it and understand its aggregate nature. The phrase '节点与规则情感' is somewhat opaque, but the overall scope and the professional_intelligence alternative make the tool's boundaries clear.

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%, with keyword, geo, and timeframe each already described in the input schema. The tool description adds no param-specific meaning or constraints beyond that, so it stays at the baseline of 3.

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 't话题研究包' that aggregates multiple signal types: current resonance, search curve/momentum, related words, future signals, nodes, and rule sentiment. It names one sibling (professional_intelligence) as the alternative for more advanced needs, though it does not distinguish itself from other overlapping siblings like future_signals or related_queries.

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 tells the agent when NOT to use this tool: for multi-year lifecycle, forecast validation, brand entity analysis, or executive reports, use professional_intelligence. This provides a clear routing rule. However, it does not explicitly state when to choose analyze_topic over other siblings that cover individual components such as related_queries or future_signals.

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 mark the tool as read-only, open-world, and non-destructive. The description adds useful behavioral details beyond those: it clusters based on title similarity, reflects current topics, and produces results that need LLM review. There is no contradiction with the 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 definition is a single sentence with no filler. The key scoping information—no keywords, multi-platform resonance, automatic clustering, title-similarity method, and LLM-review requirement—is compact and 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 read-only tool with three optional parameters, the description plus schema is mostly adequate for selection and invocation. However, there is no output schema and the description does not specify the return shape or what the clustered results actually contain, leaving an agent to infer the output format.

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 three parameters. The description adds only the high-level 'no keywords required' framing and does not meaningfully extend the parameter semantics provided by 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 clearly states the tool's operation: automatically clustering and discovering topics currently resonating across multiple platforms, without requiring keywords. It adds distinctive qualifiers like 'based on title similarity' and 'needs LLM review', which help differentiate it from generic trending-topic tools, though it does not explicitly name a sibling 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 provides clear usage context: use when you have no keywords and want cross-platform resonant topics. It also warns that results require LLM review, which informs the agent about appropriate follow-up. However, it does not explicitly discuss when to choose an alternative sibling such as get_trending or cross_platform_overlap.

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 readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds behavioral context beyond annotations by clarifying that the tool returns raw article material and does not perform trend analysis itself, which is valuable for setting caller expectations.

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

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

Two short sentences, front-loaded with the core action and source scope, followed by filtering options and caller responsibility. Every sentence adds distinct value with no filler or 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?

For a read-only, optional-parameter aggregation tool, the description is largely complete: it states the input source, filtering options, and the division of labor between tool and caller. It lacks exact return-field examples and sorting/pagination details, but the absence of an output schema and the simplicity of the tool make this acceptable.

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 67%: keyword and category are described in the schema, while limit is not. The description reinforces the purpose of keyword/category filtering but adds little detail about limit behavior or how filters interact. It partially compensates for the missing limit documentation, so a 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 states a specific action (aggregate latest articles) on a specific resource (high-quality tech/AI/business/marketing sources) and mentions filtering by category/keyword. It is clear and distinct from generic siblings, though it does not explicitly name a sibling or contrast itself with one.

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 usage: gather raw future-trend signal material and let the calling LLM do trend judgment. It provides useful context for when to call it, but it does not explicitly state when not to use it or name alternative 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, openWorldHint=true, and destructiveHint=false. The description adds that it aggregates data and invokes the user's current AI to produce editable artifacts, which is a behavioral trait not covered by annotations. However, it does not disclose potential side effects (e.g., external API calls, rate limits) or the nature of the AI invocation, leaving some transparency 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?

The description is a single sentence that is not overly long, but it is somewhat run-on and abstract. It front-loads the aggregation concept but lacks a clear logical structure. It is not as concise or well-structured as it could be, though it avoids repetition and tautology.

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 output schema) and its role in producing editable artifacts, the description is inadequate. It does not explain what the output looks like, how the editable artifact is delivered, whether there are prerequisites (e.g., needing a workspace), or any limitations. An agent would not know what to expect from the return value or how to interpret results, making the description incomplete.

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 all 7 parameters are documented in the input schema. The tool description does not add any parameter-specific meaning beyond what the schema provides; it only gives a high-level overview. Since the schema already carries the load, 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 the tool aggregates real hot topic evidence, related search terms, same-platform samples, and templates, then invokes the user's current AI to produce editable artifacts in the content workbench. This is a specific verb-resource-outcome combination that distinguishes it from siblings like related_queries or get_template, which focus on individual components. The mention of 'editable artifacts' is a unique differentiator.

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 provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or scenarios where a sibling tool would be more appropriate. An agent would have to infer the use case from the description alone, which is insufficient for choosing among 19 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 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?

The annotations already indicate an open-world, non-read-only operation, and the description adds the valuable detail that it also accumulates a local snapshot, implying a side effect beyond simply returning live data. This goes beyond what the annotations alone 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 dense sentences: the first states the core behavior, and the second supplies routing guidance. There is no filler or repetition of schema information.

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

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

For a simple fetch-and-snapshot tool, the description plus schema covers invocation well: purpose, alternatives, parameters, and side effect are all present. It could mention what the returned hot-list entries look like, but the output is sufficiently implied by the tool's name and purpose.

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 input schema already provides full descriptions for all three parameters, so the baseline of 3 applies. The description itself does not add parameter-level detail, but since schema coverage is 100%, this is an acceptable 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 clearly states the tool fetches current raw hot-topic rankings and accumulates local snapshots, using a specific verb and resource. It also explicitly differentiates itself from trend_intelligence and professional_intelligence, so an agent can select it correctly among siblings.

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 an explicit usage trigger: use when the user asks 'what's hot now'. It also names two alternative tools and the conditions that should route to each, making the when-to-use versus when-not-to-use decision unambiguous.

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

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

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?

Beyond the annotations, the description discloses a concrete methodology: proactive retrieval of public evidence, lifecycle analysis, source reliability, evidence truth state, anomaly detection, validation predictions, media/audience analysis, opportunity/risk assessment, and executive reporting. It does not contradict annotations; the refresh behavior aligns with readOnlyHint=false.

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

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

The description is front-loaded with the tool's identity and purpose, and the routing guidance is compressed into a clear final clause. The capability list is dense but each item adds scope information. It could be trimmed slightly, but no sentence is wasted.

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

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

For an 8-parameter tool with no output schema, the description gives enough operational context: what kind of entity to research, what dimensions are analyzed, and which sibling tools to use instead. The schema covers parameter details, and the description covers strategy and differentiation, so an agent can call it correctly with minimal ambiguity.

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 parameters are already individually documented. The description adds some high-level context (e.g., executive report, evidence retrieval) but does not clarify specific parameter syntax, defaults, or interactions beyond what the schema provides. 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 this is an Entity-first decision entry for brands, companies, business entities, products, and campaigns, and explicitly contrasts it with analyze_topic and get_trending. An agent can immediately identify what resource this tool operates on and how it differs from its siblings.

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 direct routing guidance: brand/entity research should use this tool, pure topic trend research should use analyze_topic, and current rankings should use get_trending. This is explicit when-to-use versus alternatives guidance, leaving little 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?

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 description adds useful behavioral context beyond the annotations: it is based on local real history, computes several named metrics, and returns insufficient_history when history is insufficient. Annotations already signal read/write and destructiveness, so the description does not need to restate those. No contradiction arises with the 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 core purpose, partitions responsibilities with the sibling, and includes the key edge-case return. Every clause earns its place with no redundancies 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?

Given three parameters and no output schema, the description covers the essential behavior, the sibling boundary, and the failure condition. It could be more explicit about the shape of a successful return, but the listed metrics strongly imply what the result contains, and the schema handles parameter details.

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 all three parameters (keyword, refresh, platforms) are already documented in the schema. The description adds no parameter-specific meaning beyond that, which meets the baseline expectation but does not elevate it.

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 purpose: computing lifecycle, velocity, persistence, diffusion, source reliability, and confidence from local real history. It also explicitly distinguishes itself from professional_intelligence by listing the use cases the sibling covers. This makes the tool's role clear and differentiates it from its siblings.

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 explicit routing guidance: brand entities, media, anomalies/predictions, alerts, and reports should use professional_intelligence. It also states the insufficient-history return condition. However, it does not explicitly state positive triggers for when to choose this tool over other trend-related siblings, so the when-to-use guidance is strong but not fully comprehensive.

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?

Annotations only say readOnlyHint=false and destructiveHint=false, so the description carries the burden of explaining mutation scope. It does so well by disclosing that behavior is local-only, non-third-party, and non-uploading, and adds the workspace_id requirement rule. It stops short of describing auth expectations or failure/error behavior, but the key side-effect scope is clear and consistent with the 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 three sentences with no filler: the first states what the tool manages, the second constrains side effects, and the third gives the key invocation precondition. Critical 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 13 parameters and no output schema, the description covers purpose, mutation scope, external-behavior exclusions, and the most important action-dependent parameter rule. It does not spell out action-specific required parameter combinations (e.g., member_set needs member_principal and role), but the schema descriptions cover those fields reasonably. Overall it is sufficient for an agent to select and invoke the tool correctly in most 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 description coverage is 100%, so the baseline is 3. The description adds value by codifying a cross-parameter rule: workspace_id is required for every action except list/create. It also maps the action enum to high-level resource categories (member, watchlist, saved query, alert rule, audit), which helps an agent reason about which parameters apply to which action.

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: '管理 TrendHub 本地工作区状态' (manage TrendHub local workspace state), and enumerates the concrete sub-operations (create/read workspace, maintain members, watchlist, saved query, alert rule, audit). It also differentiates from sibling trend-analysis tools by explicitly scoping to local workspace data and excluding third-party platform modifications.

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 actionable context: it clarifies that the tool only writes to a local data directory, does not upload automatically, and notes that the mutation interface is not exposed on public web hosting. It also states the workspace_id precondition ('list/create 不需要 workspace_id，其余 action 必须提供 workspace_id'), which is directly useful for invocation. It does not explicitly name alternative tools, but no sibling clearly overlaps this workspace-management function.

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 are limited to broad hints, so the description carries the behavioral burden. It adds meaningful detail: the source is the official homepage feed, topic words are derived rather than official, session mode is surfaced, and cookie-based auth changes the output. No contradiction with annotations, though failure modes and rate limits are not covered.

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, front-loaded sentence that leads with the main purpose, then enumerates outputs and configuration requirements. There is no filler or redundancy; the key constraints ('游客零配置即可用', XHS_COOKIE condition) are compact and useful.

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 covers the main returned groups and the authentication-dependent branch, which is enough for an agent to decide whether to call the tool. It does not specify exact output structure or error behavior when XHS_COOKIE is missing, but the five optional parameters are already schema-documented, so the remaining gaps are minor.

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 five parameters. The description adds some context by tying XHS_COOKIE to the official hot-search list, which informs with_hotlist, but it does not materially clarify the other parameters beyond what the schema provides. 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 states a specific resource ('小红书热点聚合（主打平台）') and enumerates the exact outputs: official homepage recommendation-feed notes with cover/author/like/link, derived high-frequency topic words, session mode, and an optional official hot-search list. This is much stronger than a vague or tautological purpose, but it never names or differentiates from sibling 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?

The description gives useful context: guests can use the recommendation feed with zero configuration, and setting XHS_COOKIE unlocks the official hot-search list. However, it does not state explicit when-to-use conditions or point to alternatives among the 20 sibling tools, so usage 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.