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

With no annotations, the description carries the full load and does so well: it discloses that the 9-day sequence is always the latest 9 trading days regardless of `date`, that `is_fallback=true` means the requested day's break rate was unavailable, that values shift intraday with a 5-minute cache, and that the tool is institutional-edition only (an access restriction). These are exactly the operational facts an agent cannot infer from schema or 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?

Front-loaded with the core purpose, then field schema, then trigger phrases, then caveats — a logical order where each sentence carries distinct information. It is dense and relies on bold/emoji markers, which borders on clutter, but nothing is truly redundant.

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?

Covers the metric definitions (break_rate formula), the fallback condition, cache/TTL behavior, and edition restriction, which is more than enough for a single-optional-param read tool that also has an output schema. An agent has everything needed to call it and interpret 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%, so the date param is already documented (YYYY-MM-DD, blank = latest). The description adds genuine meaning beyond the schema by clarifying that `data`'s 9-day series does not vary with `date` and that a fallback flag signals the requested day wasn't obtained — the key nuance for interpreting the single parameter's effect.

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+resource: it delivers market sentiment via break rate (破板率) and profit-effect 9-day trend, and the opening line '一眼看今天短线情绪冷不冷' frames the exact question it answers. It is clearly distinguishable from siblings like ashare_market_overview, ashare_broken_board, or ashare_limit_up because it names its composite metrics.

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?

Gives concrete trigger phrases ('今天情绪怎么样/赚钱效应如何/破板率高不高/市场冷不冷') that map user intent to this tool. However, it never explicitly names or excludes alternative siblings such as ashare_broken_board or ashare_market_overview, so the when-not boundary is left implicit.

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