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

With no annotations, the description does most of the work. It discloses that this is same-day only, that this is 委托 order flow rather than 成交 or 十档盘口, that this is institutional-edition-only, that a single call returns about 200 records at most, and crucially that meta cancel_ratio is scoped to 'returned_rows' rather than the full day. I deducted one point because it never spells out the read-only, non-mutating nature or any pagination/rate behavior.

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 is front-loaded with the core concept in bold, then the caveats and the sibling distinction. It is information-dense and mostly earns its length, though the row-field and meta-field enumerations partly duplicate the output schema that already exists.

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, single-purpose data query, the definition includes everything an agent needs: what the data is, when to use it, its limits, its time scope, its edition restriction, and a statistical-scope caveat on meta. The output schema covers the return shape, and the prose still clarifies some of it.

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, but the description adds the enumerated tur and vol thresholds and the approximately 200-record cap for limit, which is more than the schema says. It does not explain how vol and tur combine or which one takes precedence, which keeps it from a 5.

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 states a specific verb and resource, namely L2 large-order pending orders (挂单) for a stock, and explicitly contrasts it with the sibling ashare_bigorder_flow: 'queue = 挂单（可能撤），flow = 成交（真买了）'. An agent can tell the two apart 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 directly maps user intents to the tool, such as '封单是真的吗', '有没有大单挂了又撤', and '假封单'. It states that queue and flow should be viewed together, which names the alternative and explains why. It also mentions this is same-day only and lists the permitted vol and tur values.

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