get_industry_info

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

No annotations are provided, so the description carries the full burden. It does disclose a meaningful provenance caveat (the taxonomy is not interchangeable with the legacy CSRC standard), which is real behavioral value, but it says nothing about return shape, whether the call is read-only, error behavior for invalid codes, or what with_boards changes.

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 text is short and free of padding, but it is front-loaded with a cross-reference to an external tool's CLI flag that an agent may not be able to resolve, rather than with a direct statement of what the tool returns. The second sentence is the most valuable and should arguably lead.

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 three-parameter tool with no annotations and no output schema, the description leaves too much unstated: neither the parameters nor the return value are described, and the only substantive content is the taxonomy warning. An agent could call it, but would be guessing about format and with_boards.

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 description coverage is 0%, so the description must compensate for all three parameters, and it does not. "Company/industry query" hints that code identifies a stock, but format and with_boards are entirely unexplained in both schema and description, leaving two of three parameters semantically opaque.

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 identifies the resource (Eastmoney company/industry data) only by analogy to an external CLI flag ("a-share-data fetch_history --industry") rather than stating a direct verb+resource. It does distinguish itself from the sibling get_stock_industry by naming a different taxonomy, which helps selection, but an agent must infer that the tool returns industry classification for a given stock code.

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?

There is an implicit routing rule: use this tool for Eastmoney taxonomy, use get_stock_industry for Baostock's CSRC taxonomy, and the standards are not interchangeable. That is useful context, but it is stated as a warning rather than an explicit when-to-use/when-not-to-use directive, and other related siblings (list_industries, get_industry_members, get_industry_data) are not addressed.

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