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

Annotations already declare readOnly, idempotent, closed-world, so the safety profile is covered. The description adds real value beyond that: it discloses per-call billing cost ('每次调用计费 1 次') and the aggregation window, both of which affect invocation decisions. It could go further on default lookback semantics, but the billing disclosure is a genuinely useful addition.

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, no filler, with the core resource statement front-loaded and the billing note trailing. The metric enumeration earns its place by previewing the return shape in the absence of an output schema. Slightly dense repetition of '某只股票关联' across both sentences keeps it from a 5.

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 compensates by naming the returned fields (mention counts, first/last mention timestamps, institution/KOL counts), which is what an agent needs to decide whether to call it. The main remaining gap is the absence of any sibling differentiation, which matters given a large cluster of heat-related tools.

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 four parameters including defaults, min/max, and the ts_code/stock_name either-or constraint are already documented. The description only loosely restates the time window ('最近一段时间') and adds no syntax or format guidance beyond the schema. Baseline 3 applies when the schema carries the load.

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 title and opening sentence give a specific verb+resource: it computes concept heat for one stock, listing which associated concepts are hottest. The second sentence enumerates the metrics returned (mention count, first/last mention time, number of institutions/KOLs), so the agent knows exactly what the tool produces. It does not name the reverse-direction sibling (get_concept_stock_heat) or get_stock_news_heat, so differentiation is left 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?

Usage is implied by the '某只股票关联哪些概念最热' framing – the agent infers it should call this when it has a stock and wants concept-level heat. There is no explicit when-to-use/when-not-to-use statement and no routing to alternatives like get_concept_stock_heat, which is the mirror-image tool an agent could easily confuse it with.

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