stock_board_industry_info_ths

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds only that the return type is a pandas.DataFrame, which is useful but not behavioral context beyond what annotations imply. It does not mention data source quirks, possible failures for non-existent symbols, or any other runtime 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 very short and includes a reference URL and return type, which are potentially useful. However, the parameter section is essentially filler because it repeats the tool's purpose. The structure follows a docstring format and is front-loaded with the tool's name, but the content is minimal.

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 simple read-only tool with one parameter, the description is incomplete because it fails to explain the parameter semantics, which is the key piece of information needed to invoke the tool correctly. Annotations and the schema cover safety and the parameter's existence, but the meaning of 'symbol' remains ambiguous. The URL suggests a code format, but the default value is a name, creating confusion.

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?

The parameter description is tautological: ':param symbol: 板块简介' repeats the same phrase used for the tool's purpose, and does not clarify what the symbol should represent (e.g., board name or code). The schema provides only a default value '半导体' (semiconductor) and no description. With schema description coverage at 0%, the description fails to compensate, leaving the agent uncertain whether to pass an industry name, a numeric code, or something else.

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 tool as returning an industry sector introduction from THS (同花顺), with a reference URL. It is clear from context that this is a data retrieval tool for sector overview information, and it distinguishes itself from sibling tools such as stock_board_industry_summary_ths and stock_board_industry_index_ths. However, it lacks an explicit verb like 'get' or 'return', making it a noun phrase rather than a full behavioral statement.

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?

The description provides no guidance on when to use this tool versus alternatives, no exclusions, and no mention of when not to use it. Sibling tools cover similar THS industry board data (summary, name, index, constituents), but the description does not explain what differentiates this tool from them. The only hint is the title itself, which is insufficient for confident selection.

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