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

Beyond the safety annotations (readOnlyHint, idempotentHint), the description discloses two non-obvious behavioral traits: change_pct is computed only from consecutive closes within the returned range, making the first row null, and amount_cny is reported as 'not_available' rather than estimated. It also names the upstream source (Tencent/gtimg fqkline, keyless). These details prevent an agent from inventing turnover values or misinterpreting the first row's missing change_pct.

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 fronts the core purpose first, then gives example queries, and then covers critical caveats and the source. The examples sentence earns its place by helping an LLM map natural-language Chinese/English queries to the tool, and the caveats are genuinely important. It is denser than minimal, but every substantive clause adds value, with no fluff or 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?

Since there is no output schema, the description appropriately names the returned fields (open, high, low, close, volume, change_pct, amount_cny) and explains the two non-obvious output values: a null change_pct on the first row and 'not_available' for amount_cny. It does not specify units, row ordering, or the exact JSON response shape, but those are less critical for an agent deciding whether and how to invoke the tool. Combined with rich annotations, this is sufficient for safe and correct use.

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

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

The input schema covers 100% of parameters with descriptions for codes, start, end, and adjust, so the schema already carries the parameter semantics. The description merely repeats the code limit ('Up to 20 comma-separated 6-digit codes') and adds no new syntax, constraints, or format details beyond the schema. With full schema coverage, the baseline score 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 opens with a specific verb and resource: 'Daily OHLCV history for one or more Chinese A-share stocks over a date range — open, high, low, close, volume, and day-over-day change % per trading day.' It clearly differentiates from siblings by explicitly noting that turnover amount is not exposed by this daily-bar source and pointing to ashares_quote/ashares_turnover_ranking. The embedded example queries further reinforce the exact kinds of user intents the tool satisfies.

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 an explicit routing guideline: 'use ashares_quote or ashares_turnover_ranking for same-day turnover amount,' which tells the agent when not to use this tool. The historical-bar scope is evident from the phrase 'Daily OHLCV history' and the date-range examples, but it does not systematically compare against all sibling tools such as ashares_quote for current prices or ashares_market_snapshot. This is clear context with one important exclusion, but not a comprehensive routing guide.

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