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

With no annotations, the description carries the full burden and does: it discloses that this is a paid tool with a Standard (¥29.9) tier floor, that Trial is excluded, that there is a separate daily quota (200/500/2000 by tier) checkable via ashare_usage, and that unsupported symbols produce an explicit error. It also flags the reproducibility trap that qfq series are recomputed after ex-rights events and that backtests should use hfq/nofq — behavior no annotation or schema field would 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?

The purpose and scope are front-loaded in the first clause, and the numbered ①②③ comparison is an efficient structure for sibling differentiation. It is dense with bold and warning glyphs and repeats 'ashare_kline' and '10 年' several times, which costs some tightness, but essentially every sentence carries decision-relevant 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 4-parameter tool with an output schema already present, the description covers what it must add: selection criteria, quota/permission gate, instrument exclusions, adjustment-mode caveats, and the fixed 7-column shape. Nothing an agent needs in order to call this correctly or avoid a failed call 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?

Schema coverage is 100%, so the baseline is 3; the description still adds meaning by explaining why fq choice matters (qfq is non-reproducible for backtests), which the schema only lists as enum values without rationale. The implicit start default (2016-08-08) and the code whitelist are reinforced rather than newly introduced, so it sits above baseline but not at the top.

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

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

The description opens with a specific verb+resource+scope: full-history K-line, 10 years of daily bars from 2016-08-08, with an optional adjustment mode. It goes further and enumerates three explicit axes of difference from the sibling ashare_kline (row cap, fq parameter, instrument coverage), so an agent can pick correctly without opening either schema.

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 names the exact user phrasings that select this tool ('十年走势/长期回测/全历史数据/复权价/后复权/原始价') and states when NOT to use it: ETF, convertible bonds, indices, sectors, HK/US stocks, futures and FX will error and should be routed to ashare_kline. That is explicit when/when-not/alternative guidance, not inference.

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