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

No annotations exist, so the description carries the full burden and does: partial-failure semantics (per-item ok flag, requested/returned/failed counts), hard caps (200 stocks professional / 1000 institutional; 60,000 total rows = stocks × count), a concrete performance benchmark, per-returned-stock billing, and a paywall (Professional ¥99+ only). These are exactly the traits an agent must know before calling.

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 core statement is front-loaded and the ⚠️ sections impose usable structure on a dense block (scope → differentiation → benchmark → params → returns → caps → pricing). It is longer than ideal and slightly redundant (per-item result shape is restated in the returns and caps sections), but nearly every line 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 6-param batch tool with an output schema, the description still covers the operational envelope: scale limits, cost model, tier gating, failure tolerance, and field naming. Nothing an agent needs in order to call this correctly or to prefer a sibling 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 baseline is 3; the description still adds meaning the schema doesn't — bare 6-digit codes are accepted, count is per-stock (30 each) and interacts with the 60,000-row cap (e.g. 200 × 300 hits the ceiling), and the turnover field name is called out as a return-column gotcha. The only gap is minor: fq/period behavior is left to 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 title line states a specific verb, resource, and scope: fetch K-lines for multiple stocks over one shared time window, per-stock success flagged. It then explicitly distinguishes itself from all three sibling K-line tools (ashare_kline = one stock, ashare_kline_full = one stock × full history, ashare_market_kline = one day × whole market), so an agent can route without opening any 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?

Concrete triggering scenarios are given ('这几只的走势', '把我这个池子的 K 线拉下来', '一个行业最近 60 天表现'), plus an explicit exclusion rule: don't loop ashare_kline yourself because 200 calls ≈ 2.3 min with rate-limit backoff versus 3.39 s here. The alternatives table makes the when-not unambiguous.

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