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

There are no annotations, so the description carries the full load and it does well: it discloses BYOK (an extra ASHARE_LLM_KEY whose tokens the customer pays for), the ¥99 professional-tier floor, and an independent 2,000-call quota that does not draw from the 500k data pool. That is exactly the cost/quota context an agent needs before invoking an LLM-backed tool. It stops short of saying how slow or variable the call is, or what happens when the quota is exhausted.

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?

Purpose is front-loaded in the first sentence and the three ⚠️ warnings are cleanly separated by concern (auth, billing, scope). It is slightly padded by the bolded bilingual agent label, but every line carries real information for an agent.

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?

Return values are covered by an output schema, so the description need only explain the call surface — and it covers the non-obvious parts: natural-language input, read-only data access, and the billing and quota model. For a single-parameter tool this is complete.

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?

With one parameter at 100% schema description coverage, the baseline is 3. The description's example condition duplicates what the schema already shows in its Q description, so it adds no syntax, format or constraint detail beyond the structured field.

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 gives a specific verb and resource: it hands natural-language screening conditions to read-only data tools and returns a candidate pool plus evidence citations and a tool trace. The worked example ('高ROE + 央企 + 近5日主力净流入') makes the input shape concrete. It never names a sibling such as ashare_screen, so differentiation from the other screening tools is implied by scope rather than stated.

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 says when to reach for it ('适合…这类条件选股') and draws explicit boundaries ('只做条件选股，不做涨跌预测、不推荐买卖、不自动交易'). What's missing is routing to alternatives — with ashare_screen, ashare_agent_search and ashare_strategies in the sibling list, an agent still has to guess which screening entry point to use.

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